You *have* to have a skeleton class sitting there somewhere, whether it's
the main class or the delegate class. You can't get around it. So we just
create a skeleton Runtime and Class class and make every method native to
compile with. It works just the same way as if there's a VMClass or
VMSystem. I saw no reason not to do it, and many benefits *to* do it. I
also sent out a message letting everyone know about the change quite a while
back and invited discussion or arguments ... I got none then, so I went
ahead.
Class I didn't include because the VM needs to attach VM-specific
information to every Class object. It is *much* harder and *much* more
inefficient to do so if Class.class is not provided by the VM; you have to
have a hashtable to get from the Class object to the native data. If they
own Class.class, they may implement certain optimizations that allow data to
be easily associated with the object. I made the same decision with
java.lang.reflect.Method/Constructor/Field.
Runtime I didn't include because it's a pain in the ass to delegate 40
methods and seems kind of useless to have 98% of the methods delegated. Why
bother when the VM can just take over the class in the first place and
everything moves quicker and easier? If I wasn't doing it with Class
already, though, I wouldn't do it with Runtime.
After looking at the problem as long as I have now, I personally want to
just say "here is a list of the classes you have to implement to work with
Classpath" and include Runtime, Object, Class, Thread, ThreadGroup,
Constructor, Method, and Field in that list. That's my personal feeling.
It would certainly be the cleanest and simplest thing to do. In the end,
though, I wanted to keep it as close to the original plan as possible since
we had already discussed it so much. When I get it working with Japhar in
the first place we can discuss it again ... I have no problem changing it if
there is a cleaner idea.
--John Keiser
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
> M. Renn
> Sent: Sunday, October 25, 1998 12:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: missing classes (java.lang)
>
>
> John Keiser wrote:
> > Runtime and Class I can answer for.
> > Those two are part of the VM interface. They are in
> > vm/reference/java/lang. You need to include vm/reference in
> the compilation
> > classpath to make it work. We can discuss moving them into the
> main tree,
> > but I put them here to emphasize the fact that the *VM* will be
> giving us
> > those classes (trust me, it's *much* easier that way for both
> of us), and
>
> Don't we still have to have java.lang.Runtime and
> java.lang.Class? How else
> will references to those classes work? They will just have to delegate to
> the appropriate VM specific class. Unless you are somehow planning on the
> build process copying the appropriate VM specific classes into
> the java.lang
> namespace or something.
>
> --
> Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
>
>
