harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: [arch] VM/Classlibrary interface
Date Fri, 27 May 2005 17:40:08 GMT
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.

dalibor topic

see java.io.UnixFileSystem class in the stack trace.

View raw message