> From: Scott Furman [mailto:[EMAIL PROTECTED]]
>
>
> "Aaron M. Renn" wrote:
>
> > If it is (a), then you might want to make use of the Classpath libraries
> > directly. This is really not too hard, but requires some work.
> Basically
> > we expect that some of the lowest level functions of the JVM (parts of
> > java.lang and reflection) be implemented in the JVM itself.
>
> I believe that our support for java.lang.reflect is nearly 100%.
> There is also a C++
> API to access these methods. If required, we could put C
> wrappers around them so
> that Classpath could access them.
>
> The document is helpful, but what would really be great is an API
> spec that lays out
> all the methods and classes that a VM needs to implement. In an
> ideal world, someone
> working on implementing them would never need to read the Classpath code.
>
If we had the Classpath JavaDoc up, I could just link to those ... the API
requires that you implement certain *classes* and does not make any
assumptions about the methods you put in there except that they must conform
to the interface the rest of Classpath expects. All the names of those
classes are documented in
Does Electrical Fire currently work with JDK (and implement its native
methods)? In that case, it shouldn't take long to port. Japhar was
designed that way, too, and the port Aaron did didn't take very long at all.
A few renamed methods, mostly. If you look in
http://www.classpath.org/cvs/vm/reference, there is a code for all of the
~10 classes you'll need to implement. One change will be made to those
(eventually), actually to put java.lang.Throwable into the interface and
remove gnu.vm.stack (to make it easier for implementors and allow for
certain optimizations that could not be done otherwise).
If Electrical Fire already implements its own classes, that's even *better*,
and will take very little time to port. A little shuffling around of
classes will probably suffice. Basically, the concept is simple: except
those miscellaneous changes to your VM that I talked about in the
documentation, all you need to do is provide the .class files for the stuff
in vm/reference and provide the native methods in your libraries to support
those classes. You may implement *any* of the methods in the VM-dependent
classes in any way you want. Including the Java ones.
The interface doc may be a little out of date after Aaron's changes. One of
us will check into that. The VM classes' interfaces, however, should be
precisely the same.
It's good that java.lang.reflect is done in your VM. That is one API that
has to be implemented almost entirely by the VM.
Additionally, we will not be up to a complete 1.2 java.lang for a little
while yet (need to get java.security finished first). When we are, there
will *definitely* be changes to the interface.
> > gotcha I see is that we load our own native libraries and I'm
> not sure how
> > JIT's Java routines interface with existing native code.
>
> Native code loading is done on a per-method basis, not a
> per-class basis. If you are
> saying that it's possible for Classpath and EF to define the same
> JNI-callable native
> method (same class, method name and signature), then we would
> indeed need to sort
> that out.
>
I believe that's what he's saying. The way it was solved for Japhar was to
have separate libraries for lang, reflect, util, io, and net, and not load
util, io or net when running Classpath. That seemed to work fine.
--John Keiser
