Java-Programme starten - Möglichkeiten: Unterschied zwischen den Versionen
K (→Programme, die aus dem Quellcode Maschinencode erstellen (sog. ahead-of-time compiler)) |
K |
||
Zeile 184: | Zeile 184: | ||
[[Kategorie:Java]] | [[Kategorie:Java]] | ||
+ | [[Kategorie:Java Verschiedenes]] |
Version vom 25. August 2013, 22:21 Uhr
Inhaltsverzeichnis
Ein JAVA-Archiv, so genannte "JAR-Dateien"
Alle derzeit erhältlichen großen IDEs wie bspw. Eclipse, NetBeans, JDeveloper etc. bereits mit einer Funktion zum komfortablen Erzeugen einer Jar-Datei aus Quellcode ausgestattet. Auch einige Java-Editoren bieten diese Funktion an. Darunter bspw. der Java Editor und der JCreator.
Natürlich kann man auch Jar-Dateien manuell in einer Befehlszeile erzeugen oder dafür ein Skript einspannen.
Um eine ausführbare Jar-Datei erzeugen zu können, muss in dem .jar-Archive eine Manifest-Datei enthalten sein (unter META-INF/MANIFEST.MF), aus der hervorgeht, welche Klasse die main()-Methode enthält. Sie kann z.B. so aussehen:
Manifest-Version: 1.0 Main-Class: MyProgr [LEERZEILE]
Das .jar-Archive kann z.B. mit folgendem Kommando erstellt werden: jar cfm MyProgr.jar MyProgr.mf *.class *.jpg *.au.
PRO
Diese Dateien sind in jedem Falle unter jedem Betreibssystem ausführbar, für das eine JRE verfügbar ist.
Die so erstellten JAVA-Programme sind plattformunabhängig!
CONTRA Man sollte beachten, dass man als unerfahrender Benutzer die JAR-Dateien nicht mit Programmen wie WinRar verknüpft, denn sonst kann man die Programme (JAR-Dateien) nicht mehr beim Anklicken starten! Sollte man die JAR-Datei trotzdem ausversehen mit einem Packer verknüpft haben, dann kann man JAR-Dateien (bei Windows) nur noch mittels BAT-Datei oder über START->Ausführen und dann mit "javaw -jar meine_jar_datei.jar" starten. Wem das zu umständlich ist, der muss einen Schlüssel in der Registry setzen! Für erfahrene Leute, die wissen wie man mit der Registry unter Windows umgeht:
Man muss einen Schlüssel mit einem Binärwert unter
"HKEY_CLASSET_ROOT" -> "Applications" -> "javaw.exe" -> "shell" -> "open" -> "command"
eintragen mit dem Wert (Anführungszeichen mit eintragen!!!):
"C:\Programme\Java\jre1.5.0_01\bin\javaw.exe" -jar "%1" %*
(Der Pfad der JRE ist natürlich bei jedem variabel, dies ist nur der Standardpfad!)
Man kann natürlich auch einfach in den Einstellungen von WinRAR unter "Integration" den Haken bei .jar Dateien entfernen, oder die .jar-Datei per rechte Maustaste -> öffnen mit -> Java öffnen.
Eine Batch-Datei (kurz .bat)
Dabei erstellt man mit dem Compiler nur die Class-Dateien. Beim Klicken auf die BAT-Datei startet dann dementsprechend das eigene Programm. Wichtig: Damit das funktioniert, muss dem System der Pfad zum JRE bekannt sein und die Bat-Datei muss im Verzeichnis der Class-Dateien liegen.
PRO Hier ist eigentlich kein großeres PRO zu bennenen, außer dass man sein Programm jetzt mittels BAT-Datei (Stapelverarbeitungsdatei) startet. Das geht auf der Console durch Aufruf der Batchdatei oder auch per Doppelklick auf die Datei.
CONTRA Batch-Dateien lassen sich nur von Windows aus ausführen! Außerdem kommt das mit den Bat-Dateien langsam aus der Mode, unter anderem, weil Jar-Dateien wesentlich flexibler sind. Wenn man mal ein aktuelleres JRE installiert, funktioniert unsere Bat-Datei erst nach anpassen des Pfades zum JRE wieder.
Für Linux:
#!/bin/sh java mein_javaprogramm
chmod +x <Dateiname der ShellDatei>
PRO Wenn man die Datei mit vollem Pfad angibt und in das /usr/local/bin Verzeichnis kopiert, kann man die Datei einfach nur mit dem Dateinamen(meinProgramm) aufrufen, aber sonst gibt es da auch kein großartiges Pro.
CONTRA Das geht dann halt nur unter Linux. Aber wenn man dazu noch eine Batchdatei legt, hat man schon zwei Plattformen abgedeckt.
Für Windows sieht das folgendermaßen aus:
rem * Pfad zur JRE einstellen (Bitte anpassen!) set path=.;C:\Programme\Java\jre1.6.0\bin
Danach folgende Zeilen, je nach Situation hinzufügen, die Datei speichern und ausführen
rem * Starten einer Java-Klasse Bsp. MeinProgramm.class java MeinProgramm
oder
rem * Starten eines Programms aus einem Jar-Archiv mit Konsolenausgabe java -jar MeinProgramm.jar pause
oder
rem * Starten eines Programms aus einem Jar-Archiv ohne Konsolenausgabe javaw -jar MeinProgramm.jar
Programme die aus dem Bytecode Maschienencode erstellen
Dieser Maschienencode ist dann in so "EXE-Dateien" oder "DLL-Dateien" abgespeichert. Programme, die das können nennt man Native Code Compiler. Ein solches Programm ist z.B. Excelsior JET (kostenpflichtig)
PRO Wie gesagt es handelt sich nach der Compilierung um eine echte EXE-Datei. Es kompiliert neben deinem eigenen Programm auch noch die gesamte JRE und erzeugt daraus eine binäre Datei.
CONTRA Aus meiner Erfahrung her, kann ich nur sagen : "Leute lasst die Finger von sowas!". Hier die Begründung: Die Installation von Programmen wie Excelsior JET dauert bei einem 2GHz PC um die 2 Stunden, weil zunächst das JRE kompiliert wird. Die Bedienung ist meist leicht. Die Programme sind nur dann auf anderen Computern ausführbar, wenn alle Runtimes von dem entsprechenden Native-Compiler auf dem anderen PC sind (so um die 25 MB), zu den 25 MB kommt dann nochmal die gesamte JRE dazu (die als Bundle mitgeliefert wird). Das sind dann nochmal je nach JAVA-Version so um die 70 MB. Dann hat man vielleicht ein selbst geschriebenes Programm mit 200KB und 95MB Runtimes! Das lohnt sich wirklich nicht! Die Plattformunabhängigkeit geht dadurch auch verloren. Oftmals unterstützen Native Code Compiler auch nicht aktuellen JDKs.
Programme, die aus dem Quellcode Maschinencode erstellen (sog. ahead-of-time compiler)
Es gibt auch noch eine etwas einfachere Möglichkeit: Am ehesten findet man da den GCJ, den Java Compiler aus der GNU Compiler Collection. Mit diesem ist es relativ problemlos möglich Java-Quellcode zu Maschinencode zu kompilieren:
gcj --main=Foo -o Foo Foo.java
Mit --main
wird die Klasse mit der main Methode spezifiziert, -o
gibt den gewünschten Namen der kompilierten Datei an. Ob das unter Windows so ohne Weiteres funktioniert, weiß ich leider nicht, ich benutze Linux.
PRO Es wird eine JRE-unabhängige, ausführbare (unter Windows .exe) Datei erzeugt.
CONTRA Die Datei ist nicht mehr plattformunabhängig und GJC unterstützt nach eigenen Angaben einige Teile der Java Bibliotheken noch nicht.
Programme, die den JAVA-Quellcode in C++-Quellcode umwandeln
Mit einem C++ Compiler kann man dann den C++-Quelltext zu einer EXE-Datei (Maschienencode) compilieren. Diese Variante ist also eine Art Übersetzer von Java zu C++.
Ein Programm, was das kann, heißt: Ja2dol (Freeware, OpenSource-Projekt) bzw. das Nachfolge-Projekt Java2CPP
PRO Man erhält eine lauffähige EXE-Datei, und man braucht so gut wie keine Runtime-Bibliotheken. Desweiteren erhält man den in C++-Quellcode umgeformten Code des Java-Programms.
CONTRA Wie das so mit Übersetzungstools ist, stimmt die Grammatik hinterher nicht unbedingt 100%ig. Das wird vor allem bei größeren Programmen sichtbar und es kommt zu Fehlern. Man sollte also auch ein wenig C++-Kentnisse haben, um die Übersetzungsfehler korrigieren zu können. Die Übersetzung von "Ja2doll" ist aber schon recht akzeptabel. Die Plattformunabhängigkeit geht bei EXE-Dateien verloren. FAZIT Auf Grund der höhen Fehlerdichte nicht zu empfehlen für die produktive Umgebung.
Programme, die EXE-Dateien zum Starten von JAVA-Anwendungen erstellen
Dabei wird der Bytecode von einer EXE-Datei gestartet. Man hat dann neben der Jar-Datei, die die Klassen des Programms enthält, eine EXE-Datei, die das Java-Programm letztendlich startet. Man braucht also auf jeden Fall trotzdem eine JVM, um die benötigten Klassen für das Java-Programm bereitzustellen. Vertreter sind zum Beispiel JEStart von Xenoage oder Launch4J.
PRO Per Klick auf die EXE-Datei startet das Programm, wobei das Programm (EXE-Datei) sehr klein bleibt. Meist kann man ein Icon für die Exe-Datei festlegen. Plattformunabhängigkeit bleibt erhalten. Auf einem Linux-System kann immer noch die Jar-Datei ausgeführt werden.
CONTRA Man braucht, wie oben beschrieben, eine JVM (sollte aber in der heutigen Zeit schon auf fast jedem PC drauf sein). Die Exe-Datei startet u.U. nur auf einem Windows-System. Linux-Benutzer brauchen dann wieder eine ausführbare Jar-Datei oder eine Shell-Datei zum Start.
Anmerkungen zum Thema Maschinencode
Zunächst einmal ist es sehr einfach ausgedrückt, zu behaupten, "EXE-Dateien" sowie "DLL-Dateien" seien allgemein "Maschinencode". Das ist zwar für sich betrachtet nicht falsch, jedoch gibt es weitere Fälle bei denen der Begriff "Maschinencode" Anwendung findet, und somit nicht hierauf beschränkt genannt werden sollte.
(Mir) Bekannte Native-Compiler sind der bereits genannte Excelsior JET für Windows- und Linux-Systeme sowie der GNU Compiler for Java (GCJ) der GNU Compiler Collection. Ersterer ist in der Tat kostenpflichtig und bereits in Demo-Version vollstens einsetzbar. Zweiterer ist wie vom GNU-Projekt bekannt vollständig frei und kostenlos verfügbar und auf verschiedene Systeme portiert.
Allgemeine Vor- und Nachteile eines Native-Code-Programms: + Da Maschinencode, schnelle(re) Ausführung des Programms + keine "Mogelpackung" (s.u.) - Verlust der Plattformunabhänigkeit
(Anm. zu 2. '+': Einigen Programmieren (auch Nutzer) behagt der Gedanke nicht, ein Programm auszuliefern, dass im eigentlichen Sinne keines ist [sondern eben Bytecode, also gewissermaßen ein eigenes computerähnliches System braucht, um ausgeführt zu werden].) Excelsior JET In der Tat ist es so, dass dem von Excelsior JET kompilierten Programm/Programmbibliothek, sollte es auf einen anderen Rechner portiert werden, (ausschließlich!) die Laufzeit-Bibliotheken (die das Programm benötigt) beigefügt werden müssen (oder es ist eine JET Installation auf dem Rechner vorhanden), um es letztendlich ausführen zu können. Tatsächlich beginnt deren Größe mit 50 MiB und steigt abhängig von den benutzten Klassen, wobei anzumerken ist, dass meine Programm-Laufzeit-Bibliotheken niemals 60 MiB überschritten haben. Es ist durchaus ein gewaltiger psychologischer Anstieg von einem 50-200 KiB großem Programm zu etwa 60 MiB Laufzeit, allerdings ist dem im Zeitalter von DSL und Terabyte-Festplatten keine allzu große Bedeutung zuzusprechen. Darüber hinaus sind die angesetzten 2 Stunden der Installation bei Weitem zu hoch. 5 Minuten maximal sind erforderlich.
Wie schon genannt ist die Benutzerführung, wenn auch vom üblichen Windows-Bild abweichend, und Funktion ansprechend bzw. umfassend, was das Programm selbst gut verwendbar machen lässt, zudem kann sich das Ergebnis mehr als sehen lassen.
Programmeinschränkungen gegenüber der Vollversion: Die einzigen Beschränkungen, die der "JET" hat, sind die ausgewählte Verwendbarkeitsdauer (30 Tage ohne Registrierung / 90 Tage mit) und ein kleines Hinweisfenster nach Beenden des kompilierten Programms. Andernfalls sind die Programme jederzeit einsetzbar.
GNU Compiler for Java (GCJ) Zu diesem kann ich eigentlich nicht sonderlich viel sagen, da er (MinGW Windows Portierung) meine (syntaktisch korrekten) Programme bislang nicht kompilieren konnte, und ich ihn aufgrund dessen meide.
Fazit Der "JET" ist in jedem Fall einen Blick wert. Wer sich des GCJ annehmen möchte, der möge das tun, sollte aber keine allzu große Benutzerfreundlichkeit erwarten.
Ein ähnliches Konzept verfolgt das Tool Bat To Exe Converter. Allerdings wird hier eine Batchdatei in eine Exe-Datei verwandelt. Das heißt, man schreibt die Startbefehle für das Java-Programm in eine Batchdatei, aus welcher dann von Bat To Exe Converter eine Exe-Datei inkl. benutzerdefiniertem Icon erzeugt wird.
Java-Programm von CD oder USB-Stick starten
Man kann Java-Programme auf einem Zielrechner ohne JRE direkt von einer CD starten, die nach dem Einlegen ins CD-Laufwerk automatisch auf einem Windows-System mit der Ausführung beginnen. Das Interessante daran: Der Zielrechner braucht nicht mal eine JRE installiert zu haben, denn diese liegt gleich mit auf der CD.
Hinweis: Ab Java 6 wird Windows 98 und Windows ME nicht mehr unterstützt, es müsste in diesem Fall also eine ältere JRE benutzt werden.
PRO Die Anwenung ist relativ unabhängig von jeglichen Betriebssystemen, so lange eine passende JRE auf der CD mitgeliefert wird.
CONTRA
Die Anwendung benötigt zum Laden und während der Ausführung auf Grund des lansamen Laufwerks etwas mehr Zeit.
Autoren: