BT

Oracle Publishes Report on the State of Java’s Module System

| by Abraham Marín Pérez Follow 8 Followers on Oct 12, 2015. Estimated reading time: 6 minutes |

Oracle's Java Platform Group chief architect Mark Reinhold has published a report on the State of the Module System, with an emphasis on what the modularization objectives are (and aren’t.) The publication has triggered comments among users due to the apparent overlap with existing frameworks, particularly OSGi.

As explained in the report, and fully detailed in JSR-376 and in the Module System project page, the module system is meant to address two omissions in the current Java accessibility model:

  • Reliable configuration: the current way components access classes from other components through the class path is considerably error-prone, particularly when attempting to use classes that aren’t in the class path or that are present multiple times.
  • Strong encapsulation: there is no way to restrict the classes that a particular component exposes to other components, every class categorised as public will be accessible from outside.

Full details can be found both in the report and in previous InfoQ articles, but to summarize, each component is typically (but not necessarily) represented by a jar file, which includes a module descriptor file called module-info.java with the following structure:

module com.foo.bar {

   requires com.foo.baz;

   exports com.foo.bar.alpha;

   exports com.foo.bar.beta;

}

The file is structured such that one or more lines of exports will indicate the packages that are to be accessible from other components, and where zero or more lines of requires will indicate the modules that are required by this module. This system provides a method for assessing at compile time whether the access types have the right visibility (i.e. they are public and exported by the required component), and at run time to assess whether the necessary modules are available, without having to inspect the full class path. It is here where the similarities with OSGi are manifest.

OSGi Background

OSGi is a modularization system and service platform for Java that implements a complete and dynamic component model. First proposed in 1998 with JSR-8 and with subsequent reviews being published over time (the last in 2014), OSGi allows the definition of bundles (akin to modules), which take the form of a JAR file with the following MANIFEST.MF file:

Bundle-Name: Hello World

Bundle-SymbolicName: org.wikipedia.helloworld

Bundle-Description: A Hello World bundle

Bundle-ManifestVersion: 2

Bundle-Version: 1.0.0

Bundle-Activator: org.wikipedia.Activator

Export-Package: org.wikipedia.helloworld;version="1.0.0"

Import-Package: org.osgi.framework;version="1.3.0"

(Sample taken from Wikipedia.)

It is apparent that in spite of the format differences, the intent expressed is similar to the Java Platform Module System. Indeed, the similarities between the Java Platform Module System and OSGi have been noticed since the initial attempts to modularise Java started in 2005 with JSR-277, the “Java Module System”. Initially aiming at Java 7, JSR-277 focused on easing distribution and execution of Java artefacts. Despite having a nearly identical name to JSR-376, that initiative had slightly different objectives; although it was tasked to fix the problem of "reliable configuration", it did not attempt to tackle the issue of "strong encapsulation". And in contrast to JSR-376, it also tried to add a versioning model to the Java artefacts. The similarities between these objectives and the functionality provide by OSGi were stark enough for the authors to initially consider OSGi as a solution, later discarding it reasoning that OSGi version control was too weak.

JSR-294 was created shortly after that, with the objective of implementing “Improved Modularity Support in the Java Programming Language”. Also aiming at Java 7, this JSR was created to add the concepts of modules (called “superpackages”) to fix the strong encapsulation problem; this concept aligns with the current Java Platform Module System project. Both JSR-277 and JSR-294 have been dormant ever since they were labeled as such in 2012, when the Java 7 target was dropped, and are superseded by JSR-376.

Another link between OSGi and the modularisation of Java can be found in JSR-291, "Dynamic Component Support for Java SE" (essentially an implementation for OSGi Service Platform Release 4). That JSR made a reference to JSR-277, the original Java Module System, to clarify the difference in scope of both initiatives: JSR-277 would focus on the static module definition to be used by Java, while JSR-291 focused on dynamic components that can be loaded and unloaded on runtime.

