Titel | Inhalt | Suchen | Index | DOC | Handbuch der Java-Programmierung, 3. Auflage
<< | < | > | >> | API | Kapitel 50 - Hilfsprogramme des JDK

## 50.4 jdb - Der Debugger

- 50.4 jdb - Der Debugger
  - 50.4.1 Aufruf
  - 50.4.2 Beschreibung
  - 50.4.3 Vorbereitungen

### 50.4.1 Aufruf

    jdb [ classfile ]

### 50.4.2 Beschreibung

`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.

|  |  |  | Seit der Version 1.3 besitzt das JDK eine neue Debugging-Architektur. Sie wird als JPDA (Java Platform Debugger Architecture) bezeichnet und erlaubt es, Debugger komplett in Java zu schreiben. Zwar wird nach wie vor kein ausgefeilter GUI-Debugger mit dem JDK ausgeliefert. Doch befindet sich im Unterverzeichnis jpda des Demo-Verzeichnisses des JDK ein Beispielprogramm `javadt`, daß als Prototyp eines GUI-Debuggers angesehen werden kann. Hinweise zu seiner Verwendung finden sich in der JDK-Dokumentation. Auch integrierte Entwicklungsumgebungen verwenden diese Schnittstelle, um ihre eigenen Debugger einzubinden. |  |
JDK1.1-1.4

### 50.4.3 Vorbereitungen

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: |  |
Hinweis

    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« anzuklicken.

|  |  |  | 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. |  |
Warnung

Nachdem der Debugger gestartet wurde, meldet er sich mit seiner Kommandozeile und ist bereit, Befehle entgegenzunehmen. Die wichtigsten von ihnen werden in Tabelle 50.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.
`print` | 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 50.4: Kommandos von jdb

Titel | Inhalt | Suchen | Index | DOC | Handbuch der Java-Programmierung, 3. Auflage, Addison Wesley, Version 3.0
<< | < | > | >> | API | © 1998-2002 Guido Krüger, http://www.javabuch.de