From Rok.Strnisa at cl.cam.ac.uk Thu Jul 5 10:11:10 2007 From: Rok.Strnisa at cl.cam.ac.uk (Rok Strnisa) Date: Thu, 5 Jul 2007 18:11:10 +0100 Subject: [modules-discuss] A paper about JAM Message-ID: Hello, A group of us have written a paper about the upcoming Java Module System (JAM). We would be grateful for any comments/suggestions before the OOPSLA camera-ready deadline on July 30, 2007. You can find the paper here: http://www.cl.cam.ac.uk/~rs456/ljam/paper.pdf Thanks, Rok From njbartlett at gmail.com Thu Jul 5 13:15:00 2007 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 5 Jul 2007 21:15:00 +0100 Subject: [modules-discuss] A paper about JAM In-Reply-To: References: Message-ID: <1791F110-18F6-48CC-900B-9359294D3D06@gmail.com> Rok, This is a very thorough and admirable work on the JSR 277 module system. However, in section 5 (Related Work), you make some highly inaccurate statements about OSGi. They appear to be based on statements in the original specification request for JSR 277 that have never been corrected. If you note the latest revision of the JSR 277 spec request, you will see that the comments it makes about OSGi refer to Release 3; however, Release 3 is obsolete: the current version is Release 4.1, so the comments are simply not relevant and should have been removed. It would be remiss of you and your colleagues to duplicate the mistake in an academic paper. To take the points about OSGi in order: 1) "OSGi has no compatibility semantics, i.e. all newer bundles are assumed to be backward-compatible" This is not true. In OSGi, dependencies are specified using the mathematician's syntax "[1.0.0,2.0.0)", i.e. brackets for inclusive and parentheses for exclusive. This example therefore amounts to what might be informally specified as version "1.x" or "1.0.0 inclusive to 2.0.0 exclusive". Since bundles can specify precisely which versions of their dependencies they require, there is no need to make assumptions about compatibility, and in fact no such assumptions are made. 2) "the access control is limited, i.e. bundles are either private or public to everyone (which is mainly due to flat service registry)" There are some problems here with your terminology. Services are different from bundles, so the service registry has no relevance to whether bundles are private or public. Furthermore, both bundle dependencies and service dependencies are subject to access control based on J2SE security primitives. Unfortunately since you do not seem to understand what bundles and services are, it's difficult to discern what your point here is intended to be. Can you please clarify? 3) "and it is not possible to have multiple versions of public bundles in memory at the same time" This is incorrect. Multiple side-by-side versions of the same bundle are entirely possible. 4) "There is also no automatic inter-service dependency checking, which can be error-prone in large projects." Again due to your misunderstanding about services and bundles, it is difficult to see whether you have a point to make here. Can you clarify what "automatic inter-service dependency checking" is, and why you believe it to be missing from OSGi? 5) "The framework does not define a standard way of discovering and deploying bundles from external sources" This is partially true, but it is by intention. The problem is that any such mechanism for deploying bundles from an external source to (say) an enterprise server is unlikely to be suitable for a mobile phone or other resource-limited environment. Therefore the core OSGi specification chooses to remain silent on this issue and allow extenders to provide mechanisms suitable for different purposes. Having said that, there is a repository implementation for the common J2SE case, the OSGi Bundle Repository or OBR. Also OSGi hopes to exploit the repository that will be developed for JSR 277, and therefore it is hoped that the JSR 277 repository is developed with other consumers in mind. 6) "[The framework does not define a standard way of] of discovering which services are available for deployment" Again, I think the services/bundles confusion is interfering with your point. Assuming you mean bundles, then this is incorrect. Assuming you mean services, it is partially correct. Some bundles offer services in a declarative way, making it possible to introspect those bundles to discover which services they offer. However other bundles offer services programmatically, and therefore cannot be introspected. 7) "[The framework does not define a standard way of] resolving a bundle if many match the required criteria, i.e. the resolution is not predictable is such cases" Also incorrect, please see section 3.7 of the OSGi Core specification, which describes the constraint solving process in the presence of multiple possible matches. The resolution is only unpredictable if multiple identical copies of a bundle are present, and since they are identical it hardly matters which is chosen. 8) "Even though OSGi is the most widespread framework for a Java module system [3, 4, 1, 2], it is by no means standardized, probably also due to its high flexibility." You appear to be using an unusual definition of "standardised". OSGi Release 4 is codified as JSR 291, making it every bit as standard as JSRs 277 and 294. In fact, 291 is a Final, fully approved JSR, whereas 277 is only at Early Draft stage and has multiple ballots to pass before it becomes a Java standard. It is also of course defined under the stewardship of the OSGi Alliance, a non-profit standard body with much wider industry representation that the JCP, and not beholden to a single vendor. 9) "Building a module system into the language has a higher chance of achieving standardization and compatibility of module interfaces between different software houses" OSGi has already achieved that standardisation and compatibility. A good example is the Eclipse IDE, which combines code from several cut- throat competitors such as IBM, BEA, Borland and Oracle into a single interoperable platform. At this point we can only speculate whether JSR 277 will be able to achieve a similar level of interoperability, but it already has one very large barrier to compatibility: it will only work on Java 7 and above. To summarise, I believe that you need to understand OSGi before repeating the inaccurate comments made about it in the JSR 277 specification request. If you would like to obtain that understanding then many members of the OSGi community would be happy to assist. If you are interested I can put you in touch with them. Kind regards, Neil Bartlett. On 5 Jul 2007, at 18:11, Rok Strnisa wrote: > Hello, > > A group of us have written a paper about the upcoming Java Module > System (JAM). We would be grateful for any comments/suggestions > before the OOPSLA camera-ready deadline on July 30, 2007. > > You can find the paper here: > http://www.cl.cam.ac.uk/~rs456/ljam/paper.pdf > > Thanks, > Rok > _______________________________________________ > modules-discuss mailing list > modules-discuss at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-discuss From mcconnell at dpml.net Thu Jul 5 22:31:50 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Fri, 6 Jul 2007 15:01:50 +0930 Subject: [modules-discuss] A paper about JAM In-Reply-To: References: Message-ID: <011301c7bf8e$f4c8a580$0301a8c0@julia> Rok Strnisa wrote: > We would be grateful for any > comments/suggestions before the OOPSLA camera-ready deadline > on July 30, 2007. I'm still working my way though the document but I hit the following statement at the end of section 3.6: "JSR-277 states that repositories will be implemented with classloaders." That doesn't seem correct to me. In the meantime I'll continue reading. Cheers, Steve. From mcconnell at dpml.net Fri Jul 6 02:21:15 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Fri, 6 Jul 2007 18:51:15 +0930 Subject: [modules-discuss] A paper about JAM In-Reply-To: <011301c7bf8e$f4c8a580$0301a8c0@julia> References: <011301c7bf8e$f4c8a580$0301a8c0@julia> Message-ID: <014201c7bfaf$015f6700$0301a8c0@julia> On shallow validation (section 3) ... This section addresses the pros and cons of depth-first validation (self, then imports) versus reverse depth-first fashion (imports, then self). The example in section 6.4 focuses on a scenario involving multiple duplicate fully qualified names (which according to 277 draft is an to avoided). However, the sources for the modules package includes a ModuleDefinition class which includes the AllowShadowing annotation which in effect moves us into a gray area (discussion of and/or mechanisms to allow shadowing are not discussed in the 277 draft but only appear in the sources at super-package level). From this rather loose platform the paper is asserting the following statement at the end of section 3: Therefore, the only guarantee validation gives is that, if it succeeds, there will be no unexpected behaviour due to the unnatural class lookup function. I think that some additional clarity is needed here - but I also think that depth-first versus reverse depth-first is a subject that has not been discussed to any significant extent (at least I have not seen this on the 294 or 277 lists). I think this subject is worthy of additional discussion (as I for one have some opinions critical of the scoping of AllowShadowing annotation). In effect - within section 3 the report makes a distinction between depth-first versus reverse depth-first (which is an opinion raised by the paper as opposed to an opinions put forward in the 277 draft - but all the same is an interesting opinion). The paper subsequently draws on this opinion in terms of the emphasis assigned to conclusions which appear to qualify 277 relative to concepts established in the paper. I.e. the modules stuff is in a gray area on this subject and the paper is asserting points of view but basing these points of view on its own assertions - and things get confused. Cheers, Steve. > -----Original Message----- > From: modules-discuss-bounces at openjdk.java.net > [mailto:modules-discuss-bounces at openjdk.java.net] On Behalf > Of Stephen J. McConnell > Sent: Friday, 6 July 2007 3:02 PM > To: modules-discuss at openjdk.java.net > Subject: Re: [modules-discuss] A paper about JAM > > > > Rok Strnisa wrote: > > We would be grateful for any > > comments/suggestions before the OOPSLA camera-ready > deadline on July > > 30, 2007. > > I'm still working my way though the document but I hit the > following statement at the end of section 3.6: > > "JSR-277 states that repositories will be implemented > with classloaders." > > That doesn't seem correct to me. > > In the meantime I'll continue reading. > > Cheers, Steve. > > _______________________________________________ > modules-discuss mailing list > modules-discuss at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-discuss From mcconnell at dpml.net Fri Jul 6 10:29:40 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Sat, 7 Jul 2007 02:59:40 +0930 Subject: [modules-discuss] A paper about JAM In-Reply-To: References: Message-ID: <019d01c7bff3$3c5af2e0$0301a8c0@julia> > -----Original Message----- > From: modules-discuss-bounces at openjdk.java.net > [mailto:modules-discuss-bounces at openjdk.java.net] On Behalf > Of Rok Strnisa > Sent: Friday, 6 July 2007 2:41 AM > To: modules-discuss at openjdk.java.net > Subject: [modules-discuss] A paper about JAM Minor stuff ... 1. I'm guessing that relative to the fragment on page 13 "i.e. the resolution is not predictable is such cases [17]" the 'is' should be replaced with an 'in'. 2. References: the reference [1], [2], [3], [4], [8] are not referred to in the document. 3. Reference [31] to JSR 294 should include the url http://jcp.org/en/jsr/detail?id=294 4. For completeness I would suggest adding a reference to the OpenJDK/modules project page http://openjdk.java.net/projects/modules/ Cheers, Steve. -------------------------- Stephen J. McConnell mailto:mcconnell at dpml.net http://www.dpml.net From mcconnell at dpml.net Fri Jul 6 10:50:34 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Sat, 7 Jul 2007 03:20:34 +0930 Subject: [modules-discuss] A paper about JAM In-Reply-To: <019d01c7bff3$3c5af2e0$0301a8c0@julia> References: <019d01c7bff3$3c5af2e0$0301a8c0@julia> Message-ID: <01a701c7bff6$27d810c0$0301a8c0@julia> > 2. References: the reference [1], [2], [3], [4], [8] are not > referred to in the document. Woops, my mistake - these references exist. However, I'm not sure that the reference to Apache Derby [1] is relevant (Derby is a database solution). /Steve.