Re: Thoughts on 'reference classes'

[Archie Cobbs]

Stephen Crawley wrote:
>   "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

I guess what I meant by that was that the 'reference' classes should
ultimately become stable (or at least their native methods should).

Once this happens, maintaining support with existing JVM's (that work
with the stable reference classes) will become automatic.

I'm willing to tolerate a "one time" set of major incompatibility
changes if that's what's required to (a) remove JVM-specific hacks that
are not generally useful and (b) achieve a stable, "best common wisdom"
set of classes -- assuming such a thing (b) is possible.

Also, there's no reason the existing set of classes can't also be
kept around. Maybe we should have "vm/reference" and "vm/idealized"
or something.

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

It's even easier to not maintain replacements :-)

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com