Bug ID: JDK-8154895 Revisit javapackager module path related options

Type: Sub-task
Component: deploy
Sub-Component: packager
Affected Version: 9

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2016-04-21
Updated: 2016-06-09
Resolved: 2016-06-09

JDK 9
9Fixed

http://openjdk.java.net/jeps/275 documents the following command-line options:

-jdkmodulepath <path>
-modulepath <path>(:<path>)*
-appmodulepath <path>(,<path>)*
-detectmods
-detectjremods

This issue is to revisit the module path related command-line options for JDK 9.

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/059e3e937e89
09-06-2016
+1
09-06-2016
New changeset: http://cr.openjdk.java.net/~cbensen/JDK-8154895/webrev.02/
09-06-2016
+1 pending the fix for the white-space issue (and double-checking before you push that the files are tracked as renames)
09-06-2016
Regarding the history, this might just be a webrev issue...you can double-check by running "hg diff--git"
09-06-2016
As for the changes themselves, I skimmed them and didn't see anything obvious that jumped out at me. It built fine for me, too.
09-06-2016
I used: hg mv <source> <target> but yeah, history didn't follow. I'm not sure why.
09-06-2016
Note: make sure that the following shows a "rename from" and "rename to" line rather than added / deleted: hg diff --git ...
09-06-2016
How did you rename the following files? Webrev thinks they are removed and then added rather than renamed: modules/fxpackager/src/main/java/jdk/packager/internal/JDepHelper.java modules/fxpackager/src/main/java/jdk/packager/internal/JLinkBundlerHelper.java modules/fxpackager/src/main/java/jdk/packager/internal/Module.java modules/fxpackager/src/main/java/jdk/packager/internal/ModuleManager.java modules/fxpackager/src/main/resources/jdk/packager/internal/JLinkBundlerHelper.properties
09-06-2016
Thanks Kevin. I just found that as well. Not sure how I missed it earlier. I'll push a new patch soon.
09-06-2016
I'm reviewing and testing it now. I found one problem so far that must be fixed: $ gradle checkrepo :checkrepo modules/fxpackager/src/main/native/library/common/Package.cpp :trailingWhitespace: Found 1 whitespace or executable issues To correct, use bash tools/scripts/checkWhiteSpace -F -x :checkrepo FAILED
09-06-2016
Review: http://cr.openjdk.java.net/~cbensen/JDK-8154895/webrev.01/
07-06-2016
It's really confusing and the argument parsing is not done well. I shouldn't have even brought up -B, it really isn't an option. All arguments are -B, for instance -modulepath is a shortcut for -Bmodulepath. Anytime a developer needs the ability to load a JAR dynamically this will be required. The equivalent of -jdkmodulepath is a requirement of the Java Packager. As is currently the case, the use case goes there is a bug in the packager introduced in JDK 9.1, but JDK 9.0 worked just fine. But for some reason the developer needs to deploy with JDK 9.1. Currently the developer can choose the JRE to bundle regardless of the JDK the packager is bundled with. So this would be a feature loss. So if we deliver the jmod files with the JDK the developer can simply run: javapackager -deploy... and the default jmod files that ship with the JDK will be used. I prefer this because it is backward compatible. But if they want to use the packager from JDK 9.0 to bundle with the JRE from JDK 91, they have the option to run: javapackager -deploy -jdkmodulepath \path\to\jdk\jmods ... The proposition of requiring the user to add -modulepath and we ship with the jmod files looses our backward compatibility story because they would be required to know the path to the jmod files and to add it to existing scripts: javapackager -deploy -modulepath \path\to\jdk\jmods ...
21-04-2016
Since there is an existing way to add launcher arg (-B option), I don't see -appmodulepath is helpful if you plan to rework it in the future anyway other than causing confusion. In addition, how typical do you expect a user wants to add modular JARs to the app image already created? Maybe supporting -B-modulepath as a workaround and decide on the supported options in a future release. You can determine the module version from module-info.class in the JMOD files. How does packager do differently if you package with a different JRE? Are you planning to link with different list of JRE modules according to the release version? Packager can't know the list of JRE modules of a future JDK version.
21-04-2016
Reworking the launcher args is a task that is slated for the future when reworking all of the CLI arguments. The current java packager convention, like class path is to have it be a major option, i.e. -optionname. Many options that are bundler specific are prepended with -B, so we could go with -Boptionname which would be -Bappmodulepath in this case. -Bmodulepath and -modulepath would be too confusing and the way the argument parser works, they'd be the same so that isn't an option. Again, my vote is for -appmodulepath as to avoid confusion and this will be reworked next release anyway. There is a need to differentiate JDK modules. If we ship with the jmod files, and we want backward compatibility, then this the java packager defaults to the bundled jmod files and without -jdkmodulepath the packager has no way to know if the user wants to bundle with a different JRE than the one that's included with the JDK or not. This allows that.
21-04-2016
Some notes on the discussion I had with Chris on packaging a modular application: -appmodulepath is an option to configure the native launcher created by packager. It allows a user to copy additional modules to some location in the app image and alter the module path for launching the application. My suggestion is to separate the options for launcher configuration from the options to create the app image, e.g. might be to prefix launcher config related options as -launcherArgs "-modulepath <path> ...." -jdkmodulepath is to specify an alternate location of JDK JMOD files. There is no need to differentiate packaged modules for JDK modules and user modules. The user can specify multiple paths with -modulepath option e.g. -modulepath <user-module-path>:<jdk-jmods-path>. If packager has a default module path for JDK packaged modules, it can append the default path to the end (see java.lang.module.ModuleFinder)
21-04-2016
I've been working on this and I have a first pass at it but it isn't complete. It looks like -detectmods and detectjremods can safely be removed without too many side effects or loss of features. It does make it when bundling with an unnamed jar very difficult to reduce the size of the bundled runtime. -appmodulepath and -modulepath must stay. -jdkmodulepath really is needed if the jmods directory does ship with the JDK. If it doesn't then it could be argued to not have it. But it still allows the Java Packager to know a bit more about the JRE it's bundling which is very nice from a bundling perspective. My current thought is we keep it and just don't document it unless jmods don't ship with the JDK.
21-04-2016