Re: Thoughts on 'reference classes'

[Mark Wielaard]

Hi,

On Fri, 2003-02-28 at 04:17, Stephen Crawley wrote:
> 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.

I am certainly willing to help make sure that Kissme will stay useable
with current CVS. I am always using it when hacking on Classpath (or
even libgcj) to make sure that I don't break things.

> 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.

This is how I think all VMs should do it BTW.

> 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.]

Hopefully some of the things that are now in your specific VM reference
version (like e.g. Runtime, which Classpath doesn't currently provide an
native reference implemenentation for) can be moved into the Classpath
reference implementation if you want to donate them.

I think the problem with SableVM is that it has its completely own build
system. That makes updating to newer versions of Classpath very hard. I
used to use sablevm but since it didn't keep up with CVS I stopped using
it. Adapting the build process such as Kissme has done so you can track
CVS changes easily (if they are not to big of a change to the VM
interface) has been really helpfull. Thanks.

Cheers,

Mark