[fedora-java] Re: jpackage.org and FC4

[Gary Benson]

David Walluck wrote:
> Ian Pilcher <i.pilcher at comcast.net> wrote:
> > It would be a very good thing, IMNSHO, if the Fedora Java folks
> > and the JPackage folks could develop some sort of co-existance
> > strategy.
> 
> I don't think that there are any major issues with co-existence. The
> idea, as I gather from the list, was always to have FC4 be ``fully''
> jpp-compatible.
> 
> The major issue I see is that the .so files and other binaries
> aren't shipped separately. I never did catch the exact reason for
> this.

There's a multitude of reasons.  The biggest showstopper of them all
(from my point of view) is that there's no way to cause the native
stuff to be installed automatically.  Someone who did 'yum install
tomcat5' would have a very slow Tomcat if they did not know to run
'yum install tomcat-gcjlibs' or whatever.

> This means that if you run a jpp package on gij then it may run
> slower because it hasn't been natively compiled.  The upside of
> shipping the .so files separately is that you don't have to lose
> them if you use a jpp package,

You would lose them unless the JPackage package was compiled with the
same compiler as the Fedora one since Native code is located using the
MD5 of the bytecode.

> As I understand it, it takes much too long to compile the libs on
> the fly (ideally what I wish could be done),

Yes.  Hours in the case of big packages like JacORB and Xalan.  You
also need an incredible amount of memory, although aot-compile-rpm
mitigates this somewhat.

> The other major issue I see is that sometimes the free packages are
> missing functionality (due to either license restrictions or actual
> missing functionality in the free stacks)

That's not such a problem these days, except where packages use Sun-
specific classes.  A bigger problem is that the Fedora rpms often
contain workarounds for libgcj issues.  Upgrading to the JPackage
loses those workarounds.

Cheers,
Gary