Geir Magnusson Jr. wrote:
Ok, from the school of "Storming the Gates! Take 2", lets again
examine the question of VM/classlib interface as this is an
important aspect to address and our first run at it wasn't so
successful.
The questions I have are all around the different ways has this
been done. So far we know about GNU Classpath, but I assume there
are others. What I'm specifically interested in is :
- what were the architectural goals
- what mistakes made in the past did you try to avoid
- what are the known limitations
- does the interface support our target version of 1.5
Just my opinion: I don't think the VM/classlib API matters that much.
Seriously... I've never done VM work, but system-level work that I have
done can live or die based on the API, for all sorts of reasons, like
performance, the ability to elegantly evolve over time, etc.
I think you're right -- in general -- that API design can have a major
impact on things. I'm just saying that in this specific case it doesn't
look like it's so critical (to me).
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).
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.
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.
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
