{"id":1157,"date":"2017-12-20T07:32:35","date_gmt":"2017-12-20T07:32:35","guid":{"rendered":"https:\/\/www.javaadvent.com\/?p=1157"},"modified":"2019-11-27T09:47:37","modified_gmt":"2019-11-27T09:47:37","slug":"automatic-module-name-calling-java-library-maintainers","status":"publish","type":"post","link":"https:\/\/www.javaadvent.com\/2017\/12\/automatic-module-name-calling-java-library-maintainers.html","title":{"rendered":"Automatic-Module-Name: Calling all Java Library Maintainers"},"content":{"rendered":"
With the Java 9 release, developers can use the new module system to create modular applications. However, in order to modularize applications, libraries should be usable as modules as well.<\/em><\/header>\n
Creating modular applications using the Java module system is an enticing prospect. Modules have module descriptors in the form of\u00a0module-info.java<\/code>, declaring which packages are exported and what dependencies it has on other modules. This means we finally have explicit dependencies between modules at the language level, and can strongly encapsulate code within these modules. The book\u00a0Java 9 Modularity<\/a>\u00a0(O’Reilly) written by Paul Bakker and me explains these mechanisms and their benefits in detail.That, however, is not what this post is about. Today, we’ll talk about what needs to be done to move the Java library ecosystem toward modules. In the ideal world where all libraries have module descriptors, all is well. That’s not yet where we are in the Java community.<\/p>\n

What You Need To Do Now<\/h3>\n

We need Java library maintainers to step up! Ultimately, it would be best for your library to have a module descriptor so that modular applications can depend on it. Getting there isn’t trivial in all cases. Fortunately, support for the Java module system can be incrementally added to libraries. This post explains the first step you can take as library maintainer on your way to becoming a Java module. This first step boils down to picking a module name, and adding it as\u00a0Automatic-Module-Name: <module name><\/code>\u00a0entry to the library’s MANIFEST.MF. That’s it.<\/p>\n

With this first step you make your library usable as Java module without moving the library itself to Java 9 or creating a module descriptor for the library, yet. It doesn’t even require re-compilation. So, do yourself a favor and do it now. If you’re not a library maintainer, encourage libraries you use by opening an issue and pointing to this post. Then, if you’d like to know why this is a good idea and how it actually works, keep reading.<\/p>\n

Automatic Modules<\/h3>\n

Traditional applications are packaged into JARs and run from the classpath. Java 9 still supports this, but also opens the door to more reliable and efficient deployment. Modular applications on Java 9 and later are packaged into JARs which contain module descriptors (modular JARs<\/em>) and run from the module path. Code in modular JARs on the module path can’t access code in traditional JARs on the classpath. So what happens when a modular application wants to use a library living on the classpath, which doesn’t have a module descriptor yet? The modular application can’t express such a dependency in its module descriptor.<\/p>\n

It would be unworkable if the only resort for application developers were to wait for the library maintainer to write a module descriptor, or worse, attempt to patch the JAR themselves with a module descriptor. To prevent this possibly indefinite waiting game, a feature called\u00a0automatic modules<\/em>\u00a0was introduced. Moving a traditional JAR (without module descriptor) from the classpath to the module path turns it into an automatic module. Such an automatic module exports all of its packages and depends on all other resolved modules. Additionally, automatic modules themselves\u00a0can<\/em>\u00a0still access code on the classpath.<\/p>\n

So, instead of waiting for libraries to be modularized, application developers can take matters into their own hands. Traditional JARs can be used as if they were modules. For an example of automatic modules in action, look at\u00a0Paul’s post<\/a>\u00a0where he uses Vert.x JARs as automatic modules in an application.<\/p>\n

Automatic Module Name Derivation<\/h3>\n

Still, the question remains how you can express a dependency on an automatic module from application modules. Where does its name come from?<\/p>\n

There are two possible ways for an automatic module to get its name:<\/p>\n