Re: Thoughts on 'reference classes'

[Stephen Crawley]

> Archie Cobbs <address@hidden> writes:
> 
> > The tension between these two 'hands' seems to me likely to result
> > in a negative effect on the reference code, because you can't easily
> > make changes that improve anything. As a result, new JVM implementors
> > like me don't get as much value out of the 'reference' code.
> > 
> > I.e., in my (biased) opinion, ideally the 'reference' classes should
> > always reflect the combined wisdom of the Classpath developers'
> > about what the best, most correct way is to organize and partition
> > the Java code from the native code. If a new way to do something is
> > discovered, it should be natural and we should be quick to include
> > it in Classpath, even if that changes the Java <-> native API.
> 
> How do other JVM developers feel about this sort of thing?  I don't
> like to make changes here myself because then I've nothing to use
> Classpath with until JVMs adjust!

Speaking as the most active Kissme maintainer, and the one on whose
shoulders the work will fall, I'm wary of changes to the reference 
classes and the native APIs they use.  It represents short term /
high priority work ... and I'd prefer to be doing things that make
Kissme more usable.

However, it one way to make things easier for most people would be
if the Classpath CVS was branched each time someone makes a change
(or set of changes) to the reference classes that is likely to
break compatibility with JVMs.  That way, JVM developers can migrate 
at a more leisurely pace.  Obviously, there needs to be a schedule
for merging such branches back into the main tree ... once the
important JVMs have been adapted.

> > What I'd like to suggest is the following (donning flamesuit): the
> > goal of the 'reference' code should be explicitly changed so that
> > it reflects this 'best guess' at what an 'ideal' set of native
> > method classes should look like, and the goal of maintaining support
> > for existing JVM's in the 'reference' classes should be dropped.
> > In it's place, the existing 'reference' code can be (CVS repository)
> > copied into distinct 'vm' subdirectories for each JVM out there
> > that currently relies on it. These JVM's can then manage their
> > per-JVM classes as they see fit (some may not change anything,
> > others may try to migrate toward the 'reference' set).
> 
> I think we'd like to not try to maintain 3rd party specific code
> within Classpath but rather let the reference code be maintained by
> JVM implementors in their own repository.  The first part you suggest
> may be okay if other JVM implementors agree.

We maintain own version of the VM reference classes that need to be
different for Kissme.  They live in the Kissme CVS repository, and
we don't intend to check them into the Classpath CVS repository.  We
handle integration by putting a ZIP file of Kissme specific classes
on the bootstrap classpath, ahead of the Classpath JAR file.

Historically, Kissme's VM classes came from an old version of Classpath
... well before the split between core and vm/ reference classes.  We
probably have too many (unnecessary) Kissme-specific classes, which
means that we don't benefit from some bug fixes made in Classpath.

When you say:

  "and the goal of maintaining support for existing JVM's in 
   the 'reference' classes should be dropped"

... I have to disagree.  I'm prepared to wear some migration cost for
adapting Kissme to changes in the Classpath vm reference classes and
APIs.  However, if the Classpath development process does not take
account of the ongoing support for old JVMs, those will stop working
or the they will get stuck on an old version of Classpath.  [This
happened to Kissme in the past, until we changed the build process
to work against a pristine Classpath checkout.  It has apparently
also happened to the current version of SableVM.]

> > Moreover, a second goal for the 'reference' classes should be that it
> > is possible for a JVM to be implemented using them without any changes.
> > Having methods marked "XXX - Not implemented; this requires native help"
> > but not actualy native is neither here nor there.

This is an interesting goal, but I don't really see the value of it.
After all, it is easy to maintain replacements for a subset of the 
Classpath vm reference classes, provided the APIs aren't changing
all of the time.

I agree with you last sentence, provided that someone can come
up with a reasonable (useable) definition for the native methods in
question.

-- Steve