Dalibor Topic wrote:
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. :)
Yes, this is definitely something that could benefit from such a packaging mechanism. If it were possible to chunk the class libraries into modules, then without some mechanism to support/enforce this encapsulation the exercise becomes somewhat pointless.
Some of the features I am talking about are already available in the OSGi spec, but these ideas in general are definitely in the purview of the OSGi framework and the work done around it. I have an experimental release of Oscar that starts to deal with the issues we are discussing here...these things are of interest to the OSGi Alliance Core Platform Expert Group too.
I agree that these types of mechanisms require some sort of tooling support. One area that I want to investigate more is the generation of the module metadata by analyzing its byte code. There are already tools that do this for the R3 OSGi spec, so it should be possible to extend the approach to handle the metadata required for this type of encapsulation stuff too.
Unfortunately, the tool support is still coming up from behind. Maybe this will change now that Eclipse depends on OSGi as well.
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.
Exactly. This my thought too. Plus it ensures that the VM and standard libraries themselves do not do practices that make it difficult to do various deployment/management activities on top of the VM.
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.
Yes, these are the sort of thoughts I was having too as other people were having discussions about modular VM architectures.
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.
This is another valid issue, but one that I have not given that much thought to at this point.
p.s. OSCAR already works on Kaffe & other GNU Classpath runtimes, right? I remember seing some mails from that direction :)
I am aware of users using Oscar on Kaffe, yes. I try to keep it pretty neutral and try to fix issues if I get reports of difficulties.
-> richard