Finally, JSR-376 itself also makes a reference to OSGi, mainly to discard it as a valid solution because its scope was far greater than the Java Framework Module System spec.

Given all the above, it seems reasonable that a number of users would have difficulty differentiating the new Module System and OSGi. However, the conclusion is that the module system and OSGi are understood to be complementary systems serving different purposes, with OSGi being a framework built on top of Java to create an environment where bundles can be managed dynamically in an always-running application, and the module system being a new capability of Java itself that allows for tighter and easier control of statically managed modules.

Differences between Java Platform Module System and OSGi

To understand this a bit better, InfoQ talked to Holly Cummins, co-author of Enterprise OSGi in Action. While the following doesn’t intend to be a thorough description of the differences between the Java Platform Module System and OSGi, it provides the reader with a basic understanding of how different their objectives are.

On one hand, the new Module System in Java will provide an easy way to check visibility of packages and classes at compile time, however, when we asked whether OSGi’s bundles can be used in the same way, Holly declared that “the answer for this is surprisingly complex”.

OSGi dependencies are expressed in a bundle’s manifest, and there are two basic approaches to creating the manifest: "code-first" and "manifest-first". With the code-first approach (used in the bnd tool, and the maven bundle plugin), the list of dependencies isn't enforced at compile-time, it's actually generated at compile time. The compilation goes ahead in the usual way, and then the tooling works out what's needed at runtime based on what was needed at compile time. The alternate approach is manifest-first, which is used by the Eclipse PDE tooling. In this approach, dependencies are declared in the manifest, and the Eclipse IDE will use the manifest to work out what classes your code can see, and highlight cases where a dependency is missing. There's a PDE command-line build, and a Maven plugin called Tycho, and both of those enforce the dependencies at compile-time. However, it’s important to note that this visibility isn’t enforced by OSGi itself but by the tools accompanying PDE; since not all teams using PDE use one of those tools, and there's a possibility to miss a trick at compile-time.

Another key aspect of the new Module System is the ability to restrict the modules that a particular package is exposed to, useful in situations where a set of related modules need to access each other, but they shouldn’t be accessed beyond that. As indicated in Mark Reinhold’s report, this can be achieved using the following syntax:

module java.base {
   ...
   exports sun.reflect to
       java.corba,
       java.logging,
       java.sql,
       java.sql.rowset,
       jdk.scripting.nashorn;
}

OSGi didn’t initially have this capability, but when it was added it again went further than the objectives of the Module System. As Holly explains, “Any bundle can register a resolver hook, and that can be used to filter matches, so that packages are only exposed to specific bundles. You could use the same mechanism to do things as sensible as exposing packages to bundles which declare certain metadata, or as crazy as exposing a package only on Tuesdays”.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

A Tad Confused by Peter Kriens

The history of JSR is long and confusing but I am not sure this article helps to clarify the situation. I was especially puzzled by the last section, not sure how to relate this?

To summarize: The JSR376 proposal consists of a new accessibility mode for modules, a dependency model, and a service model. The dependency model is limited to wiring versionless modules within a given module path. (A class path for modules.) The real dependencies (with versions) will have to come from a build system using propriety conventions. The service model is based on the Java service loader model. Since resources will no longer be accessible between modules a modular extension was needed.

The new module accessibility will be eagerly used by OSGi to protect the runtime and probably enforce compile visibility. The service loader model will be transparently supported as it is already today. However, not sure what to do with the dependency model. The OSGi provides a much richer dependency model and many patterns (e.g. whiteboard, extender) that support popular application techniques that are far outside the ambition horizon of JSR 376.

JSR 376 will not provide any backward compatibility for existing applications except to run as a classic class path application. Applications that want to move to JSR 376 will have to go through the painful process of modularizing because JSR 376 will punish any illegal crossing of module boundaries. (A lot of people will discover that their babies are not as modular as they thought.) Many people claim OSGi is hard without acknowledging that modularizing applications is the hard part. Mostly because Java (EE) applications have so many unmodular practices. JSR 376 will demonstrate that OSGi was just the messenger and actually not the cause.

