Geir Magnusson Jr. wrote:
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) 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?
In general a VMInterface class resides as a package private class in the
package that the class they help implement resides in. Using package
private, not-user-visible classes seems to be pefectly valid way to do
get similar things done in other, officially certified as compatible
implementations[1], so I don't think that having package private classes
means someone is extending the package's namespace, given that the
VMInterface classes are not exported to user code to compile against.
Therefore I think the term 'extension' is misplaced in this context. The
VMInterface classes are an internal (and very useful in practice) detail
of this particular class library implementation that does not extend the
namespace available to user code to link against. Extending the name
spaces would not be clever for all the obvious binary compatibility
reasons, after all.
The JCP may eventually specify classes in the future with the same
names. That could happen, and would be just fine. The JCP is obviously
free to call the specified classes any way they want, and if for some
reason the JCP decides to call some future 1.6 Object class VMObject, so
be it. :)
The internal GNU Classpath VM interface for Object would have to change
at that point, and things would move on just as they do all the time
someone changes the VM interface for a different reason. It currently
changes rather frequently in some areas, as people figure out new ways
how to implement the respective classes in a better fashion.
cheers,
dalibor topic
[1]
http://forum.java.sun.com/thread.jspa?threadID=591979&messageID=3091404
see java.io.UnixFileSystem class in the stack trace.
