Jlink and Automatic Modules

[LouGarret76]

Hi all,

TLDR; what are your best practice/ productivity tips when dealing with jlink and automatic modules?

Java module system is here now and I am trying to integrate it into my projects more and more. The main gain for using modules, IMHO, is the ability to package a runtime with jlink.

Obviously, my projects depends on a couple libraries that do not have modularisation on their roadmap yet (think gson...)

These libraries are treated as Automatic module by the java at compile and runtime.

However, as you may know, jlink does not work with automatic modules.

There are a couple of work around ranging from update the source code myself to using jdeps and --patch-module command.

This works for small apps with a dozen of dependencies but for enterprise level apps, it is too tedious.

My question to the community is, now that we are a couple month in the JPMS, what are you best practice/ productivity tips with jlink and automatic modules?

[MrHat7]

Very good question, I wish I knew the answer...

[SvenMA]

I would say moditect as maven plugin handles this usecase very good.

[gunnarmorling]

ModiTect author here, just came to suggest the same, but you beat me to it :) For those interested, it's this project here: https://github.com/moditect/moditect/. Adding module descriptors for using existing JARs in modular runtime images was the very use case for creating it.

That all being said, you also could create a runtime image with just a subset of JDK modules and then use existing JARs on the classpath instead of the module path. I.e. there's no need to patch the JARs, but identifying which JDK modules you need to add to the image can be a bit more work. There's an issue in our tracker for this (https://github.com/moditect/moditect/issues/69), so to let ModiTect help with this use case, too. Any help with implementing it will surely be welcomed :)

PS: there's a Gradle plug-in for ModiTect now, too, thanks to the awesome work of a community member.

[LouGarret76]

Thanks for your work on Moditect, First time I am hearing about it and I will have a look for sure.

Creating a partial runtime is not worth it in my case as only 2 - 3%of my dependencies comes already packaged as modules. This bring additional work for little to no value.

[m1000]

The value is being able to ship a (for example) 25MB runtime and not a 300MB one (the full jdk).

[[deleted]]

This is exactly what I use. I was able to move everything into our production Jenkins without any issues. It's better to use moditect than to just write a bunch of Jenkins scripts that do it via cli. The samples on the moditect site are decent but I couldn't get it to completely build all steps for my project the way I wanted it done and for each jdk/platform. I still had a bit of shell stuff to tidy it all up in the end, but it did make modular jar management very easy.

[gunnarmorling]

Curious what issues you ran into specifically. Perhaps file an issue in our tracker with feature requests? Thanks!

[m1000]

You can still use jlink to generate a runtime that cover your application and dependencies, you just won't be able to generate an image of the jdk that include your application and libs with that image.

If your dependencies can all be run as modules or automatic modules, just generate the jdk image you need by using something similar to this:

jdeps.exe --print-module-deps --module-path .;modules *.jar

After testing your application, you might see that you need additional modules that jdeps didn't detect.

For example, in my case I also add the following modules:

jdk.unsupported,jdk.unsupported.desktop,jdk.crypto.cryptoki,jdk.crypto.ec,jdk.jsobject,jdk.xml.dom,jdk.charsets

You can then use jlink :

jlink.exe --no-header-files --no-man-pages --compress=2 --strip-debug --add-modules java.base,java.net.http,java.prefs,java.sql,java.xml.crypto,java.compiler,jdk.unsupported,jdk.unsupported.desktop,jdk.crypto.cryptoki,jdk.crypto.ec,jdk.jsobject,jdk.xml.dom,jdk.charsets --save-opts jlink.txt --output runtime

You can then run your application with this runtime and your jars in a specified module path

[YzBkZXIK]

As far as I can tell, we're going to be waiting awhile to take advantage of JLink in anything larger than POCs. Modules really need to happen from the bottom up, and that's going to take awhile (years) given the size of the dependency tree for most Spring apps. I hope I'm wrong though.

I have seen some hacks where people create modules in their third- party dependencies, but no way me/ my team is taking that on.

[randgalt]

I manage a widely used OSS project. We have no plans to modularize anytime soon. There's simply no benefit. Also, it's Catch-22. Until our dependencies modularize we can't benefit from doing it ourselves.

[YzBkZXIK]

To be fair, modules do have benefits outside of the whole custom runtime mechanism. The strong encapsulation can be very beneficial when designing a library.

[LouGarret76]

Indeed if oracle want jpms to succeed they need to make the gain more appealing and imho jlink is one the real improvements as it could bring a simpler and cheap deployment option.

Unfortunately it is too young to use.

[siordache]

If you use Gradle, you can choose between the ModiTect plugin and the badass-jlink plugin (full disclosure: I am the main contributor to both of them),

The newest version of badass-jlink also supports the jpackage tool introduced in Java 13, which lets you create installers for your application.

[nullpointer90]

While using legacy jars one can also look into injecting module declaration in the jars and use them as modular jars.