> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Brian Jones
> Sent: Wednesday, August 12, 1998 3:23 PM
> To: John Keiser
> Cc: Classpath
> Subject: Re: java.lang checkin ...
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> John or anyone else, is there some reason why GNU Classpath can't work
> with the JDK from Sun as well as Japhar or Kaffe? I realize John
> wants jnilink to have special hooks into the VM and we obviously
> have no control over the Sun JDK. Can there be a solution to the
> multiple VM problem which relies only on what is provided by the VM
> spec, etc? Ie, I thought one of the goals of GNU Classpath was to
> be a transparent replacement for essentially `classes.zip'.
>
> Brian
>
It is literally impossible for all of our classes to work with Sun's
JDK *unless* we make our implementation identical, mimicking private and
package-protected methods and behavior, even down to the point of making
sure declare private class fields in the same order as Sun's. I am
unwilling to do that, myself. It is limiting and it is probably skirting
the boundaries of law.
The basic problem is, Sun's VM uses the private and protected field
behavior, and in fact that is legitimate, they have to (though arguably they
could have defined the spec better to get around it). For example, there is
no constructor for java.lang.Class. Sun creates it in its VM by either
setting some private fields itself, or by having a "behind-the-scenes"
pointer to the ClazzFile structure, like Japhar does. Either way, we have
no control. java.lang.System may be such a class (not sure and won't bother
testing because of the next problem), as well as java.lang.FileDescriptor
(very likely) and java.lang.String (I wouldn't put it past them). The
problem spreads from there. Because we cannot write java.lang.Class, we
cannot write java.lang.reflect.*. No java.lang.FileDescriptor, no
java.lang.File--and thus no FileInputStream or FileOutputStream or
RandomAccessFile. No java.lang.String, no java.lang.StringBuffer
(probably). Etc. Etc.
Additionally, apart from that fundamental issue, a number of methods
cannot be implemented without extensions to the JNI. I don't mean, "they
can't be implemented efficiently," I mean they *cannot be implemented at
all*. Many of the methods in java.lang.System, Runtime, ClassLoader and
SecurityManager fall into this category.
In other words, there are ill-defined spec areas going both ways: there
are some things that Sun's VM knows about the classes that it shouldn't, and
there are some things that the classes know about the VM that they
shouldn't.
Here is my suggestion to deal with the problem: we distribute a
Classpath JDK version that includes everything that can possibly be made
compatible with Sun. I have made some of the first steps toward that by
documenting incompatible classes in the NoJDK file at the root of
classpath's CVS tree. I suggest everyone who knows of such an
incompatibility put that information in that file.
Bottom line, I see no way around this:
- classes.zip itself will be just fine, and it will be drop-in, but
only if we have the VM maker's cooperation (for example, he could call a
function in our library to create a class, giving us control over its
initialization).
- The native libs will be VM-independent, but only if the VM implements
certain functions to give us information about its internal state and to
give it commands. These functions are not in Sun's spec and lkely will
never be.
- The best we can do for VMs that don't play ball is to distribute a
subset of classes.zip that does not require VM-specific stuff (java.beans is
one such package, and much of java.io can be salvaged, I am sure).
P.S. jnilink works fine with just plain ol' JNI. There is no multiple
VM problem with other VMs, because they do not support multiple VMs. In
fact, the multiple VM solution I have outlined will work on other VMs with
only slight modifications (the callback from the VM on exit). However,
jnilink is not *necessary* on other VMs because they do not support multiple
VMs. Therefore, the jnilink lib I am writing will look to see if you are
compiling for JAPHAR, and if you are it does the funky stuff, and otherwise
it just does normal, simple caching.
In the end, VMs are supposed to be distributed with the classes anyway.
It really wasn't Sun's intention to allow separation of the two. I think
it's a good idea, myself, though.
--John Keiser
