Re: Cleanly defining the VM interface

[Stephen Crawley]

> In my view the most important thing about the VMFoo classes is that
> they isolate (potentially) VM-specific functionality from general
> functionality so that I can modify/adapt each of them independently.
> If class A in written in a general way with a few dependencies on VMA
> then I don't have to worry about integrating patches to class A -
> things will just work. If I had to customize class A because I wanted
> to replace a native method then I have to hand integrate all
> subsequent patches.

Agreed 100%.  This is why I'm trying to get Kissme back into a state
where it can use the new Classpath Foo/VMFoo classes.  We basically
don't have the maintainer cycles to have own implementations of the
Foo classes, and keep them in step with bug fixes made to the Classpath
codebase.

> I agree that the extra level of indirection can become a performance
> issue, but I think that is a second-level concern. First I want the
> isolation and independence and I can get the functionality right. If
> then I determine that there are performance issues then I can choose
> which classes to "fold" together, and choose the accept the
> maintenance burden of those folded classes.

Again, agreed 100%.  If performance is a major concern, then the VM
implementors have no choice but to diverge from the Classpath Foo/VMFoo 
paradigm, and write / maintain their own implementations of the Foo 
classes.  Indeed, they would probably need to diverge from Classpath
no matter what Classpath did.

-- Steve