Stephen Crawley wrote: > "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
I guess what I meant by that was that the 'reference' classes should ultimately become stable (or at least their native methods should). Once this happens, maintaining support with existing JVM's (that work with the stable reference classes) will become automatic. I'm willing to tolerate a "one time" set of major incompatibility changes if that's what's required to (a) remove JVM-specific hacks that are not generally useful and (b) achieve a stable, "best common wisdom" set of classes -- assuming such a thing (b) is possible. Also, there's no reason the existing set of classes can't also be kept around. Maybe we should have "vm/reference" and "vm/idealized" or something. > > > 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. It's even easier to not maintain replacements :-) Cheers, -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
