Re: API clean up patch

[Archie Cobbs]

Andrew Haley wrote:
> When the VMblah classes were first introduced, the justification was
> that they would isolate platform-specific code.  Each VM would have
> its own versions of these classes.  But expecting any VM to run
> Classpath without modifying the VMblah classes as was the original
> intention is IMO quite unreasonable.

Why do you say that? The current API seems like a reasonable one to me.
JC runs fine with just a few modifications (even fewer after this patch).

>  > I'm only trying to make it at least theoretically possible for a VM
>  > to use Classpath unmodified and still function properly.
>
> To what end?

Here are a couple of reasons..

- It allows multiple VMs to share the same "stock" Classpath installation

- Fewer Classpath "diffs" means an easier burden of merging Classpath
  changes into each VM's customized versions of the VMFoo classes.

- It just plain looks dumb for the API to be inconsistent.

For example, right now JC has to carry around 9 different customized
Classpath files. Every time Classpath upgrades, I have to manually
merge in the changes, etc.

I'd like the number of these "custom" files and the size of the diffs
to be as small as possible.

To achieve this, I'm willing to adapt to the VM interface as Classpath
defines it, to the extent I can. But when that interface is inherently
broken, there's no way to do that.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com