-
Bug
-
Resolution: Fixed
-
P3
-
17
ADDITIONAL SYSTEM INFORMATION :
Windows 10
A DESCRIPTION OF THE PROBLEM :
EXE launchers created by jpackage don't have Windows system DLLs in java.library.path and sets the path to match the current installation directory and its "app" subdirectory - so System.loadLibrary("ole32") will fail. If setting -Djava.library.path explicitly when launching jpackage, then jpackage does not append those two directories to java.library.path.
REGRESSION : Last worked in version 16.0.1
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use jpackage to generate launcher test.exe for the example program below.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should have java.library.path such that is compatible for loading Windows system DLLs.
ACTUAL -
In JDK16 jpackage, the test program performs System.loadLibrary() for "ole32", "user32", "advapi32","shell32","kernel32":
System.getProperty("java.library.path") => ... long list including "C:\Program Files\APPNAME;C:\WINDOWS\system32;"
In JDK17 EA - the result is:
java.lang.UnsatisfiedLinkError: no ole32 in java.library.path: C:\Program Files\Duncan Panama\app;C:\Program Files\Duncan Panama
---------- BEGIN SOURCE ----------
package duncan.panama.screensaver;
import java.util.Arrays;
/**
* Test issues with command line launch after using jpackage.
* <p>Build a launcher for this class as test.exe and copy to test.scr
*/
public class Test
{
public static void main(String[] args)
{
System.out.println("Application args: "+Arrays.toString(args));
try {
String[] props = new String[]{"jpackage.app-path", "java.library.path"};
for (String prop : props) {
System.out.println("System.getProperty(\""+prop+"\") => "+System.getProperty(prop));
}
String[] libs = new String[]{"ole32", "user32", "advapi32","shell32","kernel32"};
for (String lib : libs) {
System.out.println("System.loadLibrary(\""+lib+"\")");
System.loadLibrary(lib);
}
} catch(Throwable t) {
System.err.println("*** System load library FAILED *** "+ t.toString());
t.printStackTrace();
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
jpackage can be run with additional --java-options settings: "-Djava.library.path=c:\\Windows\\System32;C:\Program Files\APPNAME\appC:\Program Files\APPNAME" but this hardcodes the developers Windows PC %SYSTEMROOT% and anticipated installation directory into the installer EXE - these values may match the target Windows PC.
FREQUENCY : always
Windows 10
A DESCRIPTION OF THE PROBLEM :
EXE launchers created by jpackage don't have Windows system DLLs in java.library.path and sets the path to match the current installation directory and its "app" subdirectory - so System.loadLibrary("ole32") will fail. If setting -Djava.library.path explicitly when launching jpackage, then jpackage does not append those two directories to java.library.path.
REGRESSION : Last worked in version 16.0.1
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use jpackage to generate launcher test.exe for the example program below.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should have java.library.path such that is compatible for loading Windows system DLLs.
ACTUAL -
In JDK16 jpackage, the test program performs System.loadLibrary() for "ole32", "user32", "advapi32","shell32","kernel32":
System.getProperty("java.library.path") => ... long list including "C:\Program Files\APPNAME;C:\WINDOWS\system32;"
In JDK17 EA - the result is:
java.lang.UnsatisfiedLinkError: no ole32 in java.library.path: C:\Program Files\Duncan Panama\app;C:\Program Files\Duncan Panama
---------- BEGIN SOURCE ----------
package duncan.panama.screensaver;
import java.util.Arrays;
/**
* Test issues with command line launch after using jpackage.
* <p>Build a launcher for this class as test.exe and copy to test.scr
*/
public class Test
{
public static void main(String[] args)
{
System.out.println("Application args: "+Arrays.toString(args));
try {
String[] props = new String[]{"jpackage.app-path", "java.library.path"};
for (String prop : props) {
System.out.println("System.getProperty(\""+prop+"\") => "+System.getProperty(prop));
}
String[] libs = new String[]{"ole32", "user32", "advapi32","shell32","kernel32"};
for (String lib : libs) {
System.out.println("System.loadLibrary(\""+lib+"\")");
System.loadLibrary(lib);
}
} catch(Throwable t) {
System.err.println("*** System load library FAILED *** "+ t.toString());
t.printStackTrace();
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
jpackage can be run with additional --java-options settings: "-Djava.library.path=c:\\Windows\\System32;C:\Program Files\APPNAME\appC:\Program Files\APPNAME" but this hardcodes the developers Windows PC %SYSTEMROOT% and anticipated installation directory into the installer EXE - these values may match the target Windows PC.
FREQUENCY : always
- relates to
-
JDK-8272328 java.library.path is not set properly by Windows jpackage app launcher
- Resolved
-
JDK-8271155 Wrong path separator in env variable
- Closed
-
JDK-8263157 [macos]: java.library.path is being set incorrectly
- Closed