... and run(time) with it!

November 20, 2006 3:42 PM

How best to extract the Java runtime environment for repackaging with an application?

I need to package the JRE on windows and linux in a ./jre directory for distribution with my application, and I'd like to do so with a minimum of fuss and registry|/usr/local mess. How should I go about it?

posted by ChrisR to Computers & Internet (19 answers total)

Frankly, that sounds like a nightmare. On the Windows side, doesn't Sun's JRE packaging use MSI/Windows Installer? If so it is almost certainly scriptable, or at least should have command line arguments to do a silent install. Can't your installer just have some logic along the lines of, "Is Sun JRE installed already? If yes, skip. If no, run bundled JRE in silent install mode."
posted by Rhomboid at 3:54 PM on November 20, 2006

Response by poster: Sadly, no. Leaving aside the business reasons, I have to repackage this. This can't be new -- Azureus does it, as do many Eclipse-based products.

I'm just not sure how to go about even googling for something as basic as "java bundled installer" :)
posted by ChrisR at 4:02 PM on November 20, 2006

100% of the packages and installers I've used for software that require a JRE has said up front, "Install Java first."
posted by rhizome at 4:04 PM on November 20, 2006

You should ask at Azureus directly - aren't they an open-source project?

Next - you may want to try different search parameters with Google: "Java runtime deployment options"
posted by jkaczor at 4:05 PM on November 20, 2006

For linux, you could install the jre in the jre directory, and write a shell script that starts up your java program with the jre that you bundled with your application and the classpath that you decide to specify.

There are installers (I think Install Anywhere is one) that set that stuff up for you and are great for end users installs.
posted by scalespace at 4:09 PM on November 20, 2006

Azureus requires you to have installed the JRE prior to installing the Azureus application.

I develop a cross platform Java app for my employer. There are packages for each platform (Windows, Linux, Solaris) built using Ant build scripts that bundle install scripts with our app. On Windows, the install (batch/.BAT) script kicks off the JRE install (which is the official Sun MSI). On Linux, the the install (Bash) scripts kick off the JRE install (which is the Sun self extracting archive). We then use environment variables to point to the JRE that should be used.

It's messy, but it works.
posted by kableh at 4:39 PM on November 20, 2006

Yes, Azureus does not do this. They do use exe4j to make it look more like a native application, but you still have to first download and install the JRE from Sun.
posted by Rhomboid at 4:44 PM on November 20, 2006

Response by poster: Well, damn.

We definitely need to manage the installing part of the equation with our own packaging tool, so this is unlikely to work out for us. More importantly, we CANNOT create any registry garbage on Windows, which eliminates wrapping the Sun installer completely.
posted by ChrisR at 4:47 PM on November 20, 2006

Although from the exe4j feature list:

Optional distribution of a bundled JRE

exe4j allows you to distribute your own private JRE with your application. This way you can ensure that your application's requirements are definitely met. You can even configure where the JRE is located.

So I guess that's it.
posted by Rhomboid at 4:48 PM on November 20, 2006

I searched the exe4j docs and there's not much in the section about bundled JREs other than this:

Tip: To distribute your own JRE, simply put the JRE in your distribution and define a directory search sequence entry with the appropriate relative path (e.g. jre) as the first item.

I can't tell if that implies that the generated .exe file will first try to install the bundled JRE (which would put tons of stuff in the registry and possibly require admin privileges) or if it means that it will just find the necessary DLLs and JARs in that dir and use them without needing them to be installed.
posted by Rhomboid at 4:55 PM on November 20, 2006

Good luck with the not creating registry garbage thing.
posted by flabdablet at 5:23 PM on November 20, 2006

Response by poster: Rhomboid, that's exactly what I want -- exe4j just doesn't document how they accomplish it.
posted by ChrisR at 5:33 PM on November 20, 2006

launch4j is a good option. It can bundle the jre or have the user install one.
posted by zipperhead at 5:50 PM on November 20, 2006

I use install4j on a frequent basis. install4j uses exe4j, but I haven't used it as a standalone product in ages. I cannot remember the precise locations of the options you want, but I can give you the overview.

Let's assume you're using just exe4j (it's relatively cheap, as compared to the full install4j installer, IIRC). You proceed like so:

Build your program into a .jar file (using whatever method you like). Put that jar file into a directory, e.g. "iMage/". Install the appropriate JVM on your machine. Find the root directory of the JRE (not the SDK); on Windows this is under Program Files (while the SDK is off the C:\ root); on linux, you'll have to check the JAVAROOT environment variable, 'cause who knows?

Copy that whole Java root directory into your program folder. You now should have:
./iMage
....iMage.jar
....j2se_jre-1.4.2_13/

Open up exe4j. Configure your program's launcher. Somewhere buried in the options is a path to the JVM. Set that to "./j2se_jre-1.4.2_13/" (or whatever your actual Java root is called). Add the launcher to your directory:

./iMage
....iMage.jar
....iMage.exe
....j2se_jre-1.4.2_13/

Now, zip the whole ./iMage directory up. Distribute the zip file.

If you need more power than that, you should look at install4j if you want an automated installer.
posted by Netzapper at 5:57 PM on November 20, 2006

Response by poster: We have our own installer -- we build software for very specific environments, and provide our own package management built on platform-specific installation tools. All of this means that exe4j and install4j aren't the right thing for us, regrettably.

What I need is a sun-provided downloadable tarball containing the JRE that I can ship the same way IBM ships a JRE with WebSphere, but I am beginning to think that's not gonna happen.
posted by ChrisR at 6:05 PM on November 20, 2006

Can't you just convince your organization to spring for a exe4j license then?

Failing that, I suspect what their product does amounts to essentially duplicate the functionality of the javaw.exe wrapper. It looks like if you know the location of the JVM.DLL you can dynamically create the JVM with LoadLibrary("path\to\jvm.dll") / GetProcAddress(handle, "JNI_CreateJavaVM") / GetProcAddress(handle, "JNI_GetDefaultJavaVMInitArgs") and then call those functions. See j2se\\share\bin\java.c and j2se\\windows\bin\java_md.c in the JDK source. If you can duplicate this functionality in your own launcher it looks like you can instantiate a JVM from DLLs in a directory without needing anything installed.
posted by Rhomboid at 6:24 PM on November 20, 2006

Oh, I didn't preview.

What I need is a sun-provided downloadable tarball containing the JRE that I can ship the same way IBM ships a JRE with WebSphere, but I am beginning to think that's not gonna happen.

Can't you pretty much get that just by taking the whole directory tree under jre1.5.0_xx from a standard JRE install?
posted by Rhomboid at 6:27 PM on November 20, 2006

Response by poster: Yes, but the issue is in getting to that install stage in a mostly cruft-free fashion. This is no problem on the *nixes -- those are the easy ones. This is, however, a problem on windows, where the installer registers the app, etc...

I could do that on a box and package up the results, but that leaves a VM installed on that machine, and our product commits to leaving the machine unmolested to the maximum possible extent.

It's a pain, but I think I might just have to suck it up and do some preprocessing, as you suggest.
posted by ChrisR at 9:14 PM on November 20, 2006

Best answer: You only have to do that once, on a dev machine, and then just keep that tarball around. I would presume that your dev machines have the regular JRE and JDK installed already, otherwise they wouldn't be dev machines, so it seems pretty moot.
posted by Rhomboid at 10:36 PM on November 20, 2006