|
In diesem Kapitel wollen wir die wichtigsten Werkzeuge des Java Development Kit vorstellen. Alle Programme arbeiten kommandozeilenorientiert und werden aus einer DOS-Box oder einer Shell heraus aufgerufen. Wir stellen die Aufrufsyntax und die wichtigsten Optionen der folgenden Programme vor:
Das JDK stellt darüber hinaus weitere Werkzeuge zur Verfügung, auf die wir hier nicht näher eingehen wollen. Dazu zählen beispielsweise javah, rmix oder keytool. Sie sind Bestandteil spezieller APIs und werden in der JDK-Dokumentation ausführlich beschrieben.
javac [ options ] [@filelist | { filename.java }]
|
Der Compiler javac übersetzt Sourcecode in Bytecode. Zu jeder Klasse, die innerhalb einer .java-Datei definiert wurde, wird eine eigene .class-Datei erzeugt. Der Compiler wacht automatisch über die Abhängigkeiten zwischen den Quelldateien. Wird beispielsweise in einer Klasse X in der Datei X.java eine Klasse Y, die in Y.java liegt, verwendet, so wird Y.java automatisch mit übersetzt, wenn es erforderlich ist. Anstelle der Liste von Dateinamen kann nach einem @ auch eine Textdatei angegeben werden, in der die zu übersetzenden Dateien durch Whitespaces getrennt angegeben werden.
| Option | Bedeutung |
| -classpath path | Gibt die Liste der Pfade zur Suche von Klassendateien an. Dieser Schalter übersteuert den Wert einer eventuell gesetzten Umgebungsvariable CLASSPATH. Bezüglich der Auswirkungen des Klassenpfades in den unterschiedlichen JDK-Versionen lesen Sie bitte Abschnitt 8.2.2. |
| -g | Aktiviert die Erzeugung von Debug-Informationen. Dieser Schalter sollte aktiviert werden, bevor ein Programm debugt wird. |
| -nowarn | Deaktiviert die Ausgabe von Warnungen. |
| -O | Schaltet den Code-Optimierer an. Dessen Fähigkeiten sind auch in aktuellen Versionen des JDK 1.2 noch nicht sehr ausgeprägt und beschränken sich vorwiegend auf das Expandieren von Methodenaufrufen. |
| -verbose | Aktiviert die Ausgabe von Meldungen über geladene Quell- und Klassendateien während der Übersetzung. |
| -depend | Normalerweise wird eine Quelldatei neu kompiliert, wenn das Datum der letzten Änderung nach dem Änderungsdatum der Klassendatei liegt oder wenn die Klassendatei ganz fehlt. Mit Hilfe dieses Schalters wird diese Entscheidung auf der Basis von Headerinformationen in der Klassendatei auf eine zuverlässigere Weise getroffen. Der Übersetzungsvorgang wird aber unter Umständen sehr viel langsamer. |
| -deprecation | Sorgt dafür, daß bei jedem Aufruf einer als deprecated markierten Methode (@deprecated-Marke im Dokumentationskommentar) zusätzliche Informationen über mögliche Workarounds ausgegegeben werden. Alle Methoden aus älteren JDKs, die im aktuellen JDK nicht mehr verwendet werden sollen, werden mit diesem Flag markiert. |
Tabelle 26.1: Optionen von javac
java [ options ] classname [{ args }]
javaw [ options ] classname [{ args }]
|
Der Interpreter java dient dazu, kompilierte Java-Programme auszuführen, die als Bytecode in .class-Dateien vorliegen. javaw erfüllt denselben Zweck, erzeugt aber kein Terminalfenster beim Start des Programms und erlaubt nicht die Verwendung der Standard-Streams System.in, System.out und System.err. Beim Aufruf beider Programme wird der Name einer Klassendatei erwartet (ohne die Erweiterung .class). Damit sie ausgeführt werden kann, muß sie eine Klassenmethode main mit folgender Signatur enthalten:
public static void main(String args[]) |
Alle Argumente, die nach dem Namen der Klassendatei an java übergeben werden, stehen nach dem Aufruf von main in args zur Verfügung. Der Java-Interpreter wird nach dem Rücksprung aus main beendet, wenn keine eigenen Threads erzeugt wurden. Falls weitere Threads erzeugt wurden, wird er beendet, nachdem der letzte Vordergrund-Thread beendet wurde.
Da während der Ausführung eines Java-Programms meist weitere Klassendateien benötigt werden, muß der Interpreter wissen, wo diese zu finden sind. Standardmäßig sucht er dabei im systemspezifischen Installationsverzeichnis und im aktuellen Verzeichnis. Die Suchstrategie kann durch Setzen der Umgebungsvariable CLASSPATH oder mit Hilfe der Option -classpath verändert werden. Sollen nur die Standardbibliotheken des JDK verwendet werden, sind weder CLASSPATH noch -classpath erforderlich. Weitere Informationen zu CLASSPATH-Einstellungen finden Sie in Abschnitt 8.2.2.
|
In der Windows-Version des JDK 1.2 ist ein Just-In-Time-Compiler (kurz JIT) enthalten, der standardmäßig aktiviert ist. Der JIT übersetzt zur Laufzeit des Programmes häufig benötigte Bytecodes in Maschinencode und beschleunigt so die weitere Ausführung des Programms. Soll der JIT deaktiviert werden, kann die Umgebungsvariable JAVA_COMPILER oder die Systemeigenschaft java.compiler auf den Wert NONE gesetzt werden. |
 |
