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
