[ 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
