19 Die Werkzeuge des JDK

»Erfolg sollte stets nur die Folge, nie das Ziel des Handelns sein.«
– Gustave Flaubert (1821–1880)

Dieses Kapitel stellt die wichtigsten Programme des JDK vor. Da die meisten Programme kommandozeilenorientiert arbeiten, werden sie zusammen mit ihrer Aufrufsyntax vorgestellt. Bei den JDK-Programmen handelt es sich unter anderem um folgende Tools:

javac: Java-Compiler zum Übersetzen von .java in .class-Dateien
java: Java-Interpreter zum Ausführen der Java-Applikationen
appletviewer: Applet-Viewer zum Ausführen von Java-Applets, die in eine HTML-Datei eingebettet sind
javah: Generator für Header- und Quellcode-Rümpfe zum nativen Zugriff
javap: Anzeiger vom Bytecode einer Klassendatei
jdb: Debugger zum Durchlaufen eines Programms
javadoc: Dienstprogramm zum Erzeugen von Dokumentationen
jar: Archivierungswerkzeug, um Dateien in einem Archiv zusammenzufassen
jconsole: Java-Monitoring- und Management-Konsole
pack200, unpack200: Starke (De-)Kompression von Jar-Dateien
serialver: Generiert serialVersionUID.
keytool, jarsigner und policytool: Programme zum Einstellen der Sicherheitseigenschaften

Obwohl es versionsabhängig noch weitere Aufrufparameter gibt, sind nur diejenigen aufgeführt, die offiziell in der aktuellen Dokumentation genannt sind.

19.1 Java-Quellen übersetzen

19.1.1 Java-Compiler vom JDK

Der Compiler javac übersetzt den Quellcode einer Datei in Java-Bytecode. Jede in einer Datei deklarierte Klasse übersetzt der Compiler in eine eigene Klassendatei. Wenn bei einer Klasse (nennen wir sie A) eine Abhängigkeit zu einer anderen Klasse (nennen wir sie B) besteht – wenn zum Beispiel A von B erbt – und B nicht als Bytecode-Datei vorliegt, dann verarbeitet der Compiler B automatisch mit. Der Compiler überwacht also automatisch die Abhängigkeiten der Quelldateien. Der allgemeine Aufruf des Compilers ist:

$ javac [ Optionen ] Dateiname(n).java

**Tabelle 19.1:** Optionen des Compilers javac
Option	Bedeutung
-cp classpath	Eine Liste von Pfaden, auf denen der Compiler die Klassendateien finden kann. Diese Option überschreibt die unter Umständen gesetzte Umgebungsvariable CLASSPATH und ergänzt sie nicht. Ein Semikolon (Windows) beziehungsweise Doppelpunkt (Unix) trennt mehrere Verzeichnisse.
-d Verzeichnis	Gibt an, wo die übersetzten .class-Dateien gespeichert werden. Ohne Angabe legt der Compiler sie in das gleiche Verzeichnis wie das mit den Quelldateien.
-deprecation	Zeigt veraltete Methoden an.
-g	Erzeugt Debug-Informationen. Die Option muss gesetzt sein, damit der Debugger alle Informationen hat. –g:none erzeugt keine Debug-Informationen, was die Klassendatei etwas kleiner macht.
-nowarn	Deaktiviert die Ausgabe von Warnungen. Fehler (errors) werden noch angezeigt.
-source Version	Erzeugt Bytecode für eine bestimmte Java-Version.
-sourcepath Quellpfad	Ähnlich wie -classpath, nur sucht der Compiler im Quellpfad nach Quelldateien.
-verbose	Ausgabe von Meldungen über geladene Quell- und Klassendateien während der Übersetzung.

19.1.2 Native Compiler

Eine in Java geschriebene Applikation lässt sich erst einmal nur mit einer Java-Laufzeitumgebung ausführen. Einige Hersteller haben jedoch Compiler entwickelt, die direkt unter Windows oder einem anderen Betriebssystem ausführbare Programme erstellen. Die Compiler, die aus Java-Quelltext – oder Java-Bytecode – Maschinencode der jeweiligen Architektur erzeugen, nennen sich native oder Ahead-of-Time Compiler. Das Ergebnis ist eine direkt ausführbare Datei, die keine Java-Laufzeitumgebung nötig macht. Je nach Anwendungsfall kann das Programm performanter sein, eine Garantie dafür gibt es allerdings nicht. Die Startzeiten sind im Allgemeinen geringer, und das Programm ist viel schwieriger zu entschlüsseln, was das Reverse Engineering[225](Das Zurückverwandeln von unstrukturiertem Binärcode in Quellcode.) angeht.

Ein freier Compiler unter der GNU-Lizenz ist gcj (http://gcc.gnu.org/java/). Für den gcj integriert das Open-Source-Projekt JavaCompiler (http://jnc.mtsystems.ch/) diverse Zusätze, um natives Übersetzen zu vereinfachen.

Ein kommerzieller Vertreter ist Excelsior JET (http://www.excelsior-usa.com/jet.html). Dass viele Hersteller ihre Produkte eingestellt haben, ist sicherlich ein Zeichen dafür, dass die existierenden Laufzeitumgebungen mittlerweile eine ausreichende Geschwindigkeit, einen vertretbaren Speicherverbrauch und annehmbare Startzeiten zeigen.

19.1.3 Java-Programme in ein natives ausführbares Programm einpacken

Wer Java-Programme vertreibt, weiß um das Problem der JVM-Versionen, Pfade, Start-Icons, Splash-Screens und so weiter Bescheid. Eine Lösung besteht darin, einen Wrapper zu bemühen, der sich als ausführbares Programm wie eine Schale um das Java-Programm legt. Der Wrapper ruft die virtuelle Maschine auf und übergibt ihr die Klassen. Es ist also immer noch eine Laufzeitumgebung nötig, doch lassen sich den Java-Programmen Icons mitgeben und Startparameter setzen.

Die Open-Source-Software launch4j (http://launch4j.sourceforge.net/) kapselt ein Java-Archiv mit Klassen und Ressource-Dateien in ein komprimiertes, ausführbares Programm für Windows, Linux, Mac OS X und Solaris. launch4j setzt Eigenschaften wie ein assoziiertes Icon oder Startvariablen mit einer angenehmen grafischen Oberfläche. Ein weiteres quelloffenes und freies Programm ist JSmooth (http://jsmooth.sourceforge.net/). Für beide gibt es Ant-Skripte.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

Name
E-Mail
Ihr Kommentar