JDK-8155955 : packager needs to determine the root modules to create JRE image
  • Type: Bug
  • Component: tools
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-05-03
  • Updated: 2016-06-30
  • Resolved: 2016-06-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b125Fixed
Related Reports
Blocks :  
JDK-8149975 - [packager] Programmatically Determine JDK or JRE Modules
Description
The packager needs a way to programmatically determine if a module is a JDK module and should not be included in the delivered JRE, or if the module is a JRE module and is OK to deliver.
Comments
There is no distinction between JRE and JDK any more. This request is solely for packager to build an image for a non-modular application without imposing burden on the user and to keep the behaviorial compatibility as in JDK 8. It is agreed that packager at build time generates the list of modules that are used to create an image for non-modular application and includes in jdk.packager.jmod that will always have the correct list for a given version (modules may be added/removed in a release). To creae an image using JDK 10 JMOD files using JDK 9 packager, jdk.packager.jmod must be present from the specified modulepath and JDK 9 packager will use the root module list from JDK 10 jdk.packager.jmod. This way the image created by packager will contain the right list of modules. ModuleFinder currently finds modules for runtime. packager will need to detect if the packaged module of jdk.packager is found and matching the version of the resulting image being created. The proposed patch will provide an API to get a ModuleFinder configured for link phase and JDK-8147894 will refresh the jlink API to support that.
15-06-2016
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155955/webrev.02/ +1
15-06-2016
When a developer bundles with a non modular jar, I'm trying to match exactly what they get when they run "java -jar foo.jar". This list is ALL-DEFAULT minus the non-redistributable jars such as jdk.deploy. Well, you see them in that patch Mandy provided. The only other approach which breaks backwards compatibility is to use jdeps to determine the dependent modules and link with only those modules. But then to not break backwards compatibility, since they won't have the entire runtime, I'll need to be able to find all modules that are loaded dynamically as well.
06-06-2016
I see Mandy has proposed a helper in the jlink packager package. This creates a maintenance issue in the JDK and is just not the right place for this. What is the FX packager so concerned with the legacy notion of JRE?
04-06-2016
There are use cases where the developers will want the entire JRE such as when developers allow plugins to their applications and the plugin can use any module in the JRE. Either of those options will work. I think option #1 is a little cleaner.
03-05-2016
With jlink, packager should not concern with the difference of JRE vs JDK while instead creating an application run-time image with the required modules. For compatibility and size concerns, the current default behavior of packager is to create an app runtime image for a classpath application with the same root set as JRE image. Over time we should encourage developers to package their applications to specify the required modules specified via -addmods option rather than an entire JRE that may contain several modules that are not used by the application, for example, java.corba, java.xml.ws, java.xml.bind. Two possible options considered: 1. create a `jdk.jre` aggregator module at build time. `jdk.jre` is not linked in JDK and JRE image. Packager can use ModuleFinder API to detect if `jdk.jre` is present and resolve it and the resulting set of modules minus jdk.jre will be used to pass to jlink as root modules. 2. Generate JRE_MODULES key in the `release` file in the JDK image. This option works when JMOD files are shipped with JDK image and `release` file and JMOD files are in a well-defined location of JDK. For example, packager can find ${java.home}/jmods and ${java.home}/release where ${java.home} may be the same JDK version as the packager or if --modulepath is specified to use packaged JDK modules from a different version, the packager can use ModuleFinder to find the location of java.base.jmod in the resolved graph and read `release` to get JRE_MODULES value.
03-05-2016