harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Class Library Modularity [Was Re: State of the World]
Date Tue, 10 May 2005 07:40:39 GMT
Tom Tromey wrote:

>* com.sun.*.  Those pesky java programmers often end up using unfree
>  APIs.  I'm not sure what Harmony could do here; maybe pressure Sun
>  into make it much more difficult to do this?

Just to raise the point about class library modularity again, since it 
is related to this comment. Access [and assumptions about access] to 
these types of classes is problematic when trying to implement stronger 
Java modularity mechanisms, such as is the case with the OSGi framework.

If it is possible to adopt a stronger modularity model, then it is 
possible to eliminate these types of issues. As an example, libraries 
packaged for OSGi in a bundle JAR file must explicitly list their 
package import/export dependencies; thus, it is trivial for them to 
ensure that implementation classes are not visible to the outside world.

It would be nice to see all of the libraries accompanying a JVM be more 
module-like, with dependencies and contributions explicitly listed, 
making it possible to statically and dynamically verify and deploy 
various configurations of a Java platform.

I do not claim to be a Java spec expert, so I do not know what aspects 
of these ideas are covered by the spec, but I do know that certain 
assumptions made by the Sun implementation make it more difficult to 
achieve module isolation (such as the assumption that JVM implementation 
classes like sun.* and com.sun.* are available from any class loader, 
including application class loaders, which results in the issue raised 
above by Tom Tromey). If these things can be improved while remaining 
J2SE compliant, then it is a step in the right direction.

-> richard

View raw message