Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42978057.7080403@Jarnbjo.de>
Date: Fri, 27 May 2005 22:17:27 +0200
From: Tor-Einar Jarnbjo <Tor-Einar@Jarnbjo.de>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM/Classlibrary interface
References: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org>
In-Reply-To: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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