harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 11 Jul 2005 18:11:47 GMT

On Jul 11, 2005, at 11:36 AM, Archie Cobbs wrote:

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

> Now, there may be public methods such as Thread.start() that just
> happen to be implemented via native method calls directly into the
> VM, but those are degenerate cases. The application doesn't "know"
> that things happen to be implemented that way and that it might be
> making a direct native call into the VM.


> By the way, Classpath avoids any such degenerate cases: all methods
> in class Foo that could be native instead are called through a
> "liason" class VMFoo. So all of the Classpath/VM API native methods
> are non-public. (This is why I said Classpath assumes the VM can
> do "easy" inlining, because of the Foo -> VMFoo extra hops).


> The API that applications use is defined by the public classes and
> methods in the class library. How those classes are implemented is
> not known to the application (and the application shouldn't care).
> Which ones actually involve calls into the VM is irrelevant.

Right - and I'd argue that how the VM/classlib interface is  
implemented by the VM is not known to the class library and the class  
library shouldn't care.

> E.g., have you ever seen the Javadoc for a method contain the
> "native" keyword? No -- that keyword is stripped out because it's
> irrelevant from an API point of view (so is "synchronized").
> Instead, those are implementation details.
> 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.

>> For example, when people were porting their platforms to use GNU   
>> Classpath's API, what did they think?  Did they have to redo  
>> anything  internally?
> In my experience, things mostly made sense, but there were definitely
> some problems. However, they were there more because nobody had gotten
> around to fixing them, rather than some conflict of API design vision
> or anything like that.
> For example, the API call to load native libraries didn't have a
> ClassLoader parameter. But that is required to properly implement
> Java 2 style class loading (and unloading). So we added one. There
> was nothing controversial about it. Similarly for lots of other stuff.


> In other words, there hasn't been much debate on the Classpath lists
> about APIs. It's pretty straightforward, and in for the most part the
> little details don't matter that much anyway. This is why many of  
> us who
> work on Classpath are wondering why anyone would bother wondering how
> to reinvent the wheel, when the wheel already rolls just fine :-)


> Cheers,
> -Archie
> ______________________________________________________________________ 
> ____
> Archie Cobbs      *        CTO, Awarix        *      http:// 
> www.awarix.com

Geir Magnusson Jr                                  +1-203-665-6437

View raw message