JDK-8217317 : Create jpackage native library for windows
  • Type: Bug
  • Component: tools
  • Sub-Component: jpackage
  • Affected Version: internal
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-17
  • Updated: 2019-03-22
  • Resolved: 2019-02-06
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.
Other
internalFixed
Related Reports
Duplicate :  
JDK-8212536 - Modify WindowsRegistry.java to use registry APIs directly
Relates :  
JDK-8218681 - Windows exe's generated by jpackage have wrong info
Relates :  
JDK-8217269 - jpackage Makefile improvments
Description
There is no jni library for java jpackage code to call.
As a result some operations are done by executing other commands that could be better accomplished in native code.
1.) the jpackage executable itself is invoked with args --icon-swap and --version-swap to modify the launcher to have the proper icon and version.  The code to handle this in jpackager should be moved to a new jpackage.dll and called directly.
This will allow jpackage to be built identically as on linux and mac, with no additional code.
2.) WinRegistry.readRegistry() executes "reg query <key>" to read a registry value.  This could easily be implemented in jni function.

Not sure if there is other code that could be better implemented in native code but at least these two cases.
Comments
http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ - jpackage launcher will now build same as Linux and OS X using SetupBuildLauncher. - jpackage.dll was added based on Windows jpackage.exe launcher which will have icon swap and version swap functionality called via JNI. - Some code formatting, clean up and minor improvements where done to icon and version swap code. No functional changes. - Windows registry will be read and enumerated via JNI as well. - isDirectoryInExclusionPath() will use native path comparison, since paths in registry and temp folder returned by Java code can be in short or long format, thus simple string comparison will not work. - Windows Defender workaround warning will be checked for --build-root as well if it is set. - Removed extra escaping from JPackageHelper for Windows, otherwise tests fails due to incorrect escaping. Our launcher used CreateProcess to launch java.exe by passing args from main() to CreateProcess. This is why I think we required extra escaping.
01-02-2019
yes - sorry jpackage.exe. jpackage has no code except on windows, and is built by just: $(eval $(call SetupBuildLauncher, jpackage, \ MAIN_CLASS := jdk.jpackage.main.Main, \ )) on linux and mac (in make/launcher/Launcher-jdk.jpackage.gmk) (I edited description to reflect this.)
29-01-2019
"This will allow jpackageapplauncher to be built identically as on linux and mac, with no additional code." Did you mean jpackage.exe? --icon-swap and --version-swap is part of jpackage.exe and not jpackageapplauncher.exe used to run packaged applications.
29-01-2019