Project Jigsaw: Late for the train: The Q&A
- by Mark Reinhold
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.
Making the decision
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.
Project Jigsaw
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.
The Java Platform Module System JSR
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.
Maven & OSGi
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.
Java 8 & Java 9
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.
