From Rok.Strnisa at cl.cam.ac.uk Mon Sep 3 10:18:13 2007 From: Rok.Strnisa at cl.cam.ac.uk (Rok Strnisa) Date: Mon, 3 Sep 2007 18:18:13 +0100 Subject: [modules-discuss] iJAM: a proposal for improvement of JAM Message-ID: <7D93C6EE-D17F-46AC-BBEE-B3020D479807@cl.cam.ac.uk> 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 From mcconnell at dpml.net Mon Sep 3 12:42:23 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Tue, 04 Sep 2007 05:12:23 +0930 Subject: [modules-discuss] iJAM: a proposal for improvement of JAM In-Reply-To: <7D93C6EE-D17F-46AC-BBEE-B3020D479807@cl.cam.ac.uk> References: <7D93C6EE-D17F-46AC-BBEE-B3020D479807@cl.cam.ac.uk> Message-ID: <1188848543.7468.7.camel@gloria> Rok: There seems to be a problem with your API link: http://www.cl.cam.ac.uk/~rs456/iJAM/api/ /Steve. On Mon, 2007-09-03 at 18:18 +0100, 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-discuss mailing list > modules-discuss at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-discuss From Rok.Strnisa at cl.cam.ac.uk Mon Sep 3 14:06:27 2007 From: Rok.Strnisa at cl.cam.ac.uk (Rok Strnisa) Date: Mon, 3 Sep 2007 22:06:27 +0100 Subject: [modules-discuss] iJAM: a proposal for improvement of JAM In-Reply-To: <1188848543.7468.7.camel@gloria> References: <7D93C6EE-D17F-46AC-BBEE-B3020D479807@cl.cam.ac.uk> <1188848543.7468.7.camel@gloria> Message-ID: Hi Steve, Thank you for pointing this out. It has now been fixed. Regards, Rok On 3 Sep 2007, at 20:42, Stephen J. McConnell wrote: > Rok: > > There seems to be a problem with your API link: > > http://www.cl.cam.ac.uk/~rs456/iJAM/api/ > > /Steve. > > On Mon, 2007-09-03 at 18:18 +0100, 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 From njbartlett at gmail.com Tue Sep 4 04:21:18 2007 From: njbartlett at gmail.com (Neil Bartlett) Date: Tue, 4 Sep 2007 12:21:18 +0100 Subject: [modules-discuss] [modules-dev] iJAM: a proposal for improvement of JAM In-Reply-To: <7D93C6EE-D17F-46AC-BBEE-B3020D479807@cl.cam.ac.uk> References: <7D93C6EE-D17F-46AC-BBEE-B3020D479807@cl.cam.ac.uk> Message-ID: <66C33A49-3903-40E0-AC49-6F3458F458B4@gmail.com> 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 From Rok.Strnisa at cl.cam.ac.uk Thu Sep 6 08:05:53 2007 From: Rok.Strnisa at cl.cam.ac.uk (Rok Strnisa) Date: Thu, 6 Sep 2007 16:05:53 +0100 Subject: [modules-discuss] [modules-dev] iJAM: a proposal for improvement of JAM In-Reply-To: <66C33A49-3903-40E0-AC49-6F3458F458B4@gmail.com> References: <7D93C6EE-D17F-46AC-BBEE-B3020D479807@cl.cam.ac.uk> <66C33A49-3903-40E0-AC49-6F3458F458B4@gmail.com> Message-ID: <228AFAFD-5C76-4558-9D43-1A66C2B153F9@cl.cam.ac.uk> 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 From Tom.Marble at Sun.COM Wed Sep 19 08:33:49 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 19 Sep 2007 10:33:49 -0500 Subject: [modules-discuss] Test of Gmane Message-ID: <46F1415D.5010902@sun.com> Hi: This is a test message. If all goes well this message will soon appear in: http://gmane.org/info.php?group=gmane.comp.java.openjdk.modules.general Regards, --Tom