Re: Thoughts on 'reference classes'

[Brian Jones]

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!

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

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

Okay.

-- 
Brian Jones <address@hidden>