> > I may have missed this ... will this be covering GCJ?
> >
> > Compiled Java has some nice advantages. Including
> > more natural and efficient integration with native code,
> > as well as faster startup and the ability to do some
> > aggressive ahead-of-time optimizations, and working
> > better with standard OS tools (RPM etc).
>
> I will mention this, but so far in my experience GCJ has not produced
> terribly optimal code, it's behind in terms of JDK support, and is not
> supported by any of the application server vendors. Even Turbo/J seems
> to have a tough time beating the more recent IBM & Sun JVM's.
In terms of performance, I guess "YMMV" is as true as always. It's
been faster than those JVMs for the things I've tried, despite not yet
doing some optimizations. Some GCJ programs can start, run, and exit
before any Sun-derived JVM is finished even warming up the JIT; that
can make up for code that's a _lot_ slower than what GCJ emits.
Admittedly it's not widely used so far, and if you want GUIs then
it's not yet an option. But it works most places that GCC works,
which means it's a significant broadening of the Java market. And
that includes addressing many parts of the "Java Community" that
have so far been excluded by Sun's restrictive process/licensing rules.
The 2.95 based GCJ packages are way obsolete; don't consider them.
(Current GCJ info: http://gcc.gnu.org/java )
> I'm curious about your comment about it working better with RPM. Can you
> give me an example of this?
While we're waiting for GCC 3.0 to ship (a few weeks :) and get
integrated with GNU/Linux distributions, "GCJ 2.96" is available on a
number of distributions ... RedHat 7.0 did the work, so distros
derived from that (as well as, I understand, SuSE and Debian)
can support it directly.
That means for example that you don't need to ship a JVM with
your application, since RPM can handle the dependencies just
like any other compiled program. End users don't need to be so
conscious that they're using a Java program, since the only real
difference is that the apps link against different shared libraries
(like "libgcj.so") that are available direct from the distro vendor.
A specific example: jPhoto. Supports new generations of digital
still cameras, using the original Java USB APIs on Linux. A 100%
Free Software stack ... folk using the RPM (with GCJ) have had
much less trouble installing and using this than folk using a JDK.
- Dave
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
