harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: Class Library Modularity [Was Re: State of the World]
Date Wed, 11 May 2005 13:27:37 GMT
Richard S. Hall wrote:
> 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.

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, ...

View raw message