9
\$\begingroup\$

Is it possible to turn a Java application into a standalone package that runs "out of the box"? The end user should not be required to install any Java JRE, nor should the installer contain a JRE and install it for the user.

The final distribution should contain a native executable (hopefully one for each of Windows, Mac and Linux) along with the regular data files and any extra JARs if needed. I'm not looking for a "one file" solution specifically -- I'd actually like data files to be unobfuscated.

How can this be done?

\$\endgroup\$

2 Answers 2

8
\$\begingroup\$

The main point is that the end user should not be required to install any Java JRE, nor should the installer contain a JRE and install it for the user

You can use Java source/bytecode to machine code compilers. There are Excelsior JET for Windows and Linux (requires license) and GNU Compiler for Java which is old.

If it's ok to contain Java with your game without installing it, then you can probably package Java Runtime with your game and use a start script to set JAVA_HOME to your JRT location prior to launching the game.

EDIT: (comment response) Using the second option, you will still need different builds for different platforms using the appropriate Java runtime for that platform.

EDIT2: Aslo see Dmitry's recent comment.

\$\endgroup\$
5
  • 3
    \$\begingroup\$ If your game is non-commercial, you can get a free Excelsior JET license. \$\endgroup\$ Commented May 12, 2013 at 6:53
  • \$\begingroup\$ The second option sounds good, but if I package my Windows JRE, is it crossplatform? Similarly with Excelsior, would I need to run such compilers on the three different OSes? \$\endgroup\$
    – leokhorn
    Commented May 15, 2013 at 7:42
  • 1
    \$\begingroup\$ You would need to bundle that platforms JRE with each release, but essentially it will remain cross platforms. \$\endgroup\$
    – Derek
    Commented May 15, 2013 at 19:26
  • 1
    \$\begingroup\$ @leokhorn At some point, there has to be native code. Either you have to compile to native code, or you have to run on a native VM. There is no plan C. \$\endgroup\$
    – Adrian
    Commented May 16, 2013 at 19:28
  • 1
    \$\begingroup\$ GCJ is now officially dead, whereas Excelsior JET Standard Edition has become free for commercial use as well, though if your only concern is the ease of distribution, there are many alternatives \$\endgroup\$ Commented Mar 6, 2017 at 7:53
1
\$\begingroup\$

For Mac, see the Oracle documentation for packaging a Java app for Mac. They've set up Java 7 so that you can bundle the runtime into an application bundle containing your jar files (.app is a folder treated as executable really), which is required for distribution on the Mac App Store. Basically, the .app bundle does mostly the same as what Eren's JAVA_HOME answer suggests, but is packaged as a "native" Mac app.

For distributing without the Mac App Store, you can get away with not signing the app, telling your Mountain Lion users that they can get around Gatekeeper by right-clicking (or ctrl+click) on your app and clicking on "Open" when they first open the app. This will still warn them that the app is not signed, but it will allow them to open it anyway, and then allow them to double click on the app for subsequent opens.

(side note: you could also get away with Linux-style marking of shell scripts as executable and then construct a .app bundle around that. NetBeans does this on Mac and Linux, though without a bundled JRE/JDK)

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .