John Keiser wrote:
> Does Electrical Fire currently work with JDK (and implement its native
> methods)?
Currently, to run EF you need to download the official JDK1.2 jar file.
> 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.
I'm not sure what VMObject is for. If the VM already implements
java.lang.Object, can VMObject simply be a trivial subclass of it ?
> 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).
Don't know about other VM's, but that would make it easier for EF. Throwable
and exceptions are already supported.
> > 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.
We'll just need to make it possible to specify native libraries that have higher
precedence than EF's built-in versions. I think that it's even possible to
allow Classpath to implement individual native methods in a class while EF
implements the others.
-Scott
