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: <42830A29.4000904@ungoverned.org>
Date: Thu, 12 May 2005 03:47:53 -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>
 <4281FB92.1010601@ungoverned.org> <4282B05A.80502@realityforge.org>
In-Reply-To: <4282B05A.80502@realityforge.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Donald wrote:

> What you are asking for here is new language extensions - effectively 
> an "assembly" or "jar" access specifier to go along with private, 
> protected, public and package access. This would be very useful - 
> particularly if different jars/assemblies were of higher importance in 
> runtime. However it is not part of the Java standard and thus I 
> suspect that best way to achieve this goal is go through the jcp process.


Well, I think that this is certainly one approach to implementing what I 
am talking about, but certainly not the only way. Perhaps not even the 
best way. Maybe it is better to have such module constructs outside the 
language and part of the deployment/package layer. I don't know.

> You *could* implement this in Suns java by writing a custom 
> ClassLoader and using Annotations but ... unless it is part of a 
> standard somewhere it is unlikely to get broad adoption.


Well, this is exactly the kind of stuff that is being done with the OSGi 
framework. So that is sort of where I am coming from.

> You can implement this in suns java. Just write your own ClassLoader 
> to "hide" specified classes, set the ClassLoader as the bootstrap 
> classloader and it is done.


Yes, this is basically the approach. Unfortunately, there are lots of 
little "gotchas" in here, because if you hide the wrong classes, then 
you end up getting Sun's JVM throwing exceptions at runtime because it 
cannot find "sun.*" classes, for example.

It is hard to write code on Sun's JVM that is isolated from Sun's 
private API because there is an implicit assumption that every class 
loader leads back to Sun's impl classes and this assumption is required 
by Sun's libraries to function. This is not true of all JVMs however.

> I would love get my hands on the platform to implement Isolate and 
> Resource Managers as in Suns MVM (research JVM) as that would make 
> writing scalable applications in java so much easier.


I agree. I think these technologies are looking really interesting.

-> richard