7

I run the following command to create a native bundle for a .jar file:

javapackager.exe -deploy -native image -srcfiles <files> -appclass <class> -outdir out -outfile test

Using Java 8u171/172 the bundles/AppName/ folder (containing the .exe for starting the Java application and some other stuff) contains the following DLL files:

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
msvcp140.dll
msvcr100.dll
packager.dll
ucrtbase.dll
vcruntime140.dll

Most of these seem to be also present in the runtime/bin/ subfolder.

In contrast to that, running the same javapackager command with Java 8u161 only results in the following DLL files being included (again, in addition to the .exe and other stuff):

msvcp140.dll
packager.dll
vcruntime140.dll

I think 8u161 is actually missing the msvcr100.dll (as per this bug), but otherwise it seems a lot more reasonable.

Do I really need all those api-ms-win-* DLLs in the bundle folder? Mind you they are still available in the runtime/bin/ folder for the included JRE to use, but somehow I can't imagine they are necessary for initial execution of the AppName.exe.

I found this OpenJDK commit which seems to reflect this change. It fixes the mentioned issue in 8u161 and adding the api-ms-win-* DLLs seems deliberate. I'm still not convinced that all of them are required though, although I have no good reason for it other than that it seems weird. The application appears to run fine without them, but of course I can't be sure that this will be the case in any situation.

user2375667
  • 463
  • 3
  • 10
  • 1
    This is old, but I think the reason behind it is, that starting with this version, the `javapackager` seems to be a backport from Java 9+. This coincides the the folloing and yet still to fixed issue [here](https://bugs.openjdk.java.net/browse/JDK-8205991), which also seems to affect the successor application called `jpackager`. – dzim Mar 29 '19 at 10:35
  • And yes, they seem to be necessary. – dzim Mar 29 '19 at 10:36
  • I know this is an old question, but did you find a solution? I have the same problem with lots of duplicate .dll files. – AbstractVoid May 06 '22 at 18:17
  • With Java 8 and Javapackager I haven't really seen any different behaviour (in versions beyond this, although I haven't tried all) or figured out if some DLLs actually aren't necessary. The new `jpackage.exe` in newer JDKs (I'm currently using it with OpenJDK17) doesn't have any DLLs in the folder with the application exe, but of course that doesn't really help if you need to stay on Java 8 for example. – user2375667 Jul 07 '22 at 23:37

0 Answers0