How do I bundle a JRE in my JAR, so that it can run on systems without Java?

Question

I want to bundle a JRE inside my executable JAR, so that the exe can run on any system.

I have tried Launch4j, but that approach requires me to ship both the JRE and the

Answer 1

You cannot put a JRE inside a JAR file. (Well you can ... but it won't help.)

What you need to do is build and distribute an installer. The recommended way to create an installer is to use a commercial or open-source installer generator. (Google will help you find one.)

It is also possible to do embed a JRE in a ZIP file, as described here:

• How to bundle a JRE with Launch4j? (see the accepted answer)

The ZIP file contains the JRE and the application JAR, and other files that it needs. The user has to unzip the ZIP file to install the application.

---

.. but it's copying total JRE in client system of almost 100 MB. Is it possible to make JRE light weight?

Not really. The most (legal) light-weight way to distribute a JRE is to distribute an Oracle Java installer. Beware that the Java Binary License forbids the distribution of a cut-down JRE. If you want to go down that path talk to a lawyer first!!

---

Distributing Java apps with an embedded JRE is arguably a bad thing:

• It fills up the user's disk with multiple JREs.
• The JREs tend to be hidden away / not visible to normal security updates / patching / audits. Hence they tend to become a security liability.
• You need to regularly update your distributables ... to avoid foisting out-of-date / insecure JREs on the unsuspecting user.

---

From Java 9 onwards there is a better solution than embedding a standard JRE. Use the new jlink utility to create a tailored JRE for your application; see https://www.baeldung.com/jlink for a tutorial, and the Oracle Jlink manual entry.

Note that jlink addresses the concerns with embedded JREs that we mentioned above. But it clearly makes it your responsibility¹ to provide JVM security patches to your users in the form of new jlink'd distributables.

^{1 - In reality, it has always been an application supplier / vendor's responsibility to advise and assist customers in upgrading embedded JREs. Unfortunately, many vendors neglected this, leading to customers running applications with known Java vulnerabilities, and Sun/Oracle getting the blame ... unfairly ... for the vendor's failings.}

Answer 2

Late better than never. I used maven-shade-plugin in the pom.xml as follows:

        <plugin>
          <artifactId>maven-shade-plugin</artifactId>
          <version>2.4.3</version>
          <configuration>
              <transformers>
                  <transformer
                    implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
                  <transformer
                    implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                      <mainClass>${mainClass}</mainClass>
                  </transformer>
              </transformers>
              <!-- If false the shaded artifact takes the normal artifact name, such as,  "core-tools-1.0-SNAPSHOT.jar"-->
              <!-- Meanwhile, another non-shaded version takes the prefix Original, such as  "Original-core-tools-1.0-SNAPSHOT.jar"-->
            <shadedArtifactAttached>false</shadedArtifactAttached>
              <!-- Exclude signed Manifests from the UberJar -->
              <filters>
                  <filter>
                      <artifact>*:*</artifact>
                      <excludes>
                          <exclude>META-INF/*.SF</exclude>
                          <exclude>META-INF/*.DSA</exclude>
                          <exclude>META-INF/*.RSA</exclude>
                      </excludes>
                  </filter>
                  <filter>
                      <artifact>*:*</artifact>
                      <includes>
                          <include>sun/misc/**</include>
                      </includes>
                  </filter>
              </filters>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                      <goal>shade</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>