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.
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)
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).