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@xxxxxxxx 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
