On Jul 10, 2005, at 5:21 PM, Archie Cobbs wrote:
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.
Rather, what's more important is making the runtime transitions
into and
out of the JVM (i.e., through this API) seamless. This is mostly a
property of the VM implementation rather than the API design.
Hm. I'm not sure if I agree, as I can think of some really awful
APIs between the VM and the classlibrary. XML, for example...
public String exec(String xmlInput)
(wait, that's the semantic description of webservices, isn't it...)
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.
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...
Classpath has defined a reasonable API. I can't imagine how
rearranging
the API dramatically would make things noticably better, either in
performance or code clarity/maintainability.
That's just the question I'm interested in exploring. I'm not
starting out with an predetermined answer, but rather know that there
are others in the universe that have thought about this, and am
interested in what they think.
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?
Can't comment on the 1.5 aspects, but the design goal of Classpath
seems to have been a combination of:
1. Make the set of VM native calls not too far from the minimal
possible set (i.e., don't add native methods for things that can
be done fairly easily in pure Java (plus other native methods)).
yep - that makes sense.
2. Keep the API reasonably easy to understand.
yep
3. Don't worry about inlining Java code: assume the VM can do 'easy'
inlining like invoking static methods.
How does that aspect matter to the VM/classlib interface?
geir
Again, just my opinion.
-Archie
______________________________________________________________________
____
Archie Cobbs * CTO, Awarix * http://
www.awarix.com
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
