I think that this is a good topic that many around here have
experience with and can get involved in.
I think that it's not breaking new ground to say that we'll need a
standard interface between the VM and the classlibrary, to let people
integrate the various VMs and class libraries that we'll probably see.
The GNU Classpath project has documented what they need
http://www.gnu.org/software/classpath/docs/vmintegration.html
and this seems to break down to :
1) Some sort of initialization protocol (currently seems to be
defined in code, and only up to v1.1 - that may be stale docs...)
2) Core classes implemented by the VM for class-library usage
- standard - things that you expect in java.lang (java.lang.Object)
- non-standard - extension to java.lang (java.lang.VMObject)
3) VM hooks into the classlib
4) RMI stuff
Clearly this is one model, and one that works because it's been used
by many integrations. Now, questions :
0) Standing back from this specific model, can the model be generalized?
1) Are there other models? How do some of the commercial VMs do it?
2) Are there things that the GNU Classpath model is missing due to
the version of the API it's implementing? (I.e. they don't realize
they need it yet...)
3) I was uncomfortable with extending java.lang. I understand the
argument - that as they are package private, the language can be
depended upon to keep them safe from user code using them rather than
some security infrastructure. However, isn't this a bit dangerous in
terms of standard java.lang changes colliding?
I'd like to drive to a standard interface that we can all agree on,
and hopefully GNU Classpath will support it. This would insulate us
from the ongoing legal discussion surrounding the license, and let us
get on with using it directly.
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
