Re: Classpath build process and VM-specific issues

[David Lichteblau]

Quoting Etienne Gagnon (address@hidden):
> 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

pgpW1zWAmhd_B.pgp
Description: PGP signature