[modules-discuss] A paper about JAM
njbartlett at gmail.com
Thu Jul 5 13:15:00 PDT 2007
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
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
Again, I think the services/bundles confusion is interfering with
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.
On 5 Jul 2007, at 18:11, Rok Strnisa wrote:
> 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:
> modules-discuss mailing list
> modules-discuss at openjdk.java.net
More information about the modules-discuss