Background: I'm a newcomer to the classpath mailing list. I'm interested
in classpath b/c I want to upgrade the Ghost VM to 1.1+ class libraries.
Ghost is a VM for small mobile devices, right now it supports PalmPilot
(with ports to other platforms in the works). Ghost depends on very clean
class libraries, where things like the internationalization present in
java.lang.Character (on the Sun side) can be factored out or at least
stored in an efficient manner. Right now Ghost uses JDK 1.0.2 class
libraries and supports a majority of the AWT.
I have a few comments to make on this thread.
On Tue, 15 Sep 1998, Artur Biesiadowski wrote:
[..snip..]
> This way vm creators can override code for not only
> java.lang/java.lang.reflect, but also for java.io/java.net (for example
> to make it work with their very strange threads handling).
It is my opinion that implementing platform specific functionality should
be like implementing an AWT peer. Use a Toolkit, for example:
public abstract class java.lang.Toolkit {
java.lang.peer.ObjectPeer getObjectPeer();
java.lang.peer.ClassPeer getClassPeer();
.....
}
Sort of like AWT peer except each LANG peer is a singleton, they are
associated with a class, not an instance (like ComponentPeer is to
Component). Likewise, there would be java.io.Toolkit and java.net.Toolkit,
each which produce peers that are associated with a class or an instance,
depending on what makes sense.
The only problem is a bootstrap problem, how to get the toolkits the
first time, there needs to be at least one defined native function per
VM to get access to the toolkits.
[..snip..]
> To reassume: I think that classpath should work on java side, only
> providing guidelines and default implementations to native side. If no
> default implementation is possible, then skip it and do not use
> JVNDI/VMI or some other magical interface - pass it to vm implementors.
I agree, but I also think platform specific code does not nescessarily
mean native code. I have written alot of the platform specific code for
the Palm OS version of Ghost in Java. I'm annoyed by the fact that Sun
requires certain functions to be native methods, example:
void java.lang.System.arrayCopy(Object src, int srcOffset, Object dst, int
dstOffset, int length);
Its just rediculous that this has to be a native method when its only a
few lines of native code (I don't buy efficiency, its the JavaCompiler
job to make the java code go fast, it could potentially generate the
same code as a native method would use).
Thanks!
Sean
