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: [modules] Packaging Class Libraries
Date Fri, 10 Jun 2005 14:14:29 GMT
Rodrigo Kumpera wrote:

>>>In terms of extensibility, the classlib is mostly a dead-end, an
>>>end-user should be better using some SPI. But good modularity keeps
>>>the software entropy low.
>>I am not sure what you are referring to with "classlib" here.
>The j2se lib, eg what classpath is implementing.

In that case, I agree that extensibility of the class library is a dead 
end, but that doesn't mean structuring it as a nice collection of 
modules with well defined relationships is a dead end.

>Well, the classpath folks seen to be doing just fine without an OSGi
>like container. There are some implications for building such thing,
>first is the fact that a big part would need to live in a
>"container-less" enviroment, as it would be hard to read a manifesto
>file without the java.io package available. ;)
It just depends on how you want to look at. I guess by that definition 
Sun would be doing fine too, but I have butt my head against Sun's 
implementation because it doesn't expect class loading delegation to be 
a graph so it can deadlock, for example. It also expects that all VM 
implementation classes are available from all class loaders, as another 
example. There are just numerous areas like these where it is 
problematic if you do not follow strict rules.

Again, I am not proposing using an OSGi container. I am proposing to use 
class loaders to enforce separation, that is all.

Also, I do recognize that there is more than one way to achieve similar 

I must admit, though, that I have an ulterior motive, which is the 
desire to see this sort of modularity functionality become available to 
application programmers themselves, so that they can get all of the 
benefits that I am describing.

I think this is a necessary step for Java if is wants to better position 
itself against .NET (assemblies and GAC).

-> richard

View raw message