Re: Trying to merge java.lang.Float, java.lang.Double withClasspath -- help wanted

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Sun, 2003-09-21 at 23:59, Andrew Haley wrote:
> Ah, what is the point of doing this to libgcj?  I don't get it at all,
> and there's no explanation here.

This was discussed on the classpath mailinglist and there were no
objections back then. It is even listed (like all VM interface changes)
in the NEWS file that comes with the 0.06 release:

        VM Interface changes:
         
        * VMClassLoader.loadClass(), the bootstrap classloader called by
          Class.forName() and ClassLoader.loadClass(), may now return null when
          a class is not found instead of throwing a new ClassNotFoundException.
          This is a performance optimization in some cases. This also changes
          the Class.forName() reference code.
        * Native methods in Class have been moved to VMClass.  A few additional
          methods are also available in VMClass to provide optional performance
          improvements.
        * A VM can now supply its own String.intern() strategy through the
          VMString class. The supplied VMString reference class implements the
          original WeakHashMap strategy.
        * Float and Double to/from bits conversion functions can now be supplied by
          the VM through VMFloat and VMDouble. Default JNI conversion methods are
          supplied.

These kind of changes are done to make merging of the standard class
libraries of libgcj, kaffe, ikvm, sablevm, kissme, etc easier.
The idea is that GNU Classpath (slowly) transforms into the upstream
source of the different free software VM/Compiler projects.

I would really like it if libgcj developers participated in the VM
interface discussions on the Classpath mailinglist so we can make sure
the design is right from the start.

Thanks,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part