This question is in regards to install4j 4.2.8.
We’re using install4j to create a “windows archive”-type media file for our java application. Although most users are happy to download our .exe installer, some customers require an msi and so we use this .zip artifact as the basis for an msi which is created using third party tools.
This works fine except when it comes to incorporating a bundled jre (non-shared). It seems that by default, install4j compresses certain jar files within the jre hierarchy (such as rt.jar) using the pack200 algorithm and decompresses them the first time the launcher executable is run.
This process obviously works fine for installs installed from an exe installer, but seems to fail a lot of the time from our msi install (which as mentioned before is created from the windows .zip artifact). I had a look in the install4j manual to see if there was some way to turn this compression off, but the jre bundle creating tool doesn’t seem to have any such parameter to do so. And the behaviour is nice to have, so it’d be nice to not have to do without it.
Any ideas as to why the unpacking process might be failing in some circumstances?
The unpacking process is done the first time you call a generated launcher. You could call a dummy launcher with a main class that returns immediately to reliably unpack the JRE libraries.