Advanced Modular Development by Mark Reinhold and Alan Bateman

By: Devoxx

6   0   733

Uploaded on 11/11/2016

This session focuses on developing modules with the Java Platform Module System in JDK 9. Using well-known libraries as examples, you will learn how to develop libraries and applications as modules and will also find out how to migrate existing code to modules.

Migration poses many challenges, and in addition to learning about “bottom-up” migration, you will learn about “top-down” migration, where libraries and applications are migrated to modules without waiting for libraries they depend on to migrate first.

Mark Reinhold is Chief Architect of the Java Platform Group at Oracle. His past contributions to the platform include character-stream readers and writers, reference objects, shutdown hooks, the NIO high-performance I/O APIs, library generification, and service loaders. Mark was the lead engineer for the JDK 1.2 and 5.0 releases, the JCP specification lead for Java SE 6, and both the project and specification lead for JDK 7 (Java SE 7) and JDK 8 (Java SE 8). He currently leads the JDK 9 and Jigsaw projects in the OpenJDK Community, where he also serves on the Governing Board. Mark holds a Ph.D. in computer science from the Massachusetts Institute of Technology.

Alan Bateman
Consulting Member of Staff in the JDK team in Oracle. I'm currently focused on the Java Platform Module System and the Modular JDK that targets JDK 9. I'm an active member of the OpenJDK project and have a long history in the development of JDK.

[KMR-8467]

Comments (4):

By anonymous    2017-09-20

For the sake of argument, let's assert that Java 8 (and earlier) already has a "form" of modules (jars) and module system (the classpath). But there are well-known problems with these.

By examining the problems, we can illustrate the motivation for Jigsaw. (The following assumes we are not using OSGi, JBoss Modules, etc, which certainly offer solutions.)

Problem 1: public is too public

Consider the following classes (assume both are public):

com.acme.foo.db.api.UserDao
com.acme.foo.db.impl.UserDaoImpl

At Foo.com, we might decide that our team should use UserDao and not use UserDaoImpl directly. However, there is no way to enforce that on the classpath.

In Jigsaw, a module contains a module-info.java file which allows us to explicitly state what is public to other modules. That is, public has nuance. For example:

// com.acme.foo.db.api.UserDao is accessible, but
// com.acme.foo.db.impl.UserDaoImpl is not 
module com.acme.foo.db {
    exports com.acme.foo.db.api;
}

Problem 2: reflection is unbridled

Given the classes in #1, someone could still do this in Java 8:

Class c = Class.forName("com.acme.foo.db.impl.UserDaoImpl");
Object obj = c.getConstructor().newInstance();

That is to say: reflection is powerful and essential, but if unchecked, it can be used to reach into the internals of a module in undesirable ways. Mark Reinhold has a rather alarming example. (The SO post is here.)

In Jigsaw, strong encapsulation offers the ability to deny access to a class, including reflection. (This may depend on command-line settings, pending the revised tech spec for JDK 9.) Note that because Jigsaw is used for the JDK itself, Oracle claims that this will allow the Java team to innovate the platform internals more quickly.

Problem 3: the classpath erases architectural relationships

A team typically has a mental model about the relationships between jars. For example, foo-app.jar may use foo-services.jar which uses foo-db.jar. We might assert that classes in foo-app.jar should not bypass "the service layer" and use foo-db.jar directly. However, there is no way to enforce that via the classpath. Mark Reinhold mentions this here.

By comparison, Jigsaw offers an explicit, reliable accessibility model for modules.

Problem 4: monolithic run-time

The Java runtime is in the monolithic rt.jar. On my machine, it is 60+ MB with 20k classes! In an age of micro-services, IoT devices, etc, it is undesirable to have Corba, Swing, XML, and other libraries on disk if they aren't being used.

Jigsaw breaks up the JDK itself into many modules; e.g. java.sql contains the familiar SQL classes. There are several benefits to this, but a new one is the jlink tool. Assuming an app is completely modularized, jlink generates a distributable run-time image that is trimmed to contain only the modules specified (and their dependencies). Looking ahead, Oracle envisions a future where the JDK modules are compiled ahead-of-time into native code. Though jlink is optional, and AOT compilation is experimental, they are major indications of where Oracle is headed.

Problem 5: versioning

It is well-known that the classpath does not allow us to use multiple versions of the same jar: e.g. bar-lib-1.1.jar and bar-lib-2.2.jar.

Jigsaw does not address this problem; Mark Reinhold states the rationale here. The gist is that Maven, Gradle, and other tools represent a large ecosystem for dependency management, and another solution will be more harmful than beneficial.

It should be noted that other solutions (e.g. OSGi) do indeed address this problem (and others, aside from #4).

Bottom Line

That's some key points for Jigsaw, motivated by specific problems.

Note that explaining the controversy between Jigsaw, OSGi, JBoss Modules, etc is a separate discussion that belongs on another Stack Exchange site. There are many more differences between the solutions than described here. What's more, there was sufficient consensus to approve the Public Review Reconsideration Ballot for JSR 376.

Original Thread

By anonymous    2017-09-20

Immediate performance implications include the following:

  • Modularized applications can opt to use jlink so that the distributable runtime is reduced in size: it only uses the modules you require. So if you don't need Swing, Corba, etc, it does not reside on disk. (more info here).
  • Modularized applications use the module graph for classloading; the algorithm for this is much faster than the linear search of classpath (more info here).

This is by no means a guarantee that your app will be faster, but the above is undeniably attractive.

Longer term, consider this:

  • Though experimental in JDK 9, there is an AOT compiler that (for Linux x64) will compile the java.base module to native code. This is likely the path forward for future Java releases. Surely this will improve startup time in the future. (again, more info here)

Original Thread

Recommended Books

    Popular Videos 92

    Submit Your Video

    If you have some great dev videos to share, please fill out this form.