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

[Neil Bartlett]

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
> _______________________________________________
> modules-dev mailing list
> modules-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/modules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/modules-discuss/attachments/20070904/5ff7adba/attachment.html