On Thu, 2004-03-25 at 13:17, David Lichteblau wrote:
> 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.
Yes, at some point it might be possible, though given the size of
today's disks - it might not matter that much.
But even such case does not imply that these VM-specific binaries (which
each JVM would have in its bootclasspath) could not come from one
source. Such single source would allow to share almost all of the code
(that is all maintenance, bugfixes and improvements), surrounded by
minimal, compile-time-conditional VM-specific tweaks.
Grzegorz B. Prokopski
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
