How to find automatic modules with javapackager

Question

I am bundling an app using javapackager wherein the main jar is a module with a module-info.class but it relies on many other jars that are plain old jars, so I call them out as automatic modules in module-info.java. However, javapackager complains about not being able to find them. How do I make it find the jar files for automatic modules?

Exception: jdk.tools.jlink.plugin.PluginException: java.lang.module.FindException: Module rcf not found, required by com.username.commander.ui
Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: Bundler "Mac Application Image" (mac.app) failed to produce a bundle.
    at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:374)
    at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:348)
    at jdk.packager/com.sun.javafx.tools.packager.Main.main(Main.java:496)

I have tried specifying the module path (first dir has just the main module jar, second dir has all the non-module jars):

/Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/bin/javapackager -deploy -native image \
-name Commander -title Commander -vendor "username" \
--module-path /Users/username/Dropbox/coding/commander/Commander-java/moduleJars:/Users/username/Dropbox/coding/commander/Commander-java/packageJars \
--module com.username.commander.ui/com.username.commander.ui.AppWindow \
-srcdir /Users/username/Dropbox/coding/commander/Commander-java/packageJars \
-outdir /Users/username/Dropbox/coding/commander/Commander-java/target \
-outfile Commander \
-Bruntime=target/jre-9.0.1 -Bicon=src/main/resources/icons/commander.icns \
-BappVersion=1.0 \
-Bmac.CFBundleIdentifier=com.username.Commander \
--add-modules java.base,java.desktop,java.naming,java.sql,java.xml,java.logging,java.management,java.scripting,java.compiler,java.rmi,java.activation \
--limit-modules java.base,java.desktop,java.naming,java.sql,java.xml,java.logging,java.management,java.scripting,java.compiler,java.rmi,java.activation \
-nosign -v

Answer 1

So after more research I've confirmed nullpointer's answer: automatic modules are simply not supported due to their access to the class path, which breaks the modularity of Java 9 modules. More details can be found in this discussion from about a year ago: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008559.html

So until Oracle and the Java community decide how to deal with this, javapackager in Java 9won't let you use automatic modules. If you bundle an app that uses a module, all your dependencies must be modules as well. If you require non-module dependencies, then you have to make all your jars non-modules. If you do make your jar(s) modular, then you have to make all your dependencies modular, which can be a lot of work or not possible if you don't own those dependencies.

If you make everything a non-module, the downside of course is that you don't get the advantage of a slimmer runtime that includes only the modules that you need. There is a workaround for this here.

Answer 2

Looking further the exception seems to be justified in its implementation over automatic modules, but the message seems to disguise as stated in the BUG#JDK-8189671.

It seems that a plugin reports that an automatic module being used as root because of missing module-info.class resource! jlink should detect attempt to use automatic module as root upfront and report error clearly.

Hence, you should be specifying the --module-path to the modularJars instead.

Additional Note: The Java packaging tools(javapackager) use the jlink tool to generate a custom JRE for the application.