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 Wed, 11 May 2005 08:06:35 GMT
Peter Donald wrote:

> Java already has the ability to define "Optional Packages"/Extensions 
> that have similar features to OSGis bundles. For an overview check out
>
> http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
>
> You can declare the id/version/vendor for both the specification and 
> implementation of a module. You can also declare dependencies on other 
> modules. However given the spagetti that the standard runtime is it 
> may not be entirely possible to do in a clean manner.


Yes.

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.
   2. They are not used, nor is their use really encouraged.

I won't deny that I have a biased point of view, but your point about 
the spaghetti code of the standard runtime is what I am trying to get 
at. It would be nice if Harmony defined some form of modularity 
(preferably a stronger form) and then followed the rules imposed by that 
modularity from the beginning to avoid getting into the spaghetti situation.

I am not necessarily saying the OSGi framework should be used directly 
(however, I do think that an OSGi-like layer on top of the JVM would 
make Java much more appealing when compared to .NET/Assemblies/GAC), I 
just hope that these ideas are considered from the beginning and not 
tacked on in some web page somewhere, which no one ever reads...like the 
above link.

So, if the decision is that existing modularity mechanisms are good 
enough, that's fine...just use 'em. I, for one, though, think it is 
possible to do better.

-> richard

Mime
View raw message