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.
The API is private to the VM implementation, so the only effect it can
have on application code is how efficient it is.
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.
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)).
2. Keep the API reasonably easy to understand.
3. Don't worry about inlining Java code: assume the VM can do 'easy'
inlining like invoking static methods.
Again, just my opinion.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
