[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: API clean up patch

From: Archie Cobbs
Subject: Re: API clean up patch
Date: Wed, 18 May 2005 10:38:45 -0500
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129

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 Cobbs      *        CTO, Awarix        *

reply via email to

[Prev in Thread] Current Thread [Next in Thread]