Daniel F. Savarese wrote:
The situation is the same as before. It's a simple port, but the
obstacles (by no means insurmountable) are really build and packaging
issues. I suppose the one thing that has changed is that
Didge (Dave Masser-Frye) implemented the Velocity Preprocessor
(http://vpp.sourceforge.net/), which provides an all-Java solution
for conditional compilation. The downside is requiring users
to download and install Velocity and VPP to compile ORO. But I
suppose switching from Ant to Maven for the build system would
alleviate that (except, of course, then you'd need Maven).
I'm afraid I'm one of those evil-doers that uses .bat and .sh files
instead of ever bothering to use Ant or the like. But I think I see why
you're mentioning it...
If all you're interested in doing it is porting it for your purposes,
it's very easy. It's almost as simple as changing all HashMaps to
Hashtable and all ArrayLists to Vector. Actually, now that I read it,
what I said in my original email that you quoted probably covers
everything.
Now, if you're interested in porting it and keeping the port in the
main source tree, that's a little more involved. You need to integrate
conditional compilation and the building of separate packages into
the build system and then submit patches. I encourage you to do that.
The only way it's going to get done is if someone with a need does it.
... and that's why. As much as I'd love to make it The Right Way, I'm
afraid I'm one of those fire and forget-ers, and if I could port exactly
what I needed once I would keep using it until it broke, regardless of
upgrades. I'll see how much time I have, however and if I can get what
I need to 1.1.x first. I've thought of a few cheap ways to remove
regexp in my code, but they're cheap enough I wouldn't roll them into my
own tree, and the thought of two code bases is just enough to make me
back off.
BTW, could you share why you are backporting to JDK 1.1.x? Besides
sheer curiousity, I just finished writing an article that mentions some
of the reasons people need to remain compatible with older JVMs and if
I overlooked one, I'd like to include it.
Only three. But I'm afraid you've hit a pet peeve of mine --
overdependence on 1.2+. Please bear with me as I vent. ;^)
1.) I'm a Mac user and like to release to older Mac users (where old
modifies Mac, not necessarily user, of course!). Anything before OS X
is 1.1.8 at best.
2.) The "big" one I'm sure you've covered: Now that Microsoft is
updating their VM again to some degree and since it's nearly everywhere
since, what, Win98SE?, I think it's useful to shoot, at most, twice, and
have one of those shots as low as possible.
3.) Releasing on PDAs with subsets of current Java releases.
I wrote a quick blurb about it on /.:
http://yro.slashdot.org/comments.pl?sid=102682&cid=8747118
I also tend to agree with Joel Spolsky when he says, "As if source code
rusted."
http://www.joelonsoftware.com/articles/fog0000000069.html
... as well as what he has to say about barriers to entry:
http://www.joelonsoftware.com/articles/fog0000000052.html
It's all 0s and 1s, and I've seen #very# few apps that #required# 1.2+.
Using the VM that's already installed on most of the Windows boxes out
there means that you very quickly open up the number of people who can
run your app with a double-click instead of counting on Web Start or the
savvy to run to java.com and download [what used to be known as] a jre.
Desktop apps need to be able to be run easily. Having most of your
backend code written to run in 1.1.x means you're a clever AWT hacker
away from releasing for Windows and PDAs [and Mac Classic]. Heck, there
are apps to help you release as an .exe which your user understands --
it's perfect. My largest app is in Swing, but it drives me crazy I was
silly enough to do that. With some thought, you can have one app that
takes advantage of Swing if it's there or sticks with 1.1 if it's not.
That's about it. It's not nearly the deal it was a few years ago, but I
still tend to like to keep my engines in 1.1.x-ish code. Write once,
run nearly everywhere indeed.
Ruffin Bailey
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
