Java and security bits
First public specification of the Java Module System (JSR 277)
The early draft specification of the Java Module System (JSR 277) was posted this week. This is what I have been spending most of my time on recently, working with Stanley Ho (spec lead) on specification issues for the expert group and taking the lead on the core aspects of the alpha implementation.
The specification may seem dense, but the basic concepts are fairly straightforward. Start by reading chapter 1 and section 2.1. They also explain the main rationale for the Java Module System: the standard runtime deployment concepts of Java SE - classpath and jre/lib/ext - are insufficient for large systems that run code from many different parties within the same VM process (for example, Application Servers). People have managed to work around these limitations using the extensible features of the Java platform, in particular ClassLoaders. But that is error prone and the platform should really have a built-in standard solution.
The result are Modules, which have stable names, define their supported APIs, and their dependencies on other modules. A Module is packaged into a Java Module archive (JAM file), which is deployed into a Repository. There will be private, per-user, and per-system Repositories. At runtime, we create Module instances, automatically resolve their dependencies, and setup the appropriate ClassLoaders. This allows different Modules to coexist in the same process without interfering with each other.
The Java Module System takes advantage of JSR 294 which is called Improved Modularity Support in the Java Programming Language. It will result in language and VM specification changes that allow developers to define the module information in a Java source file, which is compiled and verified by javac. This construct will also be understood by the VM, which uses it to enforce access control.
An important aspect of the Java Module system is its pluggability. The Repository class is extensible allowing 3rd parties to deliver their own implementations. Similarly, we want to make Module itself pluggable to allow developers to use module systems not based on JSR 294 within the same framework, as long as that module system follows compatible concepts.
You should understand that the current spefication of JSR 277 is literally an Early Draft. Many details are missing and the API is tentative. The reason it was published is to gather feedback from the community. Send it to the expert group at jsr-277-comments@jcp.org.
Posted at 15:17 Oct 15, 2006 by Andreas Sterbenz in Modularity | Comments[7]
Posted by rayx on October 15, 2006 at 07:30 PM PDT #
Posted by eu on October 16, 2006 at 05:58 AM PDT #
Posted by Davide Raccagni on October 16, 2006 at 08:09 AM PDT #
rayx: OSGi has a different origin, but it is now being applied to similar problems. However, many of the big and small design decisions seem to differ, and of course those matter for the "look and feel" of a solution.
eu: the .module file will be defined by JSR 294. The discussion in that EG has not really started yet, but the thinking at Sun has been that it would be handled similarly to .class files, i.e. generated by javac and reified via a reflective API at runtime (much like java.lang.Class).
Davide: we plan to deliver JSR 277 and JSR 294 as part of JDK 7. That schedule is not yet decided yet, but extrapolating from history it could mean early access code sometime next year with the GA release maybe 18-24 months from now. We all would like to see Modules be available sooner, but that is difficult in particular because of the JLS and JVMS changes required by JSR 294.
Posted by Andreas Sterbenz on October 16, 2006 at 10:49 AM PDT #
Posted by Davide Raccagni on October 17, 2006 at 12:41 AM PDT #
Davide: the code will ship as a supported product in JDK 7 in something like 2 years, but early access code will be available as part of the JDK 7 snapshots much earlier than that. I hope most of the functionality will be there a year from now and some parts should be ready even before then. By that time, Sun's JDK implementation (including its JSR 277 code) will hopefully be open source, so you or anyone else will be able to take that code and use it as you see fit [*]. Such is the beauty of open source!
[*] I am not a lawyer. Make sure to to read the license agreements. Sun previously indicated the intention to use an OSI approved open source license for the JDK source code.
Posted by Andreas Sterbenz on October 18, 2006 at 02:05 AM PDT #
Posted by Dalibor Topic on October 18, 2006 at 07:36 AM PDT #