harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VM/Classlibrary interface
Date Fri, 27 May 2005 21:14:39 GMT

On May 27, 2005, at 4:17 PM, Tor-Einar Jarnbjo wrote:

> 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.

(Tomcat : I'd bet they fixed that (or will fix...))

Well, can't the VM just prevent non-kernel code from using them?   
Maybe overhead too high?

geir


>
> Tor
>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message