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
[EMAIL PROTECTED]
