Summary

When jpackage generates a run-time image using jlink no service bindings will be performed on the default module set. This is to align the jpackage implementation to what JEP 392 describes.

Problem

JEP 392 describes in the "Runtimes" section:

The default set of jlink options used by jpackage is

--strip-native-commands --strip-debug --no-man-pages --no-header-files

but this can be changed via the --jlink-options option. The resulting
image will not include all available service providers; if you want 
those to be bound then use --jlink-options and include --bind-services
in the list of jlink options.

That is, it describes that no service binding will be performed, yet it actually does, before the modules set is being passed to jlink via --add-modules.

jpackage has a notion of ALL-DEFAULT modules when generating a run-time image for an application. When the token of ALL-DEFAULT gets resolved - which includes all modules that export API - service bindings are included. This is problematic when the base JDK running jpackage is JEP 493 enabled. Such a JDK doesn't allow for the jdk.jlink module to be included in the resulting run-time image. Since ToolProvider API is an exported and public API, including service bindings would cause jdk.jlink to be included in the output image as it provides implementations for jlink and jmod via the ToolProvider interface. Therefore, jpackage on a JEP 493 enabled JDK would fail, while it would pass on a JDK including JMODs. An inconsistency.

Solution

When resolving the ALL-DEFAULT token in jpackage don't perform service binding of the API exporting modules of the JDK. The resulting set of modules might be smaller as before, but it allows for a consistent set of modules to be included in the default run-time image jpackage generates, regardless of whether the base JDK is JEP 493-enabled or not.

Specification

The relevant change in jpackage is this:

@@ -99,8 +100,10 @@ private static Set<String> getDefaultModules(

         ModuleFinder finder = createModuleFinder(paths);

+        // Don't perform service bindings by default as outlined by JEP 343
+        // and JEP 392
         return Configuration.empty()
-                .resolveAndBind(finder, ModuleFinder.of(), roots)
+                .resolve(finder, ModuleFinder.of(), roots)
                 .modules()
                 .stream()
                 .map(ResolvedModule::name)

That is, no service binding is performed by default when the ALL-DEFAULT token is resolved. That means that the resulting run-time image produced by jpackage might include fewer modules than prior to JDK 24.

If a user wishes to produce a similar run-time image than before, the --bind-services option would need to be passed in addition to the default jlink options --strip-native-commands --strip-debug --no-man-pages --no-header-files:

$ jpackage [...] --jlink-options \
        "--strip-native-commands --strip-debug --no-man-pages --no-header-files --bind-services"