Just putting this on the list for everyone else to read and comment on
if there are comments to be made. And yes, I agree John.
Brian
------- Start of forwarded message -------
From: "John Keiser" <[EMAIL PROTECTED]>
To: "Brian Jones" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Subject: RE: java.lang checkin ...
Date: Thu, 13 Aug 1998 11:03:56 -0400
Message-ID: <001101bdc6cb$97d87cd0$[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Well, I have a section in the Hacker's Guide: Portability, Robustness,
Efficiency, in that order. First, it must be as portable as possible.
Second, as robust and bug-free as possible. Third, as efficient as
possible. The first two are the main goal, the third is the secondary (but
important) one. I like the way you define them, though.
Here's how I'd redefine them:
1. Robust: Ridiculously robust. As bug-free as possible. Works in
pathological situations other VMs wouldn't dream of.
2. Portable: works on many VMs. Works in many environments and on many
platforms (this means, possibly, a low memory version).
3. Efficient: as fast or faster than equivalent Sun classes.
I had portable in front of robust, but I like your order better. I'll
change it if you all think it's a good idea. Please continue this
discussion on the list, as it impacts the others. I'm not bumping it up
there because I don't have your permission to put your message there, and
that would be a breach of etiquette.
--John Keiser
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Brian Jones
> Sent: Thursday, August 13, 1998 12:25 PM
> To: John Keiser
> Cc: [EMAIL PROTECTED]
> Subject: Re: java.lang checkin ...
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > But you do bring up a definitely valid solution. We could specify a
> > certain set of classes that the VM must implement, and only implement
> > "template" versions of them ourselves that VM implementors can
> use and fill
> > in the things that they have to. It's certainly viable. Hell, we could
> > specify that set of classes to be the ones that Sun doesn't
> work with us on,
> > and that would make everything happy and compatible without
> much, if any,
> > work from us.
> > What do you two think? I am warming up to the idea, now that I have
> > delved into the C code required to make these things work. It's not
> > terrible, but it could easily be done better and faster without the JNI.
> > --John Keiser
>
> I think this method of providing templates (possibly doing them
> ourselves for at least one VM) is effective since it lets us
> concentrate on doing the things which are independent of the VM.
> Speed gains could probably be made by tightly coupling a few of the
> core classes to the VM in use.
>
> There are 3 categories I'm seeing:
>
> VM-dependent
> Fuzzy Gray Area
> VM-independent
>
> I'm basing this on the idea that it is impossible to legally make a
> complete set of core classes which will execute flawlessly under the
> Sun JVM. Haven't heard back from Paul on this, he probably hasn't
> woken up yet, da lazy bum. ;)
>
> I think we need to have a goals section in the Classpath web pages.
> Paul and I both think having a completely stable and bug free Java
> platform, mostly regardless of speed, is very important to start
> with. A second goal would be to work with as many JVMs as possible.
> A third goal would be to be make each class (and their functions)
> execute as fast, or faster, than their counterparts in Sun's Java
> Platform. Maybe there are others?
>
> Brian
>
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > Brian Jones
> > > Sent: Thursday, August 13, 1998 9:55 AM
> > > To: John Keiser
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: java.lang checkin ...
> > >
> > >
> > > "John Keiser" <[EMAIL PROTECTED]> writes:
> > >
> > > John,
> > >
> > > It really sucks that we can't just be a drop in replacement.
> > > I'm going to see if Paul can get a fairly definitive list of what
> > > we are allowed to mimick and what we cannot written down, perhaps
> > > on the website. I think he is most tuned in on the law these
> > > days.
> > >
> > > Perhaps the VM needs to implement certain things inside the
> > > java.* hierarchy and we shouldn't bother with them since the only
> > > way we can do it is to code something according to the VM being
> > > used to begin with, or do we need to implement things like
> > > java.lang.Class in order to rely upon their structure and design
> > > in all subsequent classes?
> > >
> > > I hate Sun.
> > >
> > > 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
> > >
> > > --
> > > |-------------------------------|Software Engineer
> > > |Brian Jones |[EMAIL PROTECTED]
> > > |[EMAIL PROTECTED] |http://www.nortel.net
> > > |http://www.classpath.org/ |------------------------------
> > >
>
> --
> |-------------------------------|Software Engineer
> |Brian Jones |[EMAIL PROTECTED]
> |[EMAIL PROTECTED] |http://www.nortel.net
> |http://www.classpath.org/ |------------------------------
>
------- End of forwarded message -------
