Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4281FB92.1010601@ungoverned.org>
Date: Wed, 11 May 2005 08:33:22 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Class Library Modularity [Was Re: State of the World]
References: <m34qdcdxl6.fsf@localhost.localdomain>
 <42806577.6080503@ungoverned.org> <4281A571.6010304@realityforge.org>
 <4281BD0B.1040100@ungoverned.org> <4281D861.7070900@realityforge.org>
In-Reply-To: <4281D861.7070900@realityforge.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.

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. :-)

-> richard