[modules-discuss] [modules-dev] iJAM: a proposal for improvement of JAM
Rok.Strnisa at cl.cam.ac.uk
Thu Sep 6 08:05:53 PDT 2007
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"):
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
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].
[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.
[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:
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:
> I wonder if intuitiveness is necessarily the best criterion for
> choosing the correct class search strategy?
> Kind regards,
> 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
More information about the modules-discuss