harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 11 Jul 2005 22:47:45 GMT
Geir Magnusson Jr. wrote:
>>>> The API is private to the VM implementation, so the only effect  it can
>>>> have on application code is how efficient it is.
>>> The API isn't private to the VM implementation, is it?  The   
>>> _implementation_ of the API is, but not the API itself - that's a   
>>> contract between the classlib and VM...
>> You're confusing two things: the API that applications use (which
>> is strictly a Java API you can read about via Javadoc) and the API
>> that the class library uses, via native method calls, to talk directly
>> to the VM. The latter is not publicly visible (and usually VM  specific).
> I'm not confusing them.  It's very clear to me.

Sorry, I see now that I misspoke.. "the API is private to the
VM implementation" should have been "the API is private to the
classlib/VM implementation", i.e., invisible to the application,
so it can't directly effect the application, so it's a private
issue to the JVM creators (where "JVM" includes the classlib), etc.

>> The application just sees a big Java class library. The class library
>> sees a handful of native methods into the VM. The VM sees an
>> operating system of some sort. Etc.
> Yes.  I understand all this.  And what I'm looking for is a way that  we 
> can define the VM<->Classlib interface (where I use "interface" in  the 
> 'set of contracts and specifications' sense rather than the Java  sense) 
> that reflects everything known to date in the community on how  to do this.

Right... and I'm still saying that although there may be different ways
to organize the API, I'm not aware of anyone claiming that it makes
very much difference in the end... would like to hear if anyone does.


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

View raw message