Re: Classpath build process and VM-specific issues

[Robert Lougher]

Hmmm,

To be honest, I can't see the point in adding yet another level.  The VM 
classes aren't that many or very big so it's not a big deal if most of the 
code is duplicated.  You can get carried away with abstraction :)  How many 
times have you had to preprocess a file to understand _exactly_ what it was 
doing when chasing a bug?  I don't want to have to do this with the VM 
classes.

I vote to leave it like it is.

Rob.

----Original Message Follows----
From: "Grzegorz B. Prokopski" <address@hidden>
To: David Lichteblau <address@hidden>
CC: GNU Classpath <address@hidden>
Subject: Re: Classpath build process and VM-specific issues
Date: Thu, 25 Mar 2004 11:18:23 -0500

On Thu, 2004-03-25 at 13:17, David Lichteblau wrote:
> 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.

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
address@hidden
http://mail.gnu.org/mailman/listinfo/classpath

_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger