Yesterday, Mark Reinhold published ‘Java Platform Module System: Issue Summary‘. This is a rundown of the issues that need to be investigated before Project Jigsaw is complete.

We have covered some of the fundamental issues delaying Project Jigsaw in How do you solve a problem like Java 9 modules and reflective access? This covers the problem of reflective access to non exported types and awkward strong encapsulation. Aside from the major issues with strong encapsulation and reflective access, what are some of the other issues open for discussion?

The Module System: Discuss

Module Name Syntax

Modules are described in their module declaration, in the module-info.java file of a module. For example:

module java.sql {
   exports java.sql;
   exports javax.sql;
   ...
}

However several people have noted that this is confusing: “Namespace for modules overlap with that of packages – can be confusing after looking at a lot of module descriptors” (see this discussion). One suggestion is that the words be lowercase and separated by underscores, or change the ‘requires‘ syntax to ‘requires module‘ and ‘exports‘ into ‘exports package‘, so we might get something like this:

module java_sql {
   exports java.sql;
   exports javax.sql;
   ...
}

Or:

module java.sql {
   requires module foo.bar;
   exports package java.sql;
   exports package javax.sql;
}

Static Layer Configuration

A module declaration does not include a version string, and The State of the Module System notes: “It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications.” As version selection is left to build tools, maintainers of build and launch tools have asked for guidance on how they go about version selection, conflict resolution and issues.

A layer maps each module in the module graph to a class loader responsible for loading the types defined in the module. A boot layer starts the initial module. Layers can be stacked: starting with the boot layer. A layer can read modules in itself, and lower layers. They are created dynamically via reflection.

The problem arises when multiple versions of the same module are in the layers. One suggestion is that layers can be specified statically, at startup.

Versioned Dependences

Requests have been made to consider including specific version strings either optionally in the module declaration, or recorded in a compiled module descriptor: “… that information is going to be very useful because it means we can take a compiled Java 9 module and we know what it was compiled against.”

On the other hand, there is also a proposal to discourage library maintainers from encoding version numbers in module names. The proposal is to do this by changing the automatic module naming alogirthm so that it doesn’t end names in digits, and add a warning to javac.

The proposal to add versioned dependences is still open, as is a proposal to create standard module attributes useful for tools, such as the module version string.

Module JARs

A modular jar file can only contain one module. Multi-Module Executable JARs and Multi-Module JARs ask for a way to support multiple modules in one jar file, modifying the module-info.java file name accordingly to specify which module it refers to. This would provide a means to create an executable modular jar with multiple modules.

Reified Module Graph

The module path is defined by the host system, and contains module artifacts, or a directory containing module artifacts. It is different from the class path as it locates whole modules and the compiler does not allow it if an artifact on the module path can’t be found, or two artifacts in the same directory define modules of the same name.

This looks to resolve a module from a module path by recording the module graph that results from resolving a main module against an application module path.

Lazy Configuration And Instantiation

Another concern is that on startup, loading all of the descriptors and building all of the modules will be too large an overhead for some applications. On startup, a ‘Layer’ would be instantiated that consisted of the configuration of modules required. The suggestion is to use incremental algorithms, although judging by ongoing discussion, this may not remain an issue for long.

Big Issues

At the time of writing, there are 18 proposals being actively discussed, and 13 that are ‘open’. Where some of the issues seem trivial (such as module names), some, like lazy configuration and instantiation, and reflective access to non-exported types, hint at a steep road ahead for the Java 9 team.

Why not see if you’d like to contribute? You can take a look at the code yourself in our short guide or see how you can help the community.

Issues with the Module System

| Java Language| 1,131 views | 0 Comments
About The Author
- Katharine is a Java developer by trade, turned Community & Content Manager for Voxxed. Helping developers learn and share knowledge. Contact me at kbe@voxxed.com with any news, articles or tutorials.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>