harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tor-Einar Jarnbjo <Tor-Ei...@Jarnbjo.de>
Subject Re: [arch] VM/Classlibrary interface
Date Fri, 27 May 2005 20:17:27 GMT
Geir Magnusson Jr. wrote:

> 1) Are there other models?  How do some of the commercial VMs do it? 

Sun are generally using two different approaches:

- package private classes in the common java.* and javax.* packages, 
which are protected from external usage by the language protection model

- proprietary classes in the com.sun.* and sun.* packages, which are in 
theory accessible to application programmers, but should only be used 
through the java.* and javax.* APIs to avoid dependencies to a specific 
VM implementation

I think both approaches are completely valid and there is no need to 
enforce a specific way to do this. The first possibility has the 
disadvantage you mention, that Harmony may decide to implement an 
internal class java.lang.Foo and Sun decides to add a new class 
java.lang.Foo to the next Java version. The second possibility has the 
advantage, that you are in full control of what recides in the 
org.apache.harmony packages, but the disadvantage that a programmer may 
decide to actually use these classes and hence make his program 
dependent on the Harmony VM implementation. Unfortunately, some Apache 
software actually does rely on com.sun classes, e.g. the SSL connectors 
in Tomcat.

Tor



Mime
View raw message