Stanley Ho's Blog: JavaOne Archives

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.

OpenJDK and Modules

Posted by stanleyh on May 08, 2007 at 07:16 PM | Permalink | Comments (2)

Unless you having been living in a cave, you should have heard that the OpenJDK is finally here today! :-)

I have been planning to make the JSR 277: Java Module System expert group mailing list publicly readable for quite some time now, but the infrastructure in jcp.org has been pretty unstable in the last two months to make this possible and usable. Now the OpenJDK web site is available and offers better infrastructure, I have made the observer mailing list available from there today. This mailing list is read-only, and you will be able to observe the EG traffic going forwards. If you are interested, be a subscriber today!

Another exciting news is that we have also created a Modules project on OpenJDK. This project will cover the reference implementation of the modularity specifications defined by JSR 277 and JSR 294 as well as the related work in the JDK. Although there aren't much information on this page at the point of this writing, the intention is to make the source code, discussion list, and other implementation-related documentations available soon.

Finally, I'll be presenting a session (TS-2318) on JSR 277 at JavaOne this Thursday 4:10pm-5:10pm. Alex and Andreas will also be presenting a session (TS-2401) on JSR 294 this Thursday 9:35am-10:35am. If you want to learn more about the latest development of JSR 277 and JSR 294, come to the sessions! I hope to see you all there.

Powered by
Movable Type 3.01D

java.net RSS Feeds