[modules-discuss] [modules-dev] iJAM: a proposal for improvement of JAM
njbartlett at gmail.com
Tue Sep 4 04:21:18 PDT 2007
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:
I wonder if intuitiveness is necessarily the best criterion for
choosing the correct class search strategy?
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:
> The other documents, including the implementation and the
> formalization, can be found on the project's website:
> Comments and suggestions very welcome.
> Rok Strnisa
> modules-dev mailing list
> modules-dev at openjdk.java.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the modules-discuss