Stanley Ho's Blog

Updates on Modularity in the Java platform

There have been lots of exciting development and changes going on in the modularity areas recently.

Modularity discussions in JSR 277 and JSR 294 expert groups

In the past, the design work on modularity was split between two expert groups: JSR 294 was responsible for defining the language extension to support modularity in the Java programming language, while JSR 277 was responsible for defining the deployment aspect of the module system. The original rationale was that each expert group would have members with the most appropriate expertise to design what's best in each area for the Java platform. As it turned out, there were situations when experts needed to work at both the language and deployment levels, and a single expert group would have been more effective. To help make the discussions of modularity in Java more effective, Alex Buckley (the spec lead of JSR 294) has joined me to become a co-spec lead in JSR 277. In case you don't know Alex, he is *THE* language guy responsible for the Java Language Specification and the Java VM Specification, and I am very excited about this change. Our plan is to have all Java modularity discussions to occur in the 277 expert group from now on, and we hope this simplification will benefit everyone.

JSR 277 early draft review 2 specification (Coming soon)

Alex and I are currently in the middle of producing the JSR 277 early draft review 2 specification for the expert group to review and discuss. This specification will be quite different from the original JSR 277 early draft in the following ways:

1. New language support based on Alex's latest proposal. If you haven't been following the language discussion around modularity, the most significant change is that there will be a new module keyword in the Java programming language:

   module org.foo.app;
   package org.foo.app;
   module class Main {
      ...
   }

Defining a Java module will be as easy as declaring a module name using the new keyword. But ... what if you want to create a deployment module with metadata that could be used in the module system? Well, it will be as simple as defining a Java module with metadata annotations:

   //
   // org/foo/app/module-info.java
   //
   @Version("1.0")
   @ImportModules({
           @ImportModule(name="org.foo.library", version="1.0+")
   })
   @MainClass("org.foo.app.Main")
   module org.foo.app;

I won't dive into all the details here, but hope the example gives you some idea.

2. Incorporates inputs from EDR feedbacks and EG discussions on existing design and new features.

Since the original early draft was published, we have received many constructive feedbacks and most of them will be addressed in the upcoming specification. In addition, the specification will include details about resource modules (for internationalization), service/service-provider modules, etc. that have been defined by the expert group.

3. Reorganizes the specification to make the separation between the abstract module system framework and concrete module system implementation explicitly clear.

The original early draft actually has two separate parts: a framework for abstract module system, and a concrete module system implementation based on JAM (JAva Module). However, the distinction in that early draft was not clear because the focus of the original early draft was to gather feedbacks on the overall design rather than individual pieces. Bryan Atsatt, a very valuable contributor in the EG, recently suggested that a clear distinction between the two would help reduce a lot of confusion, and we agreed. This reorganization will happen and it will be one of the most obvious changes in the upcoming specification.

4. Validates the specification with the reference implementation.

We have been building the reference implementation (RI) through the Modules project in OpenJDK for quite some time now. The current RI has already implemented most of the functionalities as described in the upcoming EDR2, and we hope to bring the Modules project on par with the EDR2 around the same time when the specification is published. Stay tuned for more details.

Support OSGi bundles in the Java Module System

Mandy Chung and I have been working on a draft specification for supporting OSGi bundles in the Java Module System, and we have just made it available for the expert group to review and discuss. We understand that people who have invested heavily in OSGi would like to preserve their existing investment going forwards, and this is what we hope the support for OSGi bundles will enable. Check out Mandy's blog if you want to learn more.

JavaOne 2008

JavaOne is around the corner again. This year, Alex and I will be presenting a session and a BOF on modularity:

TS-6185: Modularity in Java™ Platform
Wednesday
5/7/2008
10:50 AM -11:50 AM

BOF-5032: Modularity in the Java™ Platform
Wednesday
5/7/2008
8:30 PM -9:20 PM

We'll go over the Java Module System from the language and deployment perspectives in details, and this will be a very technical and interesting talk. If you are attending JavaOne next week, we hope to see you in the session and BOF!

- Stanley

P.S. *random personal note* In the past year, I haven't been blogging much as I was on frequent leaves to deal with some family emergencies. The situation has been improving and I hope to blog more along with Alex and Mandy about all the exciting/interesting stuffs going on in modularity going forwards.

Comments

• Forgive my ignorance, but what is the rationale behind designing a new module system instead of using OSGi bundles for example? What are the main differences between OSGi bundles and the new module system?

  Posted by: mayhem on May 06, 2008 at 05:37 AM

• Question: when one is defining a module, why do you need to specify both "package" and "module"? Won't they always be the same, as seen in your example?

  Posted by: cowwoc on June 05, 2008 at 11:54 AM

• To clarify: what I am proposing is that you omit "module org.foo.app" from the example, and when javac encounters a module-scoped entity in the source-code it derives "module org.foo.app" automatically from the package name.

  Posted by: cowwoc on June 05, 2008 at 11:55 AM

This work is licensed under a Creative Commons License.