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.
I think that would be pretty interesting, actually. One of the hard challenges so far for me has been efficient support for 'profiles'[1] in class libraries. What I have done in Kaffe is just a simple mechanism to select the classes to build as part of a profile, but that usually drags in a superset of an API due to implementation internals required by added methods in later versions of a class, rather then a minimal implementaiton of just the classes, methods, fields, and their transitive closure.
My experiments with kaffe last year have shown me that it is possible to separate the class library into large chunks with certain ease, though unfortunately the maintenace of such a modular seperation is burdensome without tool support. From my cursory glance at the OSGi specs, it seems as the OSGi devs have put a good amount of though into dealing with the subject, so I'd be very interested to hear more about it, including about respective tools. :)
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.
Yes, I agree. To give an example, an unfortunately common mispractice that leads to unportable source code written in the Java programming language is the abuse of runtime-specific classes by non-runtime code to get access to runtime-specific services. Being able to, with relative ease, make sure that modules of a class library only export the interfaces specified in the specs would be pretty useful to help people avoid writing implementation-specific code.
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. :-)
Well, I am all ears. :) It would surely be interesting to be able dynamically update a runtime installation's class libraries, for example, or just it's JIT, if one can get the architecture right.
On a side note, I'd love to see such mechanisms work hand-in-hand with the native platform's package management, to avoid having to jump through multiple hoops to manage software.
cheers, dalibor topic
p.s. OSCAR already works on Kaffe & other GNU Classpath runtimes, right? I remember seing some mails from that direction :)
[1] Say 1.5, 1.6, Personal Java, ...
