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
|