harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Class Library Modularity [Was Re: State of the World]
Date Thu, 12 May 2005 07:32:40 GMT
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

Mime
View raw message