Re: Classpath build process and VM-specific issues

[Tom Tromey]

>>>>> "Etienne" == Etienne Gagnon <address@hidden> writes:

Etienne> VM*.java Classes
Etienne> ================

Etienne> As far as I know, SableVM does not need any really "SableVM-specific"
Etienne> .java classes.  It only need *minimal* changes in the "reference"
Etienne> implementation to work.  I can easily imagine other VMs (such JamVM)
Etienne> being in the same situation.

BTW, another thing that came up on irc is that we could share some
code inside the JNI implementation, for instance argument parsing for
JNI_CreateJavaVM.

Etienne> [talking of normal package tree:  would anybody object to moving the
Etienne>   whole tree to an src/ subdirectory, as it should be done in such
Etienne>   a big project?]

Personally I'd prefer no change, since moving stuff around is a pain
with cvs, and since there doesn't seem to be a really big benefit from
it.

Etienne> I would very much like all the VM-specific code moved to VM*.java
Etienne> package-private classes, but these classes should reside in the
Etienne> *normal* package tree, not in a vm/ subdirectory.

Etienne> Grzegorz Prokopski and I are working on a set of m4 macros
Etienne> (that would not require understanding "m4" to be used) to
Etienne> allow minimal customization of VM*.java classes for each VM,
Etienne> while retaining most of the code sharing across all VMs that
Etienne> can work with the default VM*.java setup. [Some VMs, like
Etienne> JikesRVM tend to completely replace some base classes by
Etienne> their own; SableVM does not].

Etienne> The objective: Share as much code between "normal" VMs (that
Etienne> need nothing really special in base classes), and intuitive
Etienne> source file locations.

It does seem to me that most "ordinary" (C-based, Unix-y platform) VMs
could share a lot of this code.

Moving it out of the vm/ subdirectory, I don't know.  It seems like
that would prioritize these VMs over the weirder ones.  Personally I
don't see it as that big of a problem to have the VM* classes in a
separate directory hierarchy.

I talked with Grzegorz a bit about this on irc the other day.  One
question I have is, how are we going to test changes to the VM* code
if the m4 processing step is in place?

Right now, the reference code is just reference code, so we can make
changes to it on a theoretical basis.  This is both good (we can make
it more correct) and bad (we can't test it).  It does imply that
changes to this code have to be tracked by VM implementors and then
integrated into their versions of these classes.

With the m4 scheme, it seems like we would have to test any change to
these classes against all VMs using them.  In other words, the
maintenance burden gets pushed onto all of us, instead of the
particular VM implementors.

Of course the positive aspect here is that bug fixes can be more
immediately shared, and we can actually test the VM* code.  Which is
a big plus.

What do you propose for the testing part of this change?

Tom