Peter Donald wrote:
Richard S. Hall wrote:
However, while I agree that Sun's implementation does provide some modularity mechanisms, there seems to be two short comings:
1. The mechanisms themselves do not go far enough, they only provide minimal capabilities.
True but what more do you need at the runtime level?
Well, I can think of one thing I would like, some way for the packages contained in a JAR file be able to inform the underlying runtime not only its external dependencies, but also what it provides (or what it exposes). Due to limitations in the Java visibility/protection rules, sometimes it is not possible to avoid making implementation API public because you are forced to declare classes/methods as public if you need to use them from more than one package.
Of course, you could just put everything in the same package and use package protection, but that also defeats the purpose of trying to structure things into modules. So, for a module to be able to say that I export package "foo", but not "foo.FooImpl" would be very useful from my perspective. Then other packages inside the JAR are privy to implementation APIs, where packages outside the JAR are not.
I also have lots of interesting ideas about dynamic deployment/updates too, but I am sure that these things would be extension to the platform as opposed to implementing a conforming J2SE platform. :-)
-> richard
