The pieces are coming together

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

Chris Mayer
jigsaw

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.

Module

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
.

Author
Comments
comments powered by Disqus