create a JAVA Standalone executable application to run on different platforms without any Installation

后端 未结 4 1503
北恋
北恋 2021-02-14 19:24

I have created a run time image for my Java application using jlink and I would like to be able to ship my app as an executable to different platforms.

Ideally, it woul

相关标签:
4条回答
  • 2021-02-14 19:47

    You can make an installer that installs the JDK and the application. Make the application an exe by using something like Launch4j and for a Mac executable follow this tutorial by Oracle: Packaging a Java App for Distribution on a Mac and lastly: For Linux

    Minecraft uses this method and as far as that i don't know any other way.

    If you want to make portable application, "make once run anywhere" type app then I'd suggest trying out a different programming language like C# which also requires the .NET Runtime but is embedded in Windows systems whereas Java needs to be installed manually.

    0 讨论(0)
  • 2021-02-14 19:47

    Also, have a look at SubstrateVM. This is not a true Java, however, it may help you in some cases like simple command line applications.

    Substrate VM is a framework that allows ahead-of-time (AOT) compilation of Java applications under closed-world assumption into executable images or shared objects (ELF-64 or 64-bit Mach-O).

    0 讨论(0)
  • 2021-02-14 19:51

    Yes, as of Java 8 there are two ways of doing this, using the javapackager tool, or the JavaFX Ant Tasks (which aren't actually specific to JavaFX, and are provided with the Java 8 JDK).

    Here's an example of packaging an application as a Jar, setting the main-class and classpath attributes, and copying all the dependencies into a folder, using Maven.

    <plugins>
            <plugin>
                <artifactId>maven-dependency-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/lib</outputDirectory>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.2.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <mainClass>${project.groupId}.${project.artifactId}.DemoCLI</mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
    </plugins>
    

    And here is the Ant build file to package the standalone application (exe for Windows, .app and .dmg on OS X, .deb and .rpm on Linux).

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE xml>
    
    <!--
     Uses the JavaFX Ant Tasks to build native application bundles
     (specific to the platform which it is built on).
    
     See https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_tasks.html
    
     These tasks are distributed with version 8 of the Oracle JDK,
     Amazon Corretto JDK, RedHat JDK, probably others, though they
     do not seem to be the OpenJDK on Debian Linux
    
     -->
    <project
        name="fxwebclient" default="default" basedir="."
        xmlns:fx="javafx:com.sun.javafx.tools.ant">
    
        <!-- In Java 8, java.home is typically the JRE of a JDK -->
        <property name="jdk.lib.dir" value="${java.home}/../lib" />
    
        <!-- Where to build our app bundles -->
        <property name="build.dist.dir" value="${basedir}/target/dist" />
    
       <echo>Using Java from ${java.home}</echo>
    
        <target name="default" depends="clean">
    
            <!-- get the ant-jfx.jar from the JDK -->
            <taskdef resource="com/sun/javafx/tools/ant/antlib.xml"
                uri="javafx:com.sun.javafx.tools.ant"
                classpath="${jdk.lib.dir}/ant-javafx.jar" />
    
            <!-- Define our application entry point -->
            <fx:application id="demo" name="demo"
                mainClass="yourpackage.DemoCLI" />
    
            <!-- Our jar and copied dependency jars (see pom.xml) -->
           <fx:resources id="appRes">
                <fx:fileset dir="${basedir}/target" includes="*.jar"/>
                <fx:fileset dir="${basedir}/target/lib" includes="*.jar" />
           </fx:resources>
    
            <!-- Create app bundles [platform specific] -->
            <fx:deploy nativeBundles="all"
                outdir="${build.dist.dir}" outfile="DemoWebClient">
    
                <fx:application refid="demo" />
                <fx:resources refid="appRes" />
    
            </fx:deploy>
    
        </target>
    
        <!-- clean up -->
        <target name="clean">
            <delete dir="${build.dist.dir}" includeEmptyDirs="true" />
            <delete file="${basedir}/target/${ant.project.name}.jar" />
        </target>
    
    </project>
    
    0 讨论(0)
  • 2021-02-14 19:57

    Double click to run executables on multiple platforms, requires prior registration of the file type with the operating system, or an existing file type to know how to handle the code.

    jlink statically links the "required modules and their transitive dependencies" to the output.

    There is no cross platform solution to this problem.

    It is improbable(or to put it another way, not feasible) to include all platforms in a single file, since each executable type(COFF, ELF...), has a different structure. You could attempt to use a generic batch file to start the proper executable, but on Windows, that would require a text file type encoding; thus poisoning the remaining binary code.

    Using jlink and the new jmod file format will allow you store native code in a Java container, and thus allowing the entry point into the embedded native JRE code in a single executable image for a single pre-defined platform.

    The other side of this issue is the security implications. Since the embedded JRE is not subject to security updates, crackers may choose to embed a previously known flawed JRE, thus exposing corrected exploits to unknowing consumers.

    The expected response from Anti-Virus programs would be to flag all non-updated embedded JRE's as viruses.

    0 讨论(0)
提交回复
热议问题