Guide: Managing JREs
Please Note: this guide assumes you have looked through:
When JWrapper builds your app it will produce two versions - Online and Offline. These achieve the same end goal - installing your app, but they work differently and are potentially suitable for different cases.
When JWrapper builds your app it will produce two versions - Online and Offline. These achieve the same end goal - installing your app, but they work differently and are potentially suitable for different cases.
Online - No JRE Included
The Online build does not include any JRE within the package itself. This keeps the size of the executable very small (roughly less than 1MB for a small to medium sized app). If your app allows it then when the online build launches on a computer it can pick up an existing detected JRE, otherwise it will need access to your update URL to download the JRE package created when the build was run.
Offline - JRE Included
The Offline build includes a heavily compressed JRE within the executable. When it is launched it extracts and uses the JRE it has bundled with it. This leads to a larger executable but does not require access to your update URL or to download any additional files.
If you do not use an update URL then JWrapper can build only offline executables.
If you do not use an update URL then JWrapper can build only offline executables.
Accepting or Rejecting a Detected JRE
When the online wrapper runs your app it may detect one or more JREs and perform a test run with your app to see if they are suitable.
If you specify a JWrapperJreCompatibilityApp virtual app then JWrapper will run this with each detected JRE until it finds one that your compatibility-testing virtual app accepts. This allows your app to check far more than the vendor/version of a JRE (which would fall foul of a broken JRE) and perform any test of validity you like including using JWrapper APIs to discover more in depth information. It will also run with the options you specify giving you peace of mind that you can specify more esoteric options and incompatible JREs will be naturally filtered out.
Your compatibility app can use the methods in the JWJreVerifierApp API provided by JWrapper to signal on exit whether the JVM is acceptable or not. If your compatibility app fails to run, crashes or otherwise doesn't return a valid result the JRE will be rejected.
If you specify a JWrapperJreCompatibilityApp virtual app then JWrapper will run this with each detected JRE until it finds one that your compatibility-testing virtual app accepts. This allows your app to check far more than the vendor/version of a JRE (which would fall foul of a broken JRE) and perform any test of validity you like including using JWrapper APIs to discover more in depth information. It will also run with the options you specify giving you peace of mind that you can specify more esoteric options and incompatible JREs will be naturally filtered out.
Your compatibility app can use the methods in the JWJreVerifierApp API provided by JWrapper to signal on exit whether the JVM is acceptable or not. If your compatibility app fails to run, crashes or otherwise doesn't return a valid result the JRE will be rejected.
Default: Reject all Detected JREs
If you do not specify any compatibility app then JWrapper will assume that no detected JREs are valid and will always use the bundled / downloaded JRE.
Updates make no assumptions
When your app is updated to a new version, it may pick up the JRE from the previously installed version, however this will only happen if:
This gives you flexibility to update JREs across updates and accept/reject previously used JREs on whatever criteria you like.
- The JRE's JWrapper build version is the same on both the previous build's JRE and the new build's JRE (i.e. the JRE package is the very same package as the previous version)
- OR you have specified a JRE compatibility virtual app which, when run, accepts the JRE
This gives you flexibility to update JREs across updates and accept/reject previously used JREs on whatever criteria you like.
JVM Options
You can specify any JRE-specific options you like for runs of your app by using the following tags under the root tag in your JWrapper XML:
<JvmOptions>
<JvmOption>-Xmx256m</JvmOption>
<JvmOption>-Xrs</JvmOption>
</JvmOptions>
If these options are not supported by a JRE that the online wrapper is trying to pick up and use for your app then it will automatically reject the JRE.
<JvmOptions>
<JvmOption>-Xmx256m</JvmOption>
<JvmOption>-Xrs</JvmOption>
</JvmOptions>
If these options are not supported by a JRE that the online wrapper is trying to pick up and use for your app then it will automatically reject the JRE.