Mark Wielaard wrote:
> I just looked at the 1.1.8 classlist
> <URL:http://java.sun.com/products/jdk/1.1/docs/relnotes/classlist.html>
> And the only classes missing from the current Classpath CVS seem to be:
>
> java.applet.*
> java.awt.Event
> java.awt.GridBagConstraints
> java.awt.GridBagLayout
> java.awt.MediaTracker
> java.awt.image.AreaAveragingScaleFilter
> java.awt.image.ColorModel
> java.awt.image.CropImageFilter
> java.awt.image.DirectColorModel
> java.awt.image.FilteredImageSource
> java.awt.image.IndexColorModel
> java.awt.image.MemoryImageSource
> java.awt.image.PixelGrabber
> java.awt.image.RGBImageFilter
> java.awt.image.ReplicateScaleFilter
> java.rmi.*
> java.text.DecimalFormat
> java.util.zip.*
Thanks, this is helpful.
> > libgcj also has a working java.util.zip (using zlib).
>
> Does that implemention use JNI or CNI? I guess Classpath needs a JNI
> implementation.
The libgcj implementation uses CNI.
> (And to be used in Classpath the copyright should probably
> be assigned to the FSF, but maybe Cygnus already does that?)
Unfortunatly, Cygnus has retained copyright over libgcj (which is why it is not
included in the gcc distribution even though the gcj compiler is). They require
copyright on contributions to be assigned to be them. This policy has so far
resulted in libgcj development stagnating somewhat because existing code from
sources like kaffe and classpath cannot be included. There is little motivation
for volunteers to reimplement the Collections API, for example, when its already
been done in open source LGPLed code. Twice.
I'm hoping that Cygnus can one day be convinced to change this policy in the
best interests of the code. I think that gcj/libgcj is an *extremely* promising
java platform, but it just doesn't yet have the API coverage or exposure needed
to achieve critical developer mass.
> It would be very nice if gcj could use the Classpath classes
Yes, it would. This would be somewhat difficult to achieve, however, without
using code from libgcj. libgcj has to do a lot of the work that would normally
be done by the VM (as opposed to the class libraries) in a traditional Java
environment. The libgcj implementations of classes like Object, Class,
ClassLoader, String, etc are closely tied to the gcj compiler.
> would that
> mean that all the native libraries should be reimplemented with an CNI
> interface? (Classpath only uses JNI as far as I could tell.)
For the most part, it would be best to add JNI support to libgcj. This shouldn't
be too hard to do, and various people have expressed interest, but it hasn't
been done yet. Per Bothner <[EMAIL PROTECTED]> wrote this to the libgcj list
recently:
"Perhaps JNI should have higher priority than we have given it? I
don't know if Cygnus currently has scheduled work on JNI. I've
mentioned before my ideas for how we can implement JNI relatively
easily while keeping JNI's overhead to a minumum. If someone (Cygnus
or other) wants to tackle the project, I'll be happy to give my
suggestions. (Actually, you'll have a hardtime stopping me from
giving my opinions!)"
Personally I'm more interesting in doing a CNI-based AWT implementation, because
I think CNI is better.
regards
[ bryce ]
