> Archie Cobbs <[EMAIL PROTECTED]> writes: > > > 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. > > How do other JVM developers feel about this sort of thing? I don't > like to make changes here myself because then I've nothing to use > Classpath with until JVMs adjust!
Speaking as the most active Kissme maintainer, and the one on whose shoulders the work will fall, I'm wary of changes to the reference classes and the native APIs they use. It represents short term / high priority work ... and I'd prefer to be doing things that make Kissme more usable. However, it one way to make things easier for most people would be if the Classpath CVS was branched each time someone makes a change (or set of changes) to the reference classes that is likely to break compatibility with JVMs. That way, JVM developers can migrate at a more leisurely pace. Obviously, there needs to be a schedule for merging such branches back into the main tree ... once the important JVMs have been adapted. > > 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). > > I think we'd like to not try to maintain 3rd party specific code > within Classpath but rather let the reference code be maintained by > JVM implementors in their own repository. The first part you suggest > may be okay if other JVM implementors agree. We maintain own version of the VM reference classes that need to be different for Kissme. They live in the Kissme CVS repository, and we don't intend to check them into the Classpath CVS repository. We handle integration by putting a ZIP file of Kissme specific classes on the bootstrap classpath, ahead of the Classpath JAR file. Historically, Kissme's VM classes came from an old version of Classpath ... well before the split between core and vm/ reference classes. We probably have too many (unnecessary) Kissme-specific classes, which means that we don't benefit from some bug fixes made in Classpath. When you say: "and the goal of maintaining support for existing JVM's in the 'reference' classes should be dropped" ... I have to disagree. I'm prepared to wear some migration cost for adapting Kissme to changes in the Classpath vm reference classes and APIs. However, if the Classpath development process does not take account of the ongoing support for old JVMs, those will stop working or the they will get stuck on an old version of Classpath. [This happened to Kissme in the past, until we changed the build process to work against a pristine Classpath checkout. It has apparently also happened to the current version of SableVM.] > > 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. This is an interesting goal, but I don't really see the value of it. After all, it is easy to maintain replacements for a subset of the Classpath vm reference classes, provided the APIs aren't changing all of the time. I agree with you last sentence, provided that someone can come up with a reasonable (useable) definition for the native methods in question. -- Steve _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
