2016-04-11 4 views
4

Ich schreibe eine Anwendung mit JavaFX und bin besorgt über die Größe der .EXE-Datei, die ich nativ bereitstellen werde. Die Anwendung, die ich habe, ist nicht so groß (alles zusammen weniger als 5M), aber die Java-Runtime macht das endgültige installierte Verzeichnis weit über 100M, das in eine dividiblefähige 44M-Datei komprimiert wird.Reduzierung der Größe meiner nativ bereitgestellten JavaFX-Anwendung

Ich habe Tests mit 64-Bit-Windows (Java SE 8u77) ausgeführt. Um die endgültige ausführbare Datei kleiner zu machen habe ich Teile der JRE entfernt, die nicht notwendig sind, wie hier beschrieben: http://www.oracle.com/technetwork/java/javase/jre-8-readme-2095710.html

Hier ist, was ich gefunden habe:

  • komplette JRE: 45.0 M
  • Stripped JRE: 44.0 M

Hat jemand irgendwelche Ideen, wie man das verteilbare .EXE noch kleiner machen kann? Alle Informationen, die ich gefunden habe, sind mindestens 2 oder 3 Jahre alt und vielleicht nicht mehr so ​​relevant. Ich habe das Gefühl, dass mehr aus der JRE kommen kann, aber es scheint, dass dies die Lizenzierung verletzen würde.

Hat jemand Erfahrung mit der Verwendung von Nicht-Oracle-Distributionen oder anderen Möglichkeiten, die JavaFX-App kleiner zu machen?

Antwort

-2

Eines der besten Werkzeuge dafür ist Proguard.

Führen Sie Ihr Programm durch, bevor eine ausführbare

+0

Was schlagen Sie vor? Proguard einfach gegen meine Anwendung zu laufen, ist sinnlos, weil es im Vergleich zur Java-Laufzeit so winzig ist. Hat jemand Erfahrung damit, die Java Runtime zu schrumpfen? Ist das sogar legal, was die Lizenz betrifft? –

+0

Das Entfernen der JRE ist derzeit ein Verstoß gegen die Lizenzvereinbarung. Mit Java 9 (Projektpuzzle) wird es aber möglich sein. –

+0

Java 9 ist ein Jahr weg. Gibt es heute etwas, was heute getan werden kann? –

3

erzeugen, wenn die javapackager verwenden, können Sie nicht festlegen JRE enthalten. Dadurch verwendet der native Launcher die lokal installierte JRE (die möglicherweise nicht die beste Lösung ist).

Wenn die JavaFX-Maven-Plugin, man muss nur ein bundlerArgument gesetzt:

<configuration> 
    <mainClass>com.zenjava.test.Main</mainClass> 
    <bundleArguments> 
     <runtime /> <!-- dont include JRE, use installed one --> 
    </bundleArguments> 
</configuration> 

Wenn die JavaFX-gradle-Plugin, nur die Laufzeit als NULL gesetzt:

jfx { 
    verbose = true 
    mainClass = 'your.application.appname' 
    appName = 'appname' 
    jfxMainAppJarName = 'appname.jar' 
    vendor = "My Company" 
    bundleArguments = [ 
     runtime: null 
    ] 
} 

Bei Verwendung des ant-Stil xml-Datei des javapacker selbst, stellen gerade diese:

<fx:bundleArgument name="runtime" value="" />

Haftungsausschluss: Ich bin der Maintainer des und der Schöpfer des javafx-gradle-plugin.

+0

Ich habe diese Option bemerkt, aber ich muss noch verstehen, wie es nicht viel mehr Probleme schafft, als es löst. Was passiert, wenn jemand versucht, ohne eine geeignete JVM zu installieren? Ich schätze, es wird nicht schön sein. Zu erklären, was vorher zu tun ist (z. B. diese Java-Version installieren), ist ein Albtraum der Dokumentation. Und ... es ist meine Erfahrung, dass, wenn man gewöhnlichen Menschen einfach "Java" sagt, sie ausflippen, weil "es ein solches Sicherheitsproblem ist". –

+0

@SanderSmith Ja, das ist sehr wahr. Einige verwenden [JWrapper] (http://www.jwrapper.com/) als (bezahlte) Lösung dazwischen. Vielleicht möchten Sie stattdessen [Launch4J] (http://launch4j.sourceforge.net/) ausprobieren. Allen gemeinsam ist nun, dass Sie die JRE in Ihr Bundle integrieren. Es ist möglich, bereits existierendes javapackager mit launch4j-bundler zu kombinieren (im Fall von maven, mit haven zwei Profilen: ein launch4j, zwei javafx-maven-plugins mit spezieller Konfiguration). – FibreFoX

+1

@SanderSmith Es gibt eine Frage, die Sie selbst lösen müssen: Sie sind abhängig von der vom Benutzer installierten JRE, oder möchten Sie diese Aufgabe von javaverängstigten Benutzern übernehmen, indem Sie innerhalb des Bundles eine eigene JRE bereitstellen das Sicherheitsrisiko von Bugfixes). Ich persönlich tendiere dazu, die zweite Option zu haben, da man sich nicht mit "anderem JRE-Verhalten" auseinandersetzen muss, es besser macht, das Verhalten zu reproduzieren. Zum Aktualisieren:;) Einige Benutzer haben ein besseres Gefühl, dass Software oft Updates erhält, andere nicht. – FibreFoX

Verwandte Themen