[modules-discuss] A paper about JAM

Thu Jul 5 13:15:00 PDT 2007

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