> From: Scott Furman [mailto:[EMAIL PROTECTED]]
>
>
> 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 ?
>
The VM doesn't already implement Object--thus the need for VMObject, which
implements the trivially few methods that actually require the VM's input.
The point of the VM interfacewas to make the job as easy as possible for the
VM to implement things (read: as few classes and methods as possible)
without taking away their power to optimize and innovate. Controlling the
structure of Object doesn't seem necessary for that power. If you have a
need for control of the Java code for Object, let's talk. In my experience
so far, it seems like you can put all the data you need into your internal
native Object structure and thus don't even need a single Java field in
Object.
> > 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.
>
It sounds like a consensus is grinding its way down. Look for the change
soon.
>
> We'll just need to make it possible to specify native libraries
> that have higher
> precedence than EF's built-in versions.
>
That'd work, too. Hmm. How could that be done automatically and securely,
though? There would have to be the following precedence for it to work
right and securely:
- Classpath libs
- EF libs
- User libs
You don't want to give native users the ability to override your methods (or
do you?).
Right now the way we load the libs is to run System.loadLibrary(). There
would need to be a way to distinguish between when Classpath is doing this
and when a user is doing this.
> I think that it's even
> possible to
> allow Classpath to implement individual native methods in a class while EF
> implements the others.
>
Possible, yes. But not desirable, IMHO. I was trying to avoid that when
designing Classpath's VM interface. Too many inter-group control issues
involved when two different groups have a stake in the internal structure of
the class. Who, then, owns it and maintains it? This way, there are no
gray areas: all the classes in the VM interface are yours *entirely*. We
can, if you wish, provide space in Classpath for them, but it's better if
you can have them as part of your distribution. It just seems cleaner that
way.
That was probably irrelevant discussion, but I like to hash these things out
whenever I get a chance. I'd like to release with a clean and useful
design.
I would like to point out the point of vm/reference, too ... it's supposed
to be a "reference implementation" so that you can copy code if you like and
speed the porting process even more.
--John Keiser
