How do I bundle a Solaris JRE with install4j without running the install4j application on Solaris? - install4j

The JRE download wizard in install4j only offers Linux and Windows JREs. I need to build a media file that bundles a Solaris JRE. install4j supports building custom JRE bundles but it's JRE Bundle wizard states:
"Please note that the JRE Bundle wizard can only create JRE bundles
for the platform you're running on."
This seems like a serious omission as compared to the other multi-platform install buliders (i.e. InstallAnywhere and InstallBuilder) both of which provide bundled Solaris JREs.
Can I not just unzip/tar a Solaris JRE on my Linux build box and bundle it? Or is there a limitation of the mechanism used to bundle it?
Even though we support Solaris, Solaris boxes are in limited supply.

Can I not just unzip/tar a Solaris JRE on my Linux build box and bundle it?
You would have to create the tar.gz file for the bundle manually as explained here (at the bottom of the page).
However, I would rather suggest adding a requirement that Java is installed on the Solaris box. Bundling a JRE on Solaris is somewhat risky since particular JRE versions require certain OS patches.

Related

createbundle command line refuses to generate Mac bundle on Windows

https://stackoverflow.com/a/57802270/6944068 says "You can generate macOS JRE bundle on Windows."
However, my attempt failed, see transcript:
C:\develop\projects\id-gui\target\downloads\jre-bundles>..\install4j8.0.8\bin\createbundle C:\develop\projects\id-gui\target\downloads\jre-bundles\zulu11.41.24-sa-jdk11.0.8-macosx_x64
The JRE bundle wizard can only create JRE bundles for the platform you're currently running on.
The java home directory C:\develop\projects\id-gui\target\downloads\jre-bundles\zulu11.41.24-sa-jdk11.0.8-macosx_x64 contains a JRE for a different platform.
What's wrong?
The cross-platform generation only applies to bundles that are generated via the mechanism configured on the "General Settings->JRE bundles" step. The createbundle command line tool creates "pre-created JRE bundles", in the install4j IDE you would do the same with "Project->Create a JRE bundle". Those bundles can only be generated on the platform that they are intended for because they rely on a working local installation.

What options are there for using Zulu?

We need to migrate our OpenJDK-based application to Zulu, which uses install4j.
What approaches have the best long-term viability, in terms of EJ support and feasibility:
Offer pre-built bundles for download?
Install Zulu on a machine and run some scripts to massage the Zulu JDK into a JRE bundle?
Cross-platform capabilities for option 2., e.g. unpack a Mac Zulu on a Windows machine and run a script to generate a Mac bundle?
As of install4j 8.0.7 there is no JDK provider for Zulu in install4j.
You can use "Project->Create a JRE bundle" or the command line tool `bin/createbundle" to create JRE bundles from Zulu installations.
There is no way to create JRE bundles in a cross-platform way for pre-created JRE bundles.

Does install4j need a jre on the clients system?

I don't want to be dependent on that java is installed on the system or not
Our product already ships internally with a vm so the user doesn't have to install any java or need to have any java installed.
But this i also want for my installer of our product, there should be no need to have java there on the system to install the product, is this possible with Launch4J?
Because it is always tricky when reading the docs, you can bundle a jre, but what does that mean? Does the installer use that itself?
Yes, a JRE is necessary to run the installer, but you can bundle a JRE with install4j, so no "global installation" of a JRE is requried.

How do i prepare a JRE of Java 1.8.0 EA for shipping with my Mac OS X app's installer?

My goal is to bundle a JRE of JDK 1.8.0 ea (build 120 in this case) with my application files, so that the launcher which is generated by install4j will utilize this jre to run the app.
Now, when i'm trying to set the JRE in the media files options, i can't do the same as in the windows version with a windows JRE. In that case, i was just pointing to the directory the JRE resides in. As i see in the installer build log, it's expected to have a jre.tar.gz in the path that i set manually. So i packed the JRE subdir of the JDK into a jre.tar.gz file. Now, the installer is built without warnings or errors. But when i try to start the installer, it shows me an internal error: "launch path is not accessible".
This is strange because i expected an error to maybe come up when i'm launching the App, but not at this point already.
The opposite comes up when i'm using a JRE v1.7 to set as a bundled JRE in the media file. In this case, the installer starts and the program - of course - doesn't.
How do i have to prepare my Java 8 JRE to ship with my app but not cause the installer to crash?
Use
Project->Create a JRE Bundle
in the install4j IDE. It may not work with Java 8 though. We will support Java 8 JRE bundles when it is released.

How to specify which JRE to use in Netbeans?

I have two JRE in my system. One is 32-bit and the other one 64-bit. In Eclipse I can configure both and choose which one to use when running my application.
I'm wondering if I can do the same thing in Netbeans. I've tried to go to Project Properties, Libraries and then tried to configure a new JRE there, through Manage Platforms, but it doesn't accept the directory of my JRE. How should I proceed?
Be aware that I'm talking about JRE, and not JDK ;)
EDIT: I managed to make it work by downloading a new 32-bit JDK and selecting its directory. I still couldn't make it accept a JRE directory.
Whether or not you can run Netbeans with just the JRE depends on what bundle you have downloaded. In Netbeans 7 only C/C++ and PHP bundles can be run with the JRE.
Older versions of Netbeans include more languages under this JRE umbrella, but the principle is the same.
The JDK contains the JRE plus tools to debug and compile code, so if you're doing anything Java based apart from just running the IDE, netbeans depends on the JDK.