Bernd Kreimeier wrote:
> Is everybody sure that it is good/reasonable/possible to develop
> core classes independend of the VM, and vice versa? In other
> words - is it possible that at one point, Japhar faces a
> decision to support either Classpath or JDK - or Classpath
> faces a decision of supporting either Japhar or another VM?
My personal opinion is that Classpath SHOULD be developed independent of
japhar. It can (and it is) be aimed mainly at japhar, but I think that
some level of VM interfacing should be kept - in other case there is no
reason to suffer great JNI penalty.
But I don't think that classpath should be compiled to run on every vm
in same binary form (thing teoretically possible with JNI/VMI etc). My
idea would be to have same set of java classes and make supporting
native library vm dependent. From classpath point of view it could look
like:
- you support full java side, compile it and package - no problems
- you provide default JNI implementations for native methods in some
classes - but not for all of them
- at compile time you check vm dependent directory (will it be in vm
source or classpath source) for methods it provides for classpath
library - and use them first. If no vm-specific implementation is
provided you fall back to default ones. If there is no default
implementation (Class,reflect.Method etc) you signal error (vm would
have to provide implementation for basic classes).
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).
This way make life easier for both you and vm implementors - you focus
on implementing native methods for classes, using every trick possible
for given vm, not on designing interfaces which will satisfy
current/future needs of classpath and implementing this interfaces in
different VMs. Of course this can be a bit more work - in terms of lines
of code, but it will be straightforward - just implement missing natives
one after another. With possibility of skipping JNI, accessing VM
internal structures etc.
There are problems - for example changes in vm requires changing vm
specific part in classpath. But if you would allow vm implementors take
care of entire native side - possibly using default implementations
provided by you - it will not hurt anybody.
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.
Artur
