Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of tromey@redhat.com designates
 66.187.233.31 as permitted sender)
Sender: tromey@redhat.com
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM/Classlibrary interface
References: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org>
From: Tom Tromey <tromey@redhat.com>
Reply-To: tromey@redhat.com
Date: 27 May 2005 10:59:55 -0600
In-Reply-To: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org>
Message-ID: <m34qcopptg.fsf@localhost.localdomain>
Lines: 62
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Geir" == Geir Magnusson <geirm@apache.org> writes:

Geir> 4) RMI stuff

On irc Geir said that he meant "JNI" here.

Basically what this means, I think, is that Classpath has an
implementation of "jni.h", but the VM has to provide certain typedefs,
e.g., "jint".

Geir> 2) Are there things that the GNU Classpath model is missing due to
Geir>    the version of the API it's implementing?  (I.e. they don't realize
Geir>    they need it yet...)

Yeah, there are some needed additions for 1.5.  E.g., annotations
require new reflection info, and in the Classpath model this comes
from the VM layer.  This will all show up eventually, perhaps on the
generics branch.

Geir> 3) I was uncomfortable with extending java.lang.  I understand the
Geir>    argument - that as they are package private, the language can be
Geir>    depended upon to keep them safe from user code using them rather
Geir>    than  some security infrastructure.  However, isn't this a bit
Geir>    dangerous in  terms of standard java.lang changes colliding?

I don't think there is a killer failure mode.

First, note that it is both the language and the VM that implement
this protection.  This is crucial, as otherwise someone could easily
circumvent the protection at runtime.

Second, suppose Sun adds java.lang.VMObject to their public API.  What
then?

* A program written against Sun's new release that uses this feature
  will not work against our old release.  But that is already the case
  -- a program using a new API won't work against an older Classpath
  that doesn't implement it.  The choice of name doesn't matter.

* A program written against Sun's new release that uses this feature
  also won't compile against our old release.  But this won't work
  anyway either.

* To implement this new feature we would have to rename our VMObject
  and thus change the VM interface.  But that is also not a huge
  problem.  The VM interface can't remain fixed in general, because
  sometimes new features (see the 1.5 example) require additions to
  it.  (This does mean some churn for VM implementors, and it is
  inconvenient.  But it only breaks the VM, not anything else.)

* Finally, there's no way to compile a program against Classpath that
  uses the Classpath VMObject, due to the access protection.  So
  failures "the other way" aren't possible.

Geir> I'd like to drive to a standard interface that we can all agree on,
Geir> and hopefully GNU Classpath will support it.

Experience has shown that the Classpath approach is pretty flexible.
A wide range of VMs already use it.  Also we're pretty open to
specific needed changes.

Tom