Quoting Etienne Gagnon ([EMAIL PROTECTED]): > It would be impractical (or even maybe impossible) to setup a *single* > "classpath" installation on a user system, meant to be used by distinct > VMs/compilers on this same system; one can simply think of the ever > changing VM interface, VM-specific issues, etc.
While that is currently true, one would hope that the virtual machine interface will stabilize over time. At that point, Classpath developers should make sure not to introduce incompatible changes to virtual-machine related classes without making a new major release and announcing it properly anyway. Virtual machine targetting that stable classpath release could then share most of the core classes and Distributions like Debian could then ship the classpath zip-file, reusing it for all virtual machines included. The exception are, of course, the VM* classes, which virtual machine packages will include. The VM will put its own customized versions of these classes into its bootstrap classpath to override default versions (if any) included in the standard classpath installation. BTW, on the topic of VM* classes: Has there been agreement on java.lang.VMClass? The proposal was to make its methods static (and possibly add an "Object vmdata" field to java.lang.Class instead). David
pgp00000.pgp
Description: PGP signature
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
