At 09:47 AM 4/2/00 , Jonathan S. Shapiro wrote:
>1. Portability
>
>Until the release of the IBM JDK, there has not been a sufficiently reliable
>JDK for linux/x86 (or any other open source OS). The kaffe effort doesn't
>appear to have a consistent, easily installed set of libraries. I am
>therefore concerned that if I do this in Java I will wind up in difficulty
>when the time comes to run it on top of EROS. Realistically, is there a
>fully open-source Java implementation (including libraries) that can be
>relied on at this point?
The Linux/JDK I've been using is Blackdown's, which, as a Sun port, is SCSL rather than open source. Technically, it seems to work as well as Sun's JDKs do on other platforms. Whether SCSL vs open source is fatal for you, only you can tell.
Is the IBM Linux/JDK now open source?
>In particular, can Swing be redistributed (in bytecode form) on a non-Sun
>JDK, and is the JDK support out there on the open-source Java
>implementations good enough to support it?
I believe this is allowed under SCSL. I believe you can even distribute sources as well. Where SCSL hits you is when you want to distribute a modified Swing.
>2. Startup Time
>
>Since the first iteration (and probably the most commonly used version for
>the forseeable future) of this program will be a command-line tool, I am
>concerned about the startup-time cost of JIT compilation. My experience is
>that it is quite slow, and in the "start run exit" model of program you pay
>this cost again and again.
>
>Does anyone have an opinion on whether it is "fast enough"?
Startup time totally sucks. Here's a possibly unfair comparison: On my Thinkpad 770Z (Pentium 2, don't remember the MHz, 128MB Ram), Symantec Cafe, partially implemented in Java, takes 37 seconds to launch. Forte for Java Community Edition, implemented only in Java (and to be open sourced by Sun under Mozilla) takes 1 min 13 seconds to launch. In both cases, it's a second launch, giving caches the chance to cache what they may. The two programs provide similar functionality, but who can say whether they are implemented with similar skill.
HotJava (implemented only in Java) takes only 7 seconds to launch, compared with Netscape's 4 seconds. Even though it's slower, I'd also say 7 seconds isn't bad for a browser's worth of code.
>Since this application doesn't require (indeed, does not *want*) dynamic
>class loading, does anyone have experience to share with the bytecode->C
>compilers?
Not I.
>3. Heap image size
I think there were people at EC who wrestled with this issue, some of which
may even be on this list, but I wasn't one of them. However, I do remember
our big surprise: Sun's virtual machine have a huge fixed memory cost *per
class*. This leads to coding things with fewer larger classes rather than
more smaller ones. I.e., it leads one away from good object style. This is
>
>The required heap size for this application is a function of the size of the
>code base. It is likely that for any given max heap size some code base will
>overflow the heap. Why the hell did the bozos at Sun set a max heap size,
>and how does one get the runtime to simply grow the heap in reasonable
>increments?
>In the short term, I may decide to go with C for portability reasons. I'm
>hoping someone can tell me a story to the effect that I do not need to.
>Partly, I just hate to ask people to download 8 megabytes of Java runtime
>just to run this application.
If your target platforms include Windows, then I'd say, despite all of Java's problems, and despite the extraordinary achievements of Cygwin, that Java is much more portable than C. Take a look at the terrible quantity of "#ifdef"s in the little bit of C code in the E source distribution.
If you're only trying to be portable across Unixes, then C and Java are both reasonably portable.
Anyone care to speak for the Mac?
>Eventually, there will want to be GUI versions of this tool, and the
>portability of Java is very attractive. I just want to understand how it's
>going to bite me down the road before placing my own bets...
I'd bet on Java because it's the Schelling point. I.e., I'd bet on it because others are betting on it for this very reason. The level of investment being poured into making it work will probably eventually succeed.
Even though this argument was true even back in the AWT days, I don't know that I would have had the courage to make this argument. AWT never worked. Fortunately, Swing basically does work. However, avoid the Swing in Sun's JDK/JRE 1.2.x, as it has some terrible bugs. Use either the Swing for 1.1.x or 1.3.x.
Cheers,
--MarkM