Sun’s Alex Buckley and Stanley Ho gave a technical session titled “Modularity in the Java Platform”. They are spec leads for JSR 277, “Java Module System,” which defines a distribution format and a repository for collections of Java code and related resources. It also defines the discovery, loading, and integrity mechanisms at runtime. Design work on modularity had been previously split between two expert groups. JSR 294 defined the language extension support modularity in Java, and JSR 277 defined the deployment dimension of the module system. Over time, it became clear that certain situations required experts to work at both the language and deployment levels and that a single expert group was needed. To that end, Buckley, the spec lead for JSR 294, joined Ho as co-spec lead in JSR 277, so all modularity discussions now occur in the 277 Expert Group.
Basically the Java Module System specifies a distribution format for Java code, plus a repository for storing collections or modules, and identifies how they an be discovered, loaded, and checked for integrity.
Alex Buckley, the Language Guy
Alex Buckley, who Stanley Ho has described as the “*THE* language guy responsible for the Java Language Specification and the Java VM Specification,” spoke for the first part of the session on the development side of the Java Module System. “What’s missing,” explained Buckley, “is something between the development time constructs that you program with and the deployment time constructs that exist at build time. Sun’s concepts of modules span development and deployment.”
Alex explained that the development goals for the Java Module System are two-fold. The first is to continue to promote modular programming in the language. To that end, they’re introducing a simple and easy to use first class module concept into the language. He remarked that although versioning and dependencies are used at deployment time, JSR 277 seeks to make those concepts “at least expressible in the language in metadata”.
The second development goal for the Java module system is to support a modularization of the platform itself of the JDK. “The Java SE 7 expert group will eventually decide the exact semantics of those profiles, but it seems fairly clear that a profile is going to be delivered as not just a set of packages, but a set of packages wrapped in a set of modules,” explained Buckley.
Stanley Ho and JAR Hell
Stanley focused on how the deployment module system will address “JAR hell” by defining a better distribution formant. “JAR hell” is a term used to describe the various ways in which the classloading process can end up not working. One such way is when a developer or deployer of a Java application has accidentally made two different versions of a library available to the system, and another is when two libraries (or a library and the application) require different versions of the same third library.
The default deployment model defined in JSR 277 is called the JAM (for Java modules) module system, which defines a standard file format called JAM.
For those who want a simple take-home message, I refer you to Ho’s blog comments on JSR 277, where he addresses coming modularity changes (I quote):
“1. 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."
In addition, Ho spoke of a draft specification he has been working on with Sun’s Mandy Chung to support OSGi bundles in the Java Module System that they have recently made available for the expert group to review and discuss.
See Also
OpenJDK Modules Project
JSR 277
TS-6185: Modularity in Java™ Platform
2008 JavaOne Conference
Janice J. Heiss
Basically the Java Module System specifies a distribution format for Java code, plus a repository for storing collections or modules, and identifies how they an be discovered, loaded, and checked for integrity.
Alex Buckley, the Language Guy
Alex Buckley, who Stanley Ho has described as the “*THE* language guy responsible for the Java Language Specification and the Java VM Specification,” spoke for the first part of the session on the development side of the Java Module System. “What’s missing,” explained Buckley, “is something between the development time constructs that you program with and the deployment time constructs that exist at build time. Sun’s concepts of modules span development and deployment.”
Alex explained that the development goals for the Java Module System are two-fold. The first is to continue to promote modular programming in the language. To that end, they’re introducing a simple and easy to use first class module concept into the language. He remarked that although versioning and dependencies are used at deployment time, JSR 277 seeks to make those concepts “at least expressible in the language in metadata”.
The second development goal for the Java module system is to support a modularization of the platform itself of the JDK. “The Java SE 7 expert group will eventually decide the exact semantics of those profiles, but it seems fairly clear that a profile is going to be delivered as not just a set of packages, but a set of packages wrapped in a set of modules,” explained Buckley.
Stanley Ho and JAR Hell
Stanley focused on how the deployment module system will address “JAR hell” by defining a better distribution formant. “JAR hell” is a term used to describe the various ways in which the classloading process can end up not working. One such way is when a developer or deployer of a Java application has accidentally made two different versions of a library available to the system, and another is when two libraries (or a library and the application) require different versions of the same third library.
The default deployment model defined in JSR 277 is called the JAM (for Java modules) module system, which defines a standard file format called JAM.
For those who want a simple take-home message, I refer you to Ho’s blog comments on JSR 277, where he addresses coming modularity changes (I quote):
“1. 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."
In addition, Ho spoke of a draft specification he has been working on with Sun’s Mandy Chung to support OSGi bundles in the Java Module System that they have recently made available for the expert group to review and discuss.
See Also
OpenJDK Modules Project
JSR 277
TS-6185: Modularity in Java™ Platform
2008 JavaOne Conference
Janice J. Heiss
Subscribe