[modules-discuss] [modules-dev] iJAM: a proposal for improvement of JAM

[Rok Strnisa]

Hi Neil,

Thank you for your email.

I read the details in the blog you pointed to. As far as I  
understand, OSGi framework tries to unify all bundles' class  
namespaces (load with as few classloaders as possible) in order to  
get the least number of ClassCastExceptions on the generated  
services. This is why the OSGi chooses a classloader-friendlier class  
lookup function (first (2), then (3)), and why it is better for users  
to import as well as export member Java packages (in order not to  
create distinct class namespaces). All this seems to rely on the  
following: importing a package in an OSGi bundle seems to import a  
global (combined) definition of that package (or it selects one  
(pseudo-randomly?) if more than one option exists; I would guess it  
chooses 'the most global option'), which can consist of classes  
defined in bundles not directly related to the importing bundle.

Here are a few comparisons to iJAM ("improved JAM"):

1) Importing
iJAM (as well as JAM) does not have a concept of a global (or  
combined) Java package. A module definition [bundle] can import  
another module definition [bundle], which causes *all* exported (and  
public) members of the imported module definition [bundle] to become  
visible in the importing one. Therefore, the visibility control is  
more localized and under the control of the developer of the  
importing module definition [bundle].

2) User's choice
In JAM, we are not dealing with services, but rather with individual  
classes. Suppose module definition [bundle] C imports module  
definitions [bundles] A and B (in this order), both of which define  
and export a class 'foo.T'. Then a class reference "foo.T" in C will  
resolve to the class A::foo.T, and not B::foo.T, since A was imported  
first.

One of the ways to improve this is to give the developer the ability  
to specify custom mapping in the module file of the importing module  
definition [bundle], e.g. "all class references "foo.T" in this  
module definition [bundle] should map to B::foo.T". This would, of  
course, only work if a class B::foo.T was visible in the context of  
the importing module definition [bundle].

3) Overriding
[Continuing the example from 2)] If C defined its own class 'foo.T',  
the class C::foo.T would override A::foo.T, i.e. the class reference  
"foo.T" in C would instead resolve to C::foo.T. This is exactly what  
happens with fields in class hierarchies, which is why we feel our  
approach is more intuitive.

4) Communication
[In context of example from 2)] Even though using a different class  
'foo.T', B can freely communicate with both A and C, just not using a  
'foo.T' class. The class A::foo.T (used by A and C) and the class  
B::foo.T (used by B) can have completely different definitions, so it  
makes sense that they are type-incompatible.

Feel free to play with my prototype of iJAM to see what I mean:
http://www.cl.cam.ac.uk/~rs456/iJAM/iJAM_impl.zip

Regards,
Rok

On 4 Sep 2007, at 12:21, Neil Bartlett wrote:

> Hi Rok,
>
> This is another interesting paper.
>
> Regarding the import rules which you describe as unintuitive, it's  
> worth noting that OSGi chooses the opposite solution to yours. As  
> described in section 3.8.4 of the OSGi R4 Core Specification, the  
> search order is as follows (in summary):
>
> 1) The parent classloader in the case of java.* or any package  
> included in the "boot delegation" package list.
> 2) Packages imported using Import-Package or Require-Bundle (i.e.  
> dependencies of the bundle in question)
> 3) The bundle's internal classpath
> 4) "Dynamically" imported packages (this mechanism exists primarily  
> to support certain types of "legacy" code)
>
> In your solution, steps (2) and (3) are switched. OSGi chooses this  
> ordering for the purposes of class space consistency, for example  
> it is considered good practice for a bundle that exports package  
> 'com.foo' to also import 'com.foo', enabling other bundles to  
> provide an alternative implementation. The following blog post  
> explains the reasoning for this better than I am able to:
>
> 	http://www.osgi.org/blog/2007/04/importance-of-exporting-nd- 
> importing.html
>
> I wonder if intuitiveness is necessarily the best criterion for  
> choosing the correct class search strategy?
>
> Kind regards,
> Neil
>
> PS I note that you have removed the incorrect information about  
> OSGi from your earlier paper -- many thanks for that.
>
>
> On 3 Sep 2007, at 18:18, Rok Strnisa wrote:
>
>> Dear all,
>>
>> At University of Cambridge, we have written, formalized and
>> prototyped a proposal for improvement of the Java Module System
>> (JAM). The main document describing our work can be found here:
>>
>>    http://www.cl.cam.ac.uk/~rs456/iJAM/iJAM_doc.pdf
>>
>> The other documents, including the implementation and the
>> formalization, can be found on the project's website:
>>
>>    http://www.cl.cam.ac.uk/~rs456/iJAM/
>>
>> Comments and suggestions very welcome.
>>
>> Sincerely,
>> Rok Strnisa