Thoughts on 'reference classes'

[Archie Cobbs]

[ warning, random thoughts below... ]

I've been working on a new JVM and trying to figure out how
modify the "vm/reference" classpath classes into something that
this JVM particular can support.

Something occurred to me while looking at the Java sources under
vm/reference and reading some messages on this list.

On the one hand, the 'reference' classes contain many places where
the particular JVM developer is required or expected to add, subtract,
or modify the 'reference' Java code to fit that particular JVM.
>From my point of view this is annoying, because often means I have
to think hard about how to do something and whether I'm breaking
some subtle JVM semantics by doing it. But even when it's obvious
what to do, you still have to create a different version of this
class which has to be synchronized whenever you update from Classpath.

For example, VMThrowable.java. While it's clear what the JVM needs
to do in this case, whatever your JVM, you'll have to do *something*
with this class if you want to be able to print out exception traces.
Also, there are lots of other methods that are marked "XXX - Not
implemented; this requires native help" but are not native methods.
Why not just make them native so I don't have to modify the file?

On the other hand, any proposed changes to the reference classes
in the interest of making them more 'generally suitable' to the
widest variety of JVM's, or making them require fewer changes when
ported to a new JVM, run up against backwards compatibility
issues, because any such change means some existing JVM somewhere
will probably have to be adjusted to accomodate.

For an example of this, there are lots of places in the reference
classes that say "this method will be removed in a future version of
classpath" yet there the method sits.

The tension between these two 'hands' seems to me likely to result
in a negative effect on the reference code, because you can't easily
make changes that improve anything. As a result, new JVM implementors
like me don't get as much value out of the 'reference' code.

I.e., in my (biased) opinion, ideally the 'reference' classes should
always reflect the combined wisdom of the Classpath developers'
about what the best, most correct way is to organize and partition
the Java code from the native code. If a new way to do something is
discovered, it should be natural and we should be quick to include
it in Classpath, even if that changes the Java <-> native API.

What I'd like to suggest is the following (donning flamesuit): the
goal of the 'reference' code should be explicitly changed so that
it reflects this 'best guess' at what an 'ideal' set of native
method classes should look like, and the goal of maintaining support
for existing JVM's in the 'reference' classes should be dropped.
In it's place, the existing 'reference' code can be (CVS repository)
copied into distinct 'vm' subdirectories for each JVM out there
that currently relies on it. These JVM's can then manage their
per-JVM classes as they see fit (some may not change anything,
others may try to migrate toward the 'reference' set).

For an existing JVM it's probably not worth the trouble do a lot
of adjustment work to the native method implementations just for
the sake of Classpath consistency. But for new JVM's, and for any
JVM's that prefer to keep their differences from Classpath at a
minimum and track the 'combined wisdom' of the Classpath developers,
there should be a way to do this (the goals of my particular project
make me lean much farther towards using the Classpath 'reference'
suite to benefit from that combined wisdom).

Moreover, a second goal for the 'reference' classes should be that it
is possible for a JVM to be implemented using them without any changes.
Having methods marked "XXX - Not implemented; this requires native help"
but not actualy native is neither here nor there.

Hope this makes sense and is not too simplistic a view to take,
as I'm new to this project. Comments?

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com