Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200), reorganized the source code according to that structure (JEP 201), and restructured the JDK and JRE run-time images to support modules (JEP 220). The last major component, the module system itself (JSR 376 and JEP 261), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111.
Breaking changes Like the previous major change, the introduction of modular run-time images, the introduction of the module system might impact you even if you don’t make direct use of it. That’s because the module system is now fully operative at both compile time and run time, at least for the modules comprising the JDK itself. Most of the JDK’s internal APIs are, as a consequence, fully encapsulated and hence, by default, inaccessible to code outside of the JDK.
An existing application that uses only standard Java SE APIs and
runs on JDK 8 should just work, as they say, on JDK 9. If,
however, your application uses a JDK-internal API, or uses a library or
framework that does so, then it’s likely to fail. In many cases you can
work around this via the
-XaddExports option of the
commands. If, e.g., your application uses the internal
sun.security.x509.X500Name class then you can enable access to it via
This causes all members of the
sun.security.x509 package in the
java.base module to be exported to the special unnamed module
in which classes from the class path are defined.
A few broadly-used internal APIs that cannot reasonably be implemented
outside of the JDK, such as
sun.misc.Unsafe, are still accessible for
now. As outlined in JEP 260, however, these will be removed in a
future release after suitable standard replacements are available.
The encapsulation of JDK-internal APIs is the change you’re most likely to notice when running an existing application. Other relevant but, for the most part, less-noticeable changes are described in the risks-and-assumptions section of JEP 261.
If you have trouble running an existing application on JDK 9 build 111 or later, and you think that’s due to the introduction of the module system but not caused by one of the changes listed in JEPs 260 or 261, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com.
New features If you’d like to start learning about the module system itself, the video of my Devoxx BE 2015 keynote gives a high-level overview and The State of the Module System summarizes the design of the module system proposed for JSR 376. Further details are available in the six Jigsaw JEPs, listed on the main project page, and in videos of other sessions given at JavaOne 2015 and Devoxx BE 2015.
The module-system design will continue to evolve in the JSR for a while yet, based on feedback and experience. The implementation will evolve in parallel in the Project Jigsaw “Jake” forest, and we’ll continue to publish bleeding-edge early-access builds based on that code, separately from the more-stable JDK 9 builds.
As I wrote previously, Project Jigsaw is coming into JDK 9 in several large steps. JEP 200 defines the modular structure of the JDK, JEP 201 reorganizes the JDK source code into modular form, and JEP 220 restructures the JDK and JRE run-time images to support modules. The actual module system will be defined in JSR 376, which is just getting under way, and implemented by a corresponding JEP, yet to be submitted.
We implemented the source-code reorganization (JEP 201) last August. This step, by design, had no impact on developers or end users.
Most of the changes for modular run-time images (JEP 220) were integrated late last week and are now available in JDK 9 early-access build 41. This step, in contrast to the source-code reorganization, will have significant impact on developers and end users. All of the details are in the JEP, but here are the highlights:
JRE and JDK images now have identical structures. Previously a JDK
image embedded the JRE in a
jre subdirectory; now a JDK image is
simply a run-time image that happens to contain the full set of
development tools and other items historically found in the JDK.
User-editable configuration files previously located in the
directory are now in the new
conf directory. The files that remain
lib directory are private implementation details of the
run-time system, and should never be opened or modified.
The endorsed-standards override mechanism has been removed.
Applications that rely upon this mechanism, either by setting the
java.endorsed.dirs or by placing
jar files into
lib/endorsed directory of a JRE, will not work. We expect to
provide similar functionality later in JDK 9 in the form of
The extension mechanism has been removed. Applications that
rely upon this mechanism, either by setting the system property
java.ext.dirs or by placing
jar files into the
directory of a JRE, will not work. In most cases,
jar files that
were previously installed as extensions can simply be placed at the
front of the class path.
The internal files
dt.jar have been
removed. The content of these files is now stored in a more
efficient format in implementation-private files in the
directory. Class and resource files previously in
dt.jar are now always visible via the bootstrap or application
class loaders in a JDK image.
A new, built-in NIO file-system provider can be used to access the
class and resource files stored in a run-time image. Tools that
rt.jar and other internal
jar files directly
should be updated to use this file system.
We’re aware that these changes will break some applications, in particular IDEs and other development tools which rely upon the internal structure of the JDK. We think that the improvements to performance, security, and maintainability enabled by these changes are, however, more than worth it. We’ve already reached out to the maintainers of the major IDEs to make sure that they know about these changes, and we’re ready to assist as necessary.
If you have trouble running an existing application on JDK 9 build 41 or later and you think it’s due to this restructuring, yet not caused by one of the changes listed above or in JEP 220, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com. Thanks!
It’s now time to switch gears and focus on creating a production-quality design and implementation suitable for JDK 9 and thence Java SE 9, as previously proposed.
To begin this phase I’ve drafted a new document to collect goals and requirements. It reflects a new emphasis on security, as motivated by recent experience, it takes into account lessons learned from the prototype, and it’s written at a broader and more abstract level than the previous document so as not to over-constrain the solution space. This document will be one of the starting points of the upcoming Java Platform Module System JSR.
Jigsaw as a whole will bring enormous changes to the JDK; it would be unwise to wait until it’s completely finished before merging any of it. Our intent, therefore, is to proceed in large steps, each of which will have a corresponding JEP. The first three JEPs will propose a specific modular structure for the JDK, reorganize the JDK source code (but not binaries) along those lines, and then later modularize the binary images.
A fourth JEP will introduce the module system itself, which will be aligned with the module-system JSR. It may seem odd that the module system JEP comes last, but the earlier JEPs need make only minimal assumptions about its capabilities, hence work on them can proceed in parallel with work on the module-system JEP and JSR.
Comments, questions, and suggestions are welcome on the jigsaw-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.)
Thanks! A major new release of a software system as large as the JDK is the direct work of many hundreds of developers, with indirect contributions from thousands more. By way of thanks I’d like to mention the major contributors here specifically:
Brian Goetz picked up my initial straw-man proposal to add lambda expressions and default methods to Java, built it up into a better proposal, led Project Lambda in the OpenJDK Community, designed the related streams API, and achieved consensus around all of this work in the JCP. Dan Smith and Maurizio Cimadamore made major contributions to the specification and the implementation.
Stephen Colebourne‘s popular Joda Time library was the basis for his JSR 310 proposal to bring a new—and actually usable—date and time API to Java. Roger Riggs helped polish the API and integrate it into the JDK. Richard Warburton and Jim Gough of the London Java Community‘s Adopt-a-JSR Program contributed to the development of the JSR 310 conformance tests.
Michael Ernst proposed in JSR 308 to extend the language to permit annotations on any use of a type in order to support stronger static checking tools. Alex Buckley, Jonathan Gibbons, and Werner Dietl helped refine and implement the proposal and integrate it into the Java Language Specification and the JDK.
Alan Bateman and Bob Vandette led the charge to define a set of Compact Profiles for the Java SE Platform so that applications that don’t require the entire Platform can be deployed and run on small devices. Mandy Chung’s earlier work on JDK modularization laid the foundation of the Profiles.
Magnus Ihse Bursie, Erik Joelsson, and Fredrik Öhrström improved the productivity of JDK developers everywhere by rewriting the JDK build system.
Many smaller—but no less important—contributions were made via the JEP Process and in other ways by many other developers, including (but not limited to!) the following: Niclas Adlertz, Lance Andersen, Sundar Athijegannathan, Jaroslav Bachorik, Joel Borggrén-Franck, Andrew Brygin, Brian Burkhalter, Rickard Bäckman, Sergey Bylokhov, Suchen Chien, Brent Christian, Iris Clark, Sean Coffey, John Coomes, John Cuthbertson, Joe Darcy, Dan Daugherty, Mike Duigou, Xue-Lei Fan, Michael Fang, Robert Field, Daniel Fuchs, Mikael Gerdin, Jennifer Godinez, Zhengyu Gu, Kurchi Hazra, Chris Hegarty, Erik Helin, David Holmes, Vladimir Ivanov, Henry Jen, Yuka Kamiya, Karen Kinnear, Vladimir Kozlov, Marcus Lagergren, Jan Lahoda, Staffan Larsen, Doug Lea, Sergey Malenkov, Stuart Marks, Eric McCorkle, Keith McGuigan, Rob McKenna, Michael McMahon, Morris Meyer, Sean Mullan, Alejandro Murillo, Kelly O’Hair, Frederic Parain, Bhavesh Patel, Petr Pchelko, Oleg Pekhovskiy, Valerie Peng, Anthony Petrov, Pavel Porvatov, Tony Printezis, Joe Provino, Yumin Qi, Phil Race, Tom Rodriguez, Leonid Romanov, Vicente Romero, John Rose, Bengt Rutisson, Vinnie Ryan, Abhijit Saha, Dmitry Samersoff, Paul Sandoz, Naoto Sato, Thomas Schatzl, Alexander Scherbatiy, Harold Seigel, Konstantin Shefov, Xueming Shen, Serguei Spitsyn, Kumar Srinivasan, Lana Steuck, Attila Szegedi, Christian Thalinger, Igor Veresov, Hannes Wallnöfer, Joe Wang, Max Wang, Roland Westrelin, Brad Wetmore, Jesper Wilhelmsson, Hinkmond Wong, Dan Xu, Jiangli Zhou, and Alexander Zuev.
More than code Contributions of reviews, tests, and test results are just as important as contributions of code. Oracle’s internal quality and performance teams did their usual thorough job, and feedback from the wider Java community was equally valuable.
Over 400 of the more than 8,000 bug and enhancement issues addressed in JDK 8 were reported externally. These reports came in throughout the release cycle, enabled by our regular posting of weekly builds, but naturally the rate increased after we posted the Developer Preview build in September. The following early testers who submitted significant bug reports deserve special mention:
Valuable reports continued to come in after we posted the first Release
Candidate build in early February. Of the small number of bugs fixed
after that build, two were reported externally: A serious
signature bug in the lambdafication of the
Comparator API, and a nasty correctness bug in the implementation of
Launch! I’ll host the official Java 8 Launch Webcast at 17:00 UTC next Tuesday, 25 March. Join me for an open question-and-answer session with panel of key Java 8 architects, and to hear from a number of other special guests, by signing up here.
This milestone is intended for broad testing by developers. We’ve run all tests on all Oracle-supported platforms and haven’t found any glaring issues. We’ve also fixed many of the bugs discovered since we reached the Feature Complete milestone back in June.
The principal feature of this release is Project Lambda (JSR 335), which aims to make it easier to write code for multicore processors. It adds lambda expressions, default methods, and method references to the Java programming language, and extends the libraries to support parallelizable operations upon streamed data.
If you’ve been watching JDK 8 evolve from afar then now is an excellent time to download a build and try it out—the sooner the better! Let us know if your existing code doesn’t compile and run correctly on JDK 8, if it runs slower than before, if it crashes the JVM, or if there are any remaining design issues in the new language and API features.
We’ll do our best to read, evaluate, and act on all feedback received via the usual bug-reporting channel between now and the end of October. After that we’ll gradually ramp down the rate of change in order to stabilize the code, so bugs reported later on might not get fixed in time for the GA release.
Thanks to everyone who responded to that proposal, in comments on my blog entry, on Twitter, and elsewhere. The feedback was generally in favor, though understandably tinged with disappointment. As of today we have a new plan of record: The target release date for Java 8 is now 2014/3/18.
Further schedule details are available on the JDK 8 Project pages.
Security vulnerabilities related to Java running inside web browsers have lately received a lot of public attention. Here at Oracle we’ve mounted an intense effort to address those issues in a series of critical-patch update releases, the most recent of which we posted earlier this week. We’ve also upgraded our development processes to increase the level of scrutiny applied to new code, so that new code doesn’t introduce new vulnerabilities.
Maintaining the security of the Java Platform always takes priority over developing new features, and so these efforts have inevitably taken engineers away from working on Java 8. It’s one of the reasons why some features slipped past Milestone 6 (M6), our original Feature-Complete target at the end of January.
Looking ahead, Oracle is committed to continue fixing security issues at an accelerated pace, to enhance the Java security model, and to introduce new security features. This work will require more engineer hours than we can free up by dropping features from Java 8 or otherwise reducing the scope of the release at this stage.
As a consequence of this renewed focus on security the Java 8 schedule, with a GA release in early September, is no longer achievable.
Status As I’ve previously written, the most important work that slipped past M6 is related to Project Lambda, the sole driving feature of the release. We integrated the language and VM changes for Lambda late last year, but between all the moving parts involved and the security work it’s taken a bit longer than expected to put the finishing touches on the stream API and the related core-libraries enhancements (JEPs 107 and 109). Our best estimate right now is that we can finish this work by early May, about three months later than planned.
The other features that slipped past M6 are not release drivers, so in theory we could just drop them from the release, but if Lambda needs more time then there’s no point in doing that.
Alternatives So, what to do? There are many options; let’s look at a few of them.
If we drop Lambda then the remaining features are interesting but not, taken as a whole, very compelling. A Lambda-less release this year would hence be unlikely to gain wide adoption, so why bother? Lambda itself would not be available until 2016, assuming we maintain the two-year cadence that I’ve previously suggested. I don’t think anybody wants to wait that long.
If we sacrifice quality in order to maintain the schedule then we’ll almost certainly repeat the well-worn mistakes of the past, carving incomplete language changes and API designs into virtual stone where millions of developers will have to work around their flaws for years to come until those features—or the entire Platform—are replaced by something new.
With Lambda nearly complete, I don’t think it makes sense to delay its release. Beyond that, finishing Jigsaw would likely require more than a year’s delay, for reasons I’ve previously given and because key members of the Jigsaw team at Oracle have lately spent a lot of time working on security issues.
Hold the train I think the least-bad option is this:
If we can finish the remaining design and development work by early May then we should be able to test and stabilize the build over the summer and ship a solid Developer Preview release in early September.
To settle on a new GA date for Java 8 requires a bit more planning work, but my expectation is that we’d be able to ship the release in the first quarter of 2014.
That is, of course, more than a three-month slip from the current GA date in early September. At this point we’re not confident that we could be ready for a GA release in November, and experience has shown that it’s almost always a bad idea to try to ship a major software release in December, so that pushes the GA date well into the first quarter.
This option would not open the gates for a flood of new features in Java 8, nor would it permit the scope of existing features to grow without bound. We’d likely add a select few additional features, especially in areas related to security. In general, however, we’d use the additional time to stabilize, polish, and fine-tune the features that we already have rather than add a bunch of new ones. We’ve been down that latter road before, and it’s long and ugly.
Is this the best possible course of action? I think it’s better than the alternatives, but I’m open to suggestions. In the meantime I’m going to ask the same question of the Java SE 8 Expert Group and of the contributors to the Reference Implementation in the JDK 8 Project.
Features vs. schedule I’ve previously argued that it’s best to structure the Java development process as a continuous pipeline of innovation that’s only loosely coupled to a regular, rhythmic release process. If a major feature misses its intended release train then that’s unfortunate but it’s not the end of the world: It will be on the next train, which will also leave at a predictable time.
I still think that’s a good general policy. Adhering strictly to it in this case, however, would mean that we’d take the first option above—i.e., drop Lambda and stick to the schedule—which I strongly doubt anyone actually wants. An exception to the general policy is therefore well justified.
If we adopt my proposal above then we should be able to complete the browser-related security work to which we’ve committed and then resume a regular two-year release cadence, with Java 8 due in early 2014 and Java 9 in early 2016.
I recently proposed to defer Project Jigsaw from Java 8 to Java 9.
Feedback on the proposal was about evenly divided as to whether Java 8 should be delayed for Jigsaw, Jigsaw should be deferred to Java 9, or some other, usually less-realistic, option should be taken.
In light of this decision we can still make progress in Java 8 toward the convergence of the higher-end Java ME Platforms with Java SE. I previously suggested that we consider defining a small number of Profiles which would allow compact configurations of the SE Platform to be built and deployed. JEP 161 lays out a specific initial proposal for such Profiles.
There is also much useful work to be done in Java 8 toward the fully-modular platform in Java 9. Alan Bateman has submitted JEP 162, which proposes some changes in Java 8 to smooth the eventual transition to modules, to provide new tools to help developers prepare for modularity, and to deprecate and then, in Java 9, actually remove certain API elements that are a significant impediment to modularization.
Thanks to everyone who responded to the proposal with comments and questions. As I wrote initially, deferring Jigsaw to a Java 9 release in 2015 is by no means a pleasant decision. It does, however, still appear to be the best available option, and it is now the plan of record.
I recently proposed, to the Java community in general and to the SE 8 (JSR 337) Expert Group in particular, to defer Project Jigsaw from Java 8 to Java 9. I also proposed to aim explicitly for a regular two-year release cycle going forward. Herewith a summary of the key questions I’ve seen in reaction to these proposals, along with answers.
Q Has the Java SE 8 Expert Group decided whether to defer the addition of a module system and the modularization of the Platform to Java SE 9?
A No, it has not yet decided.
Q By when do you expect the EG to make this decision?
A In the next month or so.
Q How can I make sure my voice is heard?
A The EG will consider all relevant input from the wider community. If you have a prominent blog, column, or other communication channel then there’s a good chance that we’ve already seen your opinion. If not, you’re welcome to send it to the Java SE 8 Comments List, which is the EG’s official feedback channel.
Q What’s the overall tone of the feedback you’ve received?
A The feedback has been about evenly divided as to whether Java 8 should be delayed for Jigsaw, Jigsaw should be deferred to Java 9, or some other, usually less-realistic, option should be taken.
Q Why is Project Jigsaw taking so long?
A Project Jigsaw started at Sun, way back in August 2008. Like many efforts during the final years of Sun, it was not well staffed. Jigsaw initially ran on a shoestring, with just a handful of mostly part-time engineers, so progress was slow. During the integration of Sun into Oracle all work on Jigsaw was halted for a time, but it was eventually resumed after a thorough consideration of the alternatives. Project Jigsaw was really only fully staffed about a year ago, around the time that Java 7 shipped. We’ve added a few more engineers to the team since then, but that can’t make up for the inadequate initial staffing and the time lost during the transition.
Q So it’s really just a matter of staffing limitations and corporate-integration distractions?
A Aside from these difficulties, the other main factor in the duration of the project is the sheer technical difficulty of modularizing the JDK.
Q Why is modularizing the JDK so hard?
A There are two main reasons. The first is that the JDK code base is deeply interconnected at both the API and the implementation levels, having been built over many years primarily in the style of a monolithic software system. We’ve spent considerable effort eliminating or at least simplifying as many API and implementation dependences as possible, so that both the Platform and its implementations can be presented as a coherent set of interdependent modules, but some particularly thorny cases remain.
Q What’s the second reason?
A We want to maintain as much compatibility with prior releases as possible, most especially for existing classpath-based applications but also, to the extent feasible, for applications composed of modules.
Q Is modularizing the JDK even necessary? Can’t you just put it in one big module?
A Modularizing the JDK, and more specifically modularizing the Java SE Platform, will enable standard yet flexible Java runtime configurations scaling from large servers down to small embedded devices. In the long term it will enable the convergence of Java SE with the higher-end Java ME Platforms.
Q Is Project Jigsaw just about modularizing the JDK?
A As originally conceived, Project Jigsaw was indeed focused primarily upon modularizing the JDK. The growing demand for a truly standard module system for the Java Platform, which could be used not just for the Platform itself but also for libraries and applications built on top of it, later motivated expanding the scope of the effort.
Q As a developer, why should I care about Project Jigsaw?
A The introduction of a modular Java Platform will, in the long term, fundamentally change the way that Java implementations, libraries, frameworks, tools, and applications are designed, built, and deployed.
Q How much progress has Project Jigsaw made?
A We’ve actually made a lot of progress. Much of the core
functionality of the module system has been prototyped and works at both
compile time and run time. We’ve extended the Java programming language
with module declarations, worked out a structure for
modular source trees and corresponding compiled-class trees,
and implemented these features in
javac. We’ve defined an efficient
module-file format, extended the JVM to bootstrap a modular
JRE, and designed and implemented a preliminary API.
We’ve used the module system to make a good first cut at dividing the JDK
and the Java SE API into a coherent set of modules. Among
other things, we’re currently working to retrofit the
java.util.ServiceLoader API to support modular services.
Q I want to help! How can I get involved?
A Check out the project page, read the draft requirements and design overview documents, download the latest prototype build, and play with it. You can tell us what you think, and follow the rest of our work in real time, on the jigsaw-dev list.
Q What’s the relationship between Project Jigsaw and the eventual Java Platform Module System JSR?
A At a high level, Project Jigsaw has two phases. In the first phase we’re exploring an approach to modularity that’s markedly different from that of existing Java modularity solutions. We’ve assumed that we can change the Java programming language, the virtual machine, and the APIs. Doing so enables a design which can strongly enforce module boundaries in all program phases, from compilation to deployment to execution. That, in turn, leads to better usability, diagnosability, security, and performance. The ultimate goal of the first phase is produce a working prototype which can inform the work of the Module-System JSR EG.
Q What will happen in the second phase of Project Jigsaw?
A The second phase will produce the reference implementation of the specification created by the Module-System JSR EG. The EG might ultimately choose an entirely different approach than the one we’re exploring now. If and when that happens then Project Jigsaw will change course as necessary, but either way I think that the end result will be better for having been informed by our current work.
Q Why not just use Maven?
A Maven is a software project management and comprehension tool. As such it can be seen as a kind of build-time module system but, by its nature, it does nothing to support modularity at run time.
Q Why not just adopt OSGi?
A OSGi is a rich dynamic component system which includes not just a module system but also a life-cycle model and a dynamic service registry. The latter two facilities are useful to some kinds of sophisticated applications, but I don’t think they’re of wide enough interest to be standardized as part of the Java SE Platform.
Q Okay, then why not just adopt the module layer of OSGi?
A The OSGi module layer is not operative at compile time; it only addresses modularity during packaging, deployment, and execution. As it stands, moreover, it’s useful for library and application modules but, since it’s built strictly on top of the Java SE Platform, it can’t be used to modularize the Platform itself.
Q If Maven addresses modularity at build time, and the OSGi module layer addresses modularity during deployment and at run time, then why not just use the two together, as many developers already do?
A The combination of Maven and OSGi is certainly very useful in practice today. These systems have, however, been built on top of the existing Java platform; they have not been able to change the platform itself. This means, among other things, that module boundaries are weakly enforced, if at all, which makes it difficult to diagnose configuration errors and impossible to run untrusted code securely. The prototype Jigsaw module system, by contrast, aims to define a platform-level solution which extends both the language and the JVM in order to enforce module boundaries strongly and uniformly in all program phases.
Q If the EG chooses an approach like the one currently being taken in the Jigsaw prototype, will Maven and OSGi be made obsolete?
A No, not at all! No matter what approach is taken, to ensure wide adoption it’s essential that the standard Java Platform Module System interact well with Maven. Applications that depend upon the sophisticated features of OSGi will no doubt continue to use OSGi, so it’s critical that implementations of OSGi be able to run on top of the Java module system and, if suitably modified, support OSGi bundles that depend upon Java modules. Ideas for how to do that are currently being explored in Project Penrose.
Q Without Jigsaw, won’t Java 8 be a pretty boring release?
A No, far from it! It’s still slated to include the widely-anticipated Project Lambda (JSR 335), work on which has been going very well, along with the new Date/Time API (JSR 310), Type Annotations (JSR 308), and a set of smaller features already in progress.
Q Won’t deferring Jigsaw to Java 9 delay the eventual convergence of the higher-end Java ME Platforms with Java SE?
A It will slow that transition, but it will not stop it. To allow progress toward that convergence to be made with Java 8 I’ve suggested to the Java SE 8 EG that we consider specifying a small number of Profiles which would allow compact configurations of the SE Platform to be built and deployed.
Q If Jigsaw is deferred to Java 9, would the Oracle engineers currently working on it be reassigned to other Java 8 features and then return to working on Jigsaw again after Java 8 ships?
A No, these engineers would continue to work primarily on Jigsaw from now until Java 9 ships.
Q Why not drop Lambda and finish Jigsaw instead?
A Even if the engineers currently working on Lambda could instantly switch over to Jigsaw and immediately become productive—which of course they can’t—there are less than nine months remaining in the Java 8 schedule for work on major features. That’s just not enough time for the broad review, testing, and feedback which such a fundamental change to the Java Platform requires.
Q Why not ship the module system in Java 8, and then modularize the platform in Java 9?
A If we deliver a module system in one release but don’t use it to modularize the JDK until some later release then we run a big risk of getting something fundamentally wrong. If that happens then we’d have to fix it in the later release, and fixing fundamental design flaws after the fact almost always leads to a poor end result.
Q Why not ship Jigsaw in an 8.5 release, less than two years after 8? Or why not just ship a new release every year, rather than every other year?
A Many more developers work on the JDK today than a couple of years ago, both because Oracle has dramatically increased its own investment and because other organizations and individuals have joined the OpenJDK Community. Collectively we don’t, however, have the bandwidth required to ship and then provide long-term support for a big JDK release more frequently than about every other year.
Q What’s the feedback been on the two-year release-cycle proposal?
A For just about every comment that we should release more frequently, so that new features are available sooner, there’s been another asking for an even slower release cycle so that large teams of enterprise developers who ship mission-critical applications have a chance to migrate at a comfortable pace.
The aim of Project Jigsaw is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK.
Jigsaw is currently slated for Java 8. The proposed development schedule for Java 8 expects work on major features to be finished by May 2013, in preparation for a final release around September. Steady progress is being made, but some significant technical challenges remain. There is, more importantly, not enough time left for the broad evaluation, review, and feedback which such a profound change to the Platform demands.
I therefore propose to defer Project Jigsaw to the next release, Java 9. In order to increase the predictability of all future Java SE releases, I further propose to aim explicitly for a regular two-year release cycle going forward.
Goals A standard module system for the Java Platform will ease the construction, maintenance, and distribution of large applications, at last allowing developers to escape the “JAR hell” of the brittle and error-prone class-path mechanism. A truly modular Java Platform will support customizable configurations which scale from large servers down to small embedded devices and, in the long term, enable the convergence of Java SE with the higher-end Java ME Platforms. Modular applications built on top of a modular platform can be downloaded more quickly, and the run-time performance of the code they contain can be optimized more effectively.
Progress Initial work toward these goals has been underway in Project Jigsaw in the OpenJDK Community for some time. Guided by a draft requirements document written in collaboration with key stakeholders we’ve thus far produced an initial design for a module system, used that to modularize the JDK, and published an open-source prototype implementation which anyone can download and evaluate.
Despite this progress, some significant technical challenges lay ahead. Modularizing the Java SE Platform and the JDK while maintaining compatibility for existing code is an incredibly delicate task which requires careful changes throughout both the specification and the implementation. We have, moreover, yet to design and prototype an approach to supporting containers such as IDEs, Java EE application servers, and applet containers, all of which require some amount of reflective dynamism. We’re reasonably confident that we can work through these issues, but doing so will most likely take us past May 2013.
Bake time Above and beyond any specific technical problems, the introduction of a truly modular Java Platform is a momentous transition which will, eventually, affect the entire Java ecosystem. It will change the way that the Java Platform itself is deployed, and it will change the way that developers build and deploy libraries, frameworks, tools, and applications.
We must therefore allow adequate time for broad review, testing, and feedback from all segments of the community on both the design and the implementation via Project Jigsaw, via the Java SE 8 Platform JSR (337), and, primarily, via a forthcoming JSR to define a standard Java Platform Module System. We should not try to rush to complete, in less than ten months, such a deep change with such wide impact.
At this point, then, the options available are achingly familiar: Either delay Java 8 until Jigsaw is complete, most likely slipping its final release to mid-2014, or else ship Java 8 on time, around September 2013, and defer Jigsaw to Java 9.
Schedule vs. features To put the stark choice before us in another way, and more generally: When a train is scheduled to leave the station should we hold it until all the expected passengers are on board? Or should we raise the ball, let the train go, and tell anyone who’s late to wait for the next one, which will also depart precisely as scheduled?
In all the years I’ve worked on Java I’ve heard repeatedly that developers, partners, and customers strongly prefer a regular and predictable release cycle. Developers want rapid innovation while enterprises want stability, and a cadence of about two years seems to strike the right balance. It’s therefore saner for all involved—those working on new features, and those who want to use the new features—to structure the development process as a continuous pipeline of innovation that’s only loosely coupled to the actual release process, which itself has a constant rhythm. If a major feature misses its intended release train then that’s unfortunate but it’s not the end of the world: It will be on the next train, which will also leave at a predictable time.
Keep the beat In this light I think the best choice is to defer Project Jigsaw to Java 9, and to aim for a two-year release cycle going forward.
On this plan Java 8 will ship on time, around September 2013. Assuming all else goes well it will include the widely-anticipated Project Lambda (JSR 335), the new Date/Time API (JSR 310), Type Annotations (JSR 308), and a selection of the smaller features already in progress. Java 9 will follow two years later, around September 2015, with Jigsaw and, no doubt, various other features yet to be determined. Work on Jigsaw will, in the meantime, proceed at full speed.
Deferring Project Jigsaw to 2015 is by no means a pleasant decision. It does, however, appear to be the best available option. I have therefore today asked the Java SE 8 (JSR 337) Expert Group to consider it.
I’ve started drafting an overview of the current state of our work on Project Jigsaw. Ultimately this will be a fairly long document, but in order to start getting feedback as early possible I’ve published the first part on its own. This initial installment covers design principles, basic definitions, and module declarations; still to come are sections on compilation, packaging, libraries, repositories, the module-system API, and the modularization of the JDK.
The Jigsaw module system is designed to be both approachable and scalable: Approachable by all developers, yet sufficiently scalable to support the modularization of large legacy software systems in general and the JDK in particular. It aims to implement a set of general requirements; its detailed design has been further guided by the following principles:
Modularity is a language construct — The best way to support modular programming in a standard way in the Java platform is to extend the language itself to support modules. Developers already think about standard kinds of program components such as classes and interfaces in terms of the language. Modules should be just another kind of program component, and like classes and interfaces they should have meaning in all phases of a program’s development.
Module boundaries should be strongly enforced — A class that is private to a module should be private in exactly the same way that a private field is private to a class. In other words, module boundaries should determine not just the visibility of classes and interfaces but also their accessibility. Without this guarantee it is impossible to construct modular systems capable of running untrusted code securely.
Static, single-version resolution is usually sufficient — Most applications do not need to add or remove modules dynamically at run time, nor do they need to use multiple versions of the same module simultaneously. The module system should be optimized for common scenarios but also support narrowly-scoped forms of dynamic multi-version resolution motivated by actual use cases such as, e.g., application servers, IDEs, and test harnesses.
There are already plenty of module systems built on top of the Java platform. What’s new about the Jigsaw module system is that it’s designed to be an integral part of the platform. The design assumes the possibility of changing the Java language and the Java virtual machine, thereby enabling both linguistic support for modular programming and secure encapsulation.
For more details see the draft. Please send comments, questions, and suggestions to the jigsaw-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.)
Last week the JCP Executive Committee approved Java SE 7 and its component JSRs.
This week the first and only Release Candidate passed all its tests with flying colors.
A giant thank-you to everyone who contributed to this release—from Sun, Oracle, and elsewhere—and especially to those who held on for the long haul of four years, seven months, and seventeen days since JDK 6.
JSR 336: Java SE 7, the Umbrella JSR for the Platform itself.
My thanks and congratulations to the Specification Leads of these JSRs and to everyone else who contributed, in ways both large and small.
At this point all of the work required to define the abstract Java SE 7 Platfom in the JCP is done but the actual product, JDK 7, is not quite finished. Here at Oracle we’re busy wrapping up final testing of the release candidate, build 147. If all goes well then that will be declared the GA build on 28 July per the schedule posted in January. Oracle’s commercial binaries, based almost entirely on OpenJDK code, will be published that day; implementations from other vendors will follow.
There are only thirteen changes in this build. Over half of them are administrivial updates that don’t affect the actual code; the remainder are true showstoppers, including several hard VM crashes and a JIT correctness bug identified by an Eclipse unit test.
If no new showstopper issues are reported, and if JSR 336 and the component JSRs pass their Final Approval Ballots in the JCP, then this will be the GA build for release later this month per the schedule posted back in January.
The two-week vote to ratify the OpenJDK Community Bylaws ended earlier today at 16:00 UTC. I’m very pleased to report that the vote was successful, with 70 votes in favor, no votes against, and nine abstentions.
This is a major milestone for the OpenJDK Community. It’s the end result of a long-running effort which was initiated in 2007, foundered during the demise of Sun, and then rebooted earlier this year after IBM and then Apple joined up.
Not everyone is completely happy with the Bylaws as they stand, but my sense from recent conversations is that most agree them to be a workable beginning and a firm foundation upon which further trust can be built over time.
My thanks to everyone who contributed to the Bylaws drafts, and to everyone who voted.
The Bylaws have now been ratified, but they won’t be in force until we implement the transition plan outlined in Appendix B. We expect that to be done around mid-July; until then we’ll continue to operate under the existing informal guidelines.
Very nearly …
Build 146 of JDK 7 is now available. We’re still chasing down a few bugs, so this isn’t quite a Release Candidate, but it’s very close. This build will undergo a final round of JCK testing and then, if all goes well, be declared the Reference Implementation of Java SE 7 (JSR 336).
Of note in this build is the first update to Javadoc’s default display style in many years. This is enabled by other recent work on the long-neglected Javadoc tool, in particular the change to leverage Cascading Style Sheets more thoroughly so that most aspects of the display style can be changed simply by providing a new stylesheet.