Fedora Core 3

[Thomas Fitzsimmons]

On Sat, 2004-07-03 at 04:57, Nicolas Mailhot wrote:
> Le ven, 02/07/2004 à 15:00 -0700, Anthony Green a écrit :
> > On Fri, 2004-07-02 at 09:06, mike at flyn.org wrote:
> > > I would like to see more Java tools in general:
> > > 
> > > 1.  Eclipse's libswt-gtk2 would be nice (as a package installable with or
> > > without the Eclipse IDE).
> > 
> > I agree that this would be nice.  There's another bit of Eclipse
> > technology that has already wormed into FC development - the Eclipse
> > bytecode compiler (in the ecj RPM).  So a precedent has been set for
> > extracting and distributing bits of Eclipse has been set.
> > 
> > > 2.  Free software Java applet plugin for epiphany, Firefix, etc.  It seems
> > > that gcjwebplugin will be the candidate eventually.
> > 
> > gcjwebplugin is making fantastic progress.  I think the biggest bit of
> > work needing doing is auditing the gcj/GNU Classpath runtime for missing
> > security checks.
> 
> And better integration between jpackage and fedora.
> Since FC2 the jpackage support list is filled with people having
> problems with the fedora packages.
> 

Yes, the plan is to adopt jpackage wholesale starting with Fedora Core
3.  We haven't done this to date for two reasons: one, the jpackage
stack currently relies on having a proprietary JVM installed; that
reliance is unacceptable for Fedora.  Two, we want to take advantage of
GCJ's native compilation abilities to provide users with a fast, free
Java environment.

We're currently working on GCJ-JPackage, which aims to provide a free
drop-in replacement for proprietary JVM jpackages.  That will eliminate
jpackage's reliance on a proprietary JVM, and allow us to ship
unmodified jpackages with Fedora.

To make use of GCJ's abilities, we're going to create an arch-specific
add-on package for each jpackage that will contain DSOs created from the
jpackage's jars.  gij will automatically find and load these DSOs as
part of its class lookup algorithm.  This will give us the speed
benefits of native compilation without requiring us to sacrifice
compatibility with more traditional Java environments.

Tom