|
|
| Option | Bedeutung |
| -classpath path | Gibt die Liste der Pfade zur Suche von Klassendateien an. Alternativ kann auch der Schalter -cp verwendet werden. |
| -prof | Aktiviert in Prä-1.2-Versionen des JDK den Profiler im Interpreter, der Informationen über das Laufzeitverhalten der Anwendung in die Datei java.prof schreibt. Ab dem JDK 1.2 wird der Profiler mit der Option -Xprof aktiviert. Genaue Informationen zur Verwendung des Profilers sind in Abschnitt 29.3 zu finden. |
| -version | Ausgabe der Versionsnummer. |
| -help | Ausgabe eines kurzen Hilfetextes. |
| -verbose | Gibt bei jedem Laden einer Klasse eine Meldung auf der Console aus. |
| -verbosegc | Veranlaßt den Garbage Collector bei jedem Aufruf zur Ausgabe einer Nachricht. |
| -DpropName=value | Weist dem Property propName den Wert value zu. |
| -Xms n | Spezifiziert die Größe des beim Start allozierten Speichers. n ist dabei eine Ganzzahl mit einer der Erweiterungen »k« oder »m«. Die Buchstaben stehen für die Größenordnungen kilo und mega. Die Standardeinstellung ist 1m. |
| -Xmx n | Spezifiziert die Größe des maximal allozierbaren Speichers. n ist dabei eine Ganzzahl mit einer der Erweiterungen »k« oder »m«. Die Standardeinstellung ist 16m. |
Tabelle 26.2: Optionen des Java-Interpreters
|
In den 1.1er-Versionen des JDK gab es ein Programm jre, das dazu diente, den Interpreter des Laufzeitsystems zu starten (Java Runtime Environment). Dieses Programm ist in der aktuellen JDK-Version nicht mehr vorhanden, sondern wird durch das Programm java ersetzt. Auch der in früheren Versionen vorhandene debugging-fähige Interpreter java_g existiert seit dem JDK 1.2 nicht mehr. |
|
|
|
appletviewer [ options ] { url }
|
appletviewer ist ein Hilfsprogramm zum Ausführen von Applets. Er interpretiert dazu die als Argument übergebenen (und auf HTML-Dokumente zeigenden) URLs und öffnet für jedes darin gefundene APPLET-Tag ein Fenster, in dem das zugehörige Applet gestartet wird. Alle übrigen HTML-Befehle werden ignoriert. Details zur Struktur der HTML-Dateien und zur Ausführung von Applets finden sich in Kapitel 25.
| Option | Bedeutung |
| -debug | Startet den Appletviewer unter Kontrolle des Debuggers und erlaubt so die Fehlersuche in Applets. |
Tabelle 26.3: Optionen von appletviewer
jdb [ classfile ] |
jdb ist der Debugger des JDK. Er bietet die Möglichkeit, Programme kontrolliert ablaufen zu lassen und dabei Breakpoints zu setzen, im Einzelschrittmodus den nächsten Befehl ausführen zu lassen oder den Inhalt von Variablen oder Objekten zu inspizieren. Man sollte allerdings nicht zu große Erwartungen an jdb stellen, denn das Programm ist ein Kommandozeilendebugger in schönster UNIX-Tradition. Mit den grafischen Debuggern der integrierten Java-Entwicklungsumgebungen hat er nur wenig gemeinsam. Leider ist er nicht nur umständlicher zu bedienen, sondern läßt (insbesondere in Prä-1.2-JDKs) auch einige wichtige Features moderner Debugger vermissen.
Damit ein Programm debugt werden kann, sollte es mit der Option -g
übersetzt werden. Dadurch werden symbolische Informationen in
die Klassendatei geschrieben, die der Debugger zur Interpretation
von lokalen Variablen benötigt. Beim Aufruf des Debuggers kann
die zu untersuchende Klassendatei als Argument angegeben werden:
jdb classfile
|
Damit jdb überhaupt startet, muß ein laufender TCP/IP-Stack vorhanden sein. Dies ist für Anwender unangenehm, die nur eine Wählverbindung zu ihrem Provider haben, denn bei jedem Starten des Debuggers die Verbindung aufzubauen ist nicht nur umständlich, sondern auch kostspielig. Die übliche Empfehlung im Usenet lautet in diesem Fall, eine Datei hosts anzulegen und den folgenden Eintrag einzufügen: |
|
|
|
127.0.0.1 localhost
Unter Windows 95 muß die Datei im Windows-Installationsverzeichnis (typischerweise c:\windows) angelegt werden, meist gibt es dort schon eine Kopiervorlage hosts.sam, die verwendet werden kann. In aktuellen JDKs kann auf das Anlegen der Datei unter Umständen verzichtet werden. Falls der Debugger nicht starten will, kann es sinnvoll sein, zusätzlich die DNS-Konfiguration zu deaktivieren. Dazu ist in der Systemsteuerung im Bereich »Netzwerk« das TCP/IP-Protokoll auszuwählen und nach Klick auf »Eigenschaften« im Registerblatt »DNS-Konfiguration« der Button »DNS deaktivieren« auszuwählen.
|
Bei dieser Anpassung ist allerdings Vorsicht geboten, denn Veränderungen an den Netzwerkeinstellungen können die Netzwerkanbindung des Rechners unbrauchbar machen. Es empfiehlt sich in jedem Fall, vor der Veränderung der Parameter die alte Konfiguration zu notieren, um sie nötigenfalls wieder restaurieren zu können. Veränderungen sollte sowieso nur derjenige vornehmen, der genau weiß, was er tut. |
|
|
|
Nachdem der Debugger gestartet wurde, meldet er sich mit seiner Kommandozeile und ist bereit, Befehle entgegenzunehmen. Die wichtigsten von ihnen werden in Tabelle 26.4 vorgestellt und kurz erläutert.
| Kommando | Bedeutung |
| ? | Liefert eine Übersicht aller Kommandos. Alternativ kann auch das Kommando help verwendet werden. |
| !! | Wiederholt das letzte Kommando. |
| load classname | Lädt eine Klassendatei in den Debugger. Falls jdb bereits mit einer Klassendatei als Argument aufgerufen wurde, muß dieses Kommando nicht mehr aufgerufen werden. |
| run | Startet das geladene Programm. Falls die Klassendatei mit load geladen wurde, müssen zusätzlich der Klassenname und ggfs. weitere Parameter des Programms übergeben werden. Nach Ausführung dieses Programms läuft das Programm bis zum nächsten Breakpoint oder bis es mit dem suspend-Kommando angehalten wird. |
| quit | Beendet den Debugger. Alternativ kann auch das Kommando exit verwendet werden. |
| stop in | Setzt einen Breakpoint auf den Anfang einer
Methode. Das Kommando erwartet den Namen der Klasse, einen Punkt und
den Namen der Methode als Argument. Beispiel:
stop in JDBBeispiel.actionPerformed |
| stop at | Setzt einen Breakpoint auf eine vorgegebene
Zeile. Dazu müssen der Name der Klasse, ein Doppelpunkt und die
Zeilennummer innerhalb der Quelldatei angegeben werden. Beispiel:
stop at JDBBeispiel:48 |
| clear | Löscht einen Breakpoint. Als Argument müssen der Klassenname, gefolgt von einem Doppelpunkt und der Zeilennummer, in der sich der Breakpoint befindet, angegeben werden. Es gibt keine Möglichkeit, eine Liste der aktuellen Breakpoints anzeigen zu lassen. |
| list | Zeigt den aktuellen Ausschnitt des Quelltextes an, an dem das Programm angehalten wurde. Die als nächstes auszuführende Zeile wird durch einen Pfeil markiert. Alternativ kann auch der Name einer Methode oder eine Zeilennummer an das Kommando übergeben werden. |
| step | Nachdem ein Programm angehalten wurde, kann es mit diesem Kommando im Einzelschrittmodus fortgeführt werden. Befindet sich an der Aufrufstelle ein Methodenaufruf, springt das Kommando in die Methode hinein und bleibt bei der ersten ausführbaren Anweisung stehen. |
| next | Wie step, springt dabei aber nicht in einen Methodenaufruf hinein, sondern führt die Methode als Ganzes aus und bleibt beim nächsten Kommando nach dem Methodenaufruf stehen. Dieses Kommando steht erst ab dem JDK 1.2 zur Verfügung. |
| step up | Führt die aktuelle Methode bis zum Ende aus. |
| cont | Führt das Programm nach einem Breakpoint fort. Es läuft dann bis zum nächsten Breakpoint oder bis es mit dem suspend-Kommando angehalten wird. |
| Zeigt den Inhalt der Variablen an, die als Argument übergeben wurde. print verwendet dazu die Methode toString, die in allen Objektvariablen implementiert ist. Damit eine Variable angezeigt werden kann, muß sie an der Aufrufstelle sichtbar sein. Es gibt leider keine Möglichkeit, den Inhalt einer Variablen aus dem Debugger heraus zu verändern. | |
| dump | Zeigt den Inhalt der Objektvariable, die als Argument übergeben wurde, inklusive aller Membervariablen an. Damit eine Variable angezeigt werden kann, muß sie an der Aufrufstelle sichtbar sein. |
| locals | Gibt eine Liste aller lokalen Variablen und ihrer aktuellen Inhalte aus. |
| where | Zeigt einen Stacktrace an. |
Tabelle 26.4: Kommandos von jdb
|
| Go To Java 2, Addison Wesley, Version 1.0.2, © 1999 Guido Krüger, http://www.gkrueger.com |