JDK-8150991 : [packager] Module Path Packager Arguments
  • Type: Sub-task
  • Component: deploy
  • Sub-Component: packager
  • Affected Version: 9-repo-jigsaw
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-03-01
  • Updated: 2016-04-12
  • Resolved: 2016-04-12
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
9Fixed
Description
Figure out new arguments for modular Java Packager.
Comments
Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/81ad92430d25
12-04-2016

There is something wrong with the webrev for at least the modules/fxpackager/src/main/native/library/common/IniFile.cpp file. It shows no changes when you click on any of the "diffs" links and yet the patch is showing changes. Odd. Anyway, I tested it on Linux and Windows and it all looks fine to me. The questions I have on the com.oracle.tools.packager API (and on the exported API in general) can be addressed separately. +1
12-04-2016

Review comments: * The new Platform class got me thinking about the public classes and packages a bit. Especially since this collides with a class of the same name in the JavaFX runtime API, javafx.application.Platform. - com.oracle.tools.packager is exported, so all classes in this package are public API. In addition to the name collision for Platform, which may not be a problem since applications are not likely to directly use the packager API, I see that you have a Module class. Who is expected to use the public classes in this package? If it is only for use by the packager itself, then it should not be exported as API. - The example code in the javadoc comments of the Platform class does not follow best practices for coding style (e.g., curly braces should be on the same line as the switch statement, etc)
12-04-2016

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.03/
12-04-2016

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.01/
11-04-2016

Yes, that was Jake sandbox was my intent for the first destination.
07-04-2016

Are you going to push this to the jake sandbox? If so, then go ahead and we'll get a build tonight. I skimmed it, but don't have time for a thorough review (I can do that when you go to generate a patch to push to 9-dev).
06-04-2016