The pieces are coming together

Java 8 – Oracle unveils plans for JDK modularity in Project Jigsaw

Chris Mayer

Project Jigsaw outlines plans for standardised module system for Java SE and as part of the JDK

Just as the year is almost out, big news regarding planning for JDK 8 has been released about Project Jigsaw – the exploratory scheme aiming to create and implement a standardised module system for the Java SE platform and then apply it to the platform and JDK itself, making it readily available for all developers.

It’s been a long-held ideal within the community but the dream had never been fully realised. What hadn’t been clear up until this point was how this modularisation would be achieved. Until now. Mark Reinhold has submitted a first draft outlining the design principles, aiming for the system to be approachable and scalable. Reinhold went further to say that the system should be:

Approachable by all developers, yet sufficiently scalable to support the modularization of large legacy software systems in general and the JDK in particular.

Design Principles

He then outlined three guiding principles behind modularisation and how this must be enforced for the project to get lift-off.

  • Modularity is a language construct — The best way to support modular programming is to extend Java 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.

  • Module boundaries should be strongly enforced — 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 module 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.


For those not unaware of the term ‘module’, it is effectively a collection of Java types,classes and interfaces with a name, an optional version number, and a formal description of its relationships to other modules. But it goes much further than this – a module can include resource files, configuration files, native libraries, and native commands. It is also possible to cryptographically sign a module to validate its authenticity.

The most important inter-module relationship is dependance, where one module declares its reliance upon another, by specifying it or through a constraint upon the allowable range.

The simplest module declaration is:

module foo { }

If a version number is present, a character can be placed after the module name and version number, like so:

module foo @ 1.0 { }

Life cycle

There are three principal stages in the life cycle of a module

  1. Compile time – module dependencies are resolved, therefore its types are compiled and ready for publication/application
  2. Install time – a module is inserted into a module library i.e. a collection of other previously installed modules. If the module is invokablei.e., it has an entry point, then it is made ready for use by resolving its dependences and storing the result of that computation in a persistent configuration
  3. Run time – the invokable module is loaded on the JVM and linked up to other modules

It’s important to note that when compiling a module, the Java compiler writes class files into a module-structured classes directory - module-path layout where there is one top-level directory for each module; the content of each module directory is structured as a normal classes directory, i.e., a tree of decomposed Java package names. For this interactive development to occur, the Java launcher can run a modular application directly from a module-path directory – it performs resolution before invoking the application’s entry point, although the resulting configuration is not stored for future use.

This is merely scratching the surface of Project Jigsaw, and Reinhold even admits that the draft paper isn’t complete yet. After all, with JDK destined to emerge in mid 2013, there’s plenty of work to be done and plenty of time to get on with Project Jigsaw. It’s important to stay informed with the project, as so much can change with the bat of an eyelid.

Here’s some of the treats that lay in store for the future

  • Compilation
  • Packaging
  • Libraries
  • Repositories
  • Module System API
  • JDK modularisation

The document provides much further details such as for Exports, Version Constraints, Access Points and Services, so it’s well worth your time taking longer to read the opening gambit from Project Jigsaw.

Inline Feedbacks
View all comments