If you go to the pain of modularizing then OSGi seems a much better choice because of its maturity, support, tooling, and feature richness. We've got 15 years of experience and have tested solutions to virtually all the problems that you will encounter when you modularize. Since this article even confused me about OSGi you might be attracted to JSR 376 because it looks so much simpler. Heck, it is simpler! However, when you traverse down the modularization hole of your application you will quickly realize that those additional features OSGi provides actually solve your problems.

Re: A Tad Confused by Ant hony

I'm not sure what you meant to say with this
JSR 376 will not provide any backward compatibility for existing applications except to run as a classic class path application.

but isn't backward compatibility provided by the concept of "unnamed modules"?

As for OSGi: about 3 years ago I wanted to learn it, so I did the Apache Felix tutorials ( felix.apache.org/documentation/tutorials-exampl... ). Given that Felix is one of the major implementations, I thought that'd be a good starting point, but I found the tutorials to be quite poor (and even today, several examples are "Coming soon...", just as they were back then). Moreover, OSGi occured as rather chaotic to me: e.g. there was iPOJO, BluePrint, Declarative Services, ... and I had a hard time trying to figure out what the current best practices were.

In contrast: after reading the "The State of the Module System", it occurs as a natural extension to the Java platform and it all makes sense to me. In combination with the quick start guide, I already feel like I "got it". Of course, it's simpler & doesn't provide all the features OSGi offers, but I'm wondering: why would I need those features? Maybe it's, as you say, because I haven't traversed down the modularization hole yet, but at this point I feel JSR 376 will meet the needs of most applications.

What I would like to read a year from now, is a book with the following starting point: a JSR 376-modularized Java SE application, which uses ServiceLoader & CDI 2. And then goes on to explain its problems & how OSGi allows to solve them.

Re: A Tad Confused by Peter Kriens

Portability: Since modules will be encapsulated things like annotation processing will not work out of the box. Applications and spec providers will have to be adapted to take modules into account (and this is the way it should be).

About the tutorials. Yes, we are aware of it.Since OSGi has been around so long there is just a lot of stale and bad stuff from loads of different people. The OSGi enRoute project (enroute.osgi.org) is an attempt to provide an up to date easy entry in OSGi, hopefully we can get this at the op of Google searches.

Though I would love to accept the challenge to write your proposed book but I lack the funds to pursue this. What I could do is take a simple but typical application and port it to OSGi enRoute to show how powerful OSGi is. Pet store or do you have a better example?

Re: A Tad Confused by Ant hony

Thanks for your reply and mentioning the OSGi enRoute project in particular. It looks promising & has surely renewed my interest in learning OSGi. As for getting it on top of Google searches: searching for "OSGi tutorial" lists www.osgi.org/Technology/HowOSGi as the second result. However, there's no mention of the enRoute project there. So giving it a prominent place on that page would already help a lot in increasing its visibility.

An OSGi enRoute pet store example, which showcases how powerful it is, would definitely be nice. This would allow me to invert the idea of the book I proposed: take the example OSGi application & port it to a non-OSGi application myself (by trying to replace it with JSR 376, ServiceLoader and such). Then I'd see for myself what advantages OSGi has & where JSR 376 falls short.

Re: A Tad Confused by Peter Kriens

Thanks for the tips, will work with OSGi marketing to correct this.

Ok, I will look at the pet shop but it will take some time, I am not full time on this.

Project Jigsaw might be the best thing that could have happened to OSGi by Victor Grazi

Modularization is a new concept to most Java developers. OSGi may be light-years ahead of Project Jigsaw, but most Java developers still struggle to get their arms around it (Ant hony above expressing some common emotions.) and OSGi has accordingly struggled to break in.

That said, once modularization becomes part of the Java core tool set, developers will begin to embrace it en-masse, and as they do so, they will seek more robust and more mature solutions. Enter OSGi!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT