Re: Classpath build process and VM-specific issues

[Steven Augart]

Etienne Gagnon wrote:
> 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; 

I have a counterexample.  I just used /usr/local/classpath on my 
workstation to build JikesRVM (CVS head) and to run JamVM 1.1.1.

> So, I suggest to change the "configure.ac" to force "./configure" to
> require a "--with-vm=xxx" option.  In other words, there would not
> be a "default" Classpath configuration.  The motivation is that when
> a user builds a Classpath version, he intends to use it in some
> context.  There is no default set of options that would work for
> all possible uses of Classpath.  In fact, each possible "default"
> configuration would favor one VM or one compiler over the others.

I oppose this change on software engineering grounds.  I don't like 
the idea of Classpath having knowledge about particular VMs and what 
they need.  I see your point that different VMs may need different 
Classpath config flag combinations -- maybe I was just lucky that 
JamVM and Jikes RVM had compatible needs -- but I want to keep 
Classpath VM-independent.

As we discussed on the Sable VM developer's mailing list today, there 
is no requirement that all of the classes in a particular package be 
in the same .jar file.

Jikes RVM, like JC and Kissme, overrides a few GNU Classpath classes 
with its own implementation; the jar file containing the classes 
specific to Jikes RVM appears in the bootstrap class loader's (two 
element long) search path before GNU Classpath's library.
[...]

> [talking of normal package tree:  would anybody object to moving the
>  whole tree to an src/ subdirectory, as it should be done in such
>  a big project?]
I object.  Moving files in CVS is unpleasant.  (The different ways of 
doing so are discussed in the cvs.info page.  None of them is good.)

> Grzegorz Prokopski and I are working on a set of m4 macros (that would
> not require understanding "m4" to be used) to allow minimal customization
> of VM*.java classes for each VM, while retaining most of the code
> sharing across all VMs that can work with the default VM*.java setup.

This sounds very nice.  I would like to share more of our common 
infrastructure.

> [Some VMs, like JikesRVM tend to completely replace some base classes
> by their own; SableVM does not].

Jikes RVM's rvmrt.jar overrides exactly eleven non-VM* classes from a 
default Classpath installation's glibj.zip:

        java.lang.Class
        java.lang.Object
        java.lang.Thread
        java.lang.Throwable
        java.lang.ref.PhantomReference
        java.lang.ref.Reference
        java.lang.ref.SoftReference
        java.lang.ref.WeakReference
        java.lang.reflect.Constructor
        java.lang.reflect.Field
        java.lang.reflect.Method

--Steve Augart

--
Steven Augart

Jikes RVM, a free Virtual Machine:
http://oss.software.ibm.com/jikesrvm