JavaOne 2015 saw a series of talks by the Project Jigsaw team about modularity in Java 9. They are all very interesting and full of valuable information and I urge every Java developer to watch them.

Beyond that I want to give the community a way to search and reference them, so I summarize them here:

I made an effort to link to as many external resources as possible to keep the individual posts short. The play icons will take you straight to the corresponding point in the ten hour long video streams that Oracle put online for each room and day. (Great format, guys!) Not only did they (so far) fumble the cutting, they also seem to have resorted to low-volume mono sound so make sure to crank up the volume.

Let’s build on the introduction with some advanced modular development and migration advice!

Overview

  • Content: How to migrate applications and libraries to the module system
  • Speaker: Mark Reinhold, Alex Buckley, Alan Bateman
  • Links: Video and Slides

Screen Shot 2015-11-26 at 17.18.08Introductory Remarks

Mark Reinhold begins by emphasizing that the current prototype is still a work in progress, a proposal with some rough edges and missing parts. The reason the Jigsaw team is spending so much time talking about it is to spread the word and gather feedback.

So try it out and give feedback!

Screen Shot 2015-11-26 at 17.18.08

Application Migration

javaone-project-jigsaw-migration-scenario

Copyright © 2015, Oracle and/or its affiliates.
All rights reserved.

In the talk’s first part, Alex Buckley covers how to migrate an application to the module system. He discusses this under the assumption that the application’s dependencies are not yet published as modules. (Because if they were, this would be fairly simple and straight-forward.)

Screen Shot 2015-11-26 at 17.18.08

Top-Down Migration

Whenever a JAR is turned into a module, two questions have to be answered:

  • What does the module require?
  • What does the module export?

The first question can be answered with the help of jdeps. The second requires the module’s authors to consciously decide which packages contain its public API.

Both answers must then be poured into the moduleinfo.java as explained in the introduction to modular development and the quick-start guide.

Screen Shot 2015-11-26 at 17.18.08

Automatic Modules

Buckley now addresses the intrinsic problem of his example: What to do with the application’s dependencies that were not yet published as modules? The solution are automatic modules.

javaone-project-jigsaw-automatic-modules

Copyright © 2015, Oracle and/or its affiliates.
All rights reserved.

Simply by placing a JAR on the module path instead of the class path it becomes an automatic module. This is a full fledged module but requires no changes to the JAR itself. Its name is derived from the JAR name and it exports all its packages. It can read all modules on the module path (by implicitly requiring them all) and all classes on the class path.

This provides the maximum compatibility surface for migrating JAR files.

Screen Shot 2015-11-26 at 17.18.08

System Structure

Even with the slightly exceptional automatic modules, which add a lot of edges to the module path, the situation is better than it was on the class path. There everything could access everything else and the JVM simply erased any system structure envisioned by the developers.

Screen Shot 2015-11-26 at 17.18.08

Compiling And Running The Example

The example is compiled and run with the commands covered by the quick-start guide.

Buckley also demonstrates the javac flag modulesourcepath to enable multi-module compilation. It requires a single directory and expects it to contain one subdirectory per module. Each module directory can then contain source files and other resources required to build the module. This corresponds to the new directory schema proposed by JEP 201.

Screen Shot 2015-11-26 at 17.18.08Summary

For top-down migration the application’s JARs are transformed into modules by creating moduleinfo.java files for them. The dependencies are turned into automatic modules by putting them on the module path instead of the class path.

Screen Shot 2015-11-26 at 17.18.08Library Migration

Alan Bateman approaches the same scene but from a different perspective. He is showing how to convert libraries to modules without requiring the application’s using them to do the same.

Screen Shot 2015-11-26 at 17.18.08Bottom-Up Migration

For libraries the same questions need to be answered as for application modules:

  • What does the module require?
  • What does the module export?

Again, jdeps is brought out to answer the first. But here Bateman also demonstrates how the flag genmoduleinfo can be used to generate a first draft of the moduleinfo.java files. In this mode jdeps derives the module name from the JAR name, requires the correct dependencies and simply exports all packages. The module authors should then decide which exports to take out.

Bateman then compiles and packages the modules like described above and in the quick-start guide.

Screen Shot 2015-11-26 at 17.18.08Mixing Class Path And Module Path

The application is not yet converted to modules, which has two implications:

javaone-project-jigsaw-library-modules

Copyright © 2015, Oracle and/or its affiliates.
All rights reserved.

  • Both the class path and the module path are required to run it.
  • The application can not express which modules it depends on.

Mixing class and module path on the command line is verbose but straight forward. On top of that the flag addmodsmust be used to specify the root modules against which the module system has to resolve the module path. In the running examples, this would be the freshly converted library modules.

Screen Shot 2015-11-26 at 17.18.08Advanced Migration Challenges

In the presented example one of the newly created library modules uses reflection to access the application’s code. This is problematic because modules can only access code from modules on which they depend and clearly libraries can not depend on the applications using them.

The solution is addReads on the new class java.lang.Module. It can be used to allow the module calling the method to read a specified module. To get a module callClass.getModule().

Screen Shot 2015-11-26 at 17.18.08Putting It All Together

javaone-project-jigsaw-migration-done

Copyright © 2015, Oracle and/or its affiliates.
All rights reserved.

Putting both approaches together results in a nice dependency graph and super short command to launch the application.

Bateman then goes on to package the resulting application in a minimal self-contained run time image with jlink as described in the introduction to modular development.

Screen Shot 2015-11-26 at 17.18.08Summary

In summary, the two approaches show how application and library maintainers can modularize their projects independently and at their own pace. But note that some code changes may be required.

Go forth and modularize!

javaone-project-jigsaw-advanced-sf

 

Published by Joe Parks under CC-BY-NC 2.0.

Advanced Modular Development

| Java Language| 592 views | 0 Comments
About The Author
- Nicolai is a thirty year old boy, as the narrator would put it, who has found his passion in software development. He constantly reads, thinks, and writes about it, and codes for a living as well as for fun. Nicolai is the editor of SitePoint's Java channel, writes The Java 9 Module System with Manning, blogs about software development on codefx.org, and is a long-tail contributor to several open source projects. You can hire him for all kinds of things.

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>