Java-Code mit JPDA debuggen: Protokolle vereinfachen den Prozess

JPDA besteht aus drei Interfaces, die von Debuggern in Entwicklungsumgebungen für Desktopsysteme verwendet werden können. Das Java Virtual Machine Tools Interface (JVMTI) definiert die Services, die eine VM zwecks Debugging bereitstellen muss. (JVMTI in Java 5.0 ist ein Ersatz für das Java Virtual Machine Debug Interface, das nicht mehr verwendet werden sollte.) Das Java Debug Wire Protocol (JDWP) definiert das Format für Informationen und Requests, die zwischen dem zu prüfenden Prozess und dem Debugger-Frontend, welches das Java Debug Interface (JDI) implementiert, übertragen werden. Das JDI definiert Informationen und Requests auf Ebene des Benutzercodes.

Das JPDA-Konzept teilt den Debuggingprozess in zwei Teile auf: Das Programm, das geprüft wird („Debuggee“), und das JDI, das normalerweise die Benutzeroberfläche einer Debuggeranwendung ist (oder Teil einer Java-IDE). Eine Debuggee-Anwendung läuft im Backend-Teil, das JDI im Frontend-Teil. Zwischen dem Backend und einem Frontend gibt es einen Kommunikationskanal, der auf dem JDWP-Protokoll aufsetzt. Daher können Debuggee und Debugger auf demselben Rechner, aber auch auf verschiedenen Rechnern ausgeführt werden.

Aus Entwicklersicht kann sich eine Debugger-Anwendung auf jeder Ebene in eine JPDA einklinken. Da das JDI die oberste Ebene ist und am einfachsten zu benutzen, empfiehlt sich in der Regel die Verwendung dieses Interfaces. Angenommen, ein Unternehmen entwickelt einen Debugger mit JDI. Das Unternehmen kann diesen dann mit der Referenzimplementierung verwenden, und er wird automatisch mit allen VMs und Plattformen funktionieren, die Sun unterstützt. Daher beschreiten die meisten IDE-Anbieter diesen Weg. Es kann zum Beispiel auch mit dem Frontend der Referenzimplementierung und einem Debuggee verwendet werden, der auf der VM eines anderen Unternehmens läuft und das JDWP implementiert. Diese kann wiederum das JVMTI verwenden, muss aber nicht.

Einige Debugger bauen auf niedrigeren Ebenen auf, zum Beispiel auf dem JDWP (falls das Frontend nicht in Java geschrieben ist) oder dem JVMTI (für spezielle Debugger, die auf Low-Level-Funktionen zurückgreifen müssen).

Das Backend des Debuggers ist verantwortlich für die Übermittlung von Anfragen wie „Nenn mir den Wert der Variablen X“ vom Debugger-Frontend an die VM des Debuggees und für die Übermittlung der Antworten auf solche Anfragen (einschließlich erwünschter Effekte wie das Erreichen eines Breakpoints) an das Frontend. Das Backend kommuniziert mit dem Frontend über einen Kommunikationskanal per JDWP. Das Backend kommuniziert mit der VM des Debuggees per JVMTI.

Der Kommunikationskanal ist die Verbindung zwischen den Front- und Backends des Debuggers. Man kann sich das bestehend aus zwei Mechanismen vorstellen: einem Connector sowie dem Transport. Connector heißt ein JDI-Objekt, mit dessen Hilfe eine Verbindung zwischen den Front- und Backends hergestellt wird. Es gibt drei Arten von Konnektoren:

• listening: Das Frontend wartet auf eine eingehende Verbindung vom Backend.
• attaching: Das Frontend verbindet sich mit einem bereits laufenden Backend.
• launching: Das Frontend startet selbst den Java-Prozess, der den Debuggee-Code und das Backend ausführt.

Ein Transport ist der zugrunde liegende Mechanismus zum Übertragen von Bits zwischen Frontend und Backend. Der zu verwendende Transportmechanismus ist nicht in der JPDA-Spezifikation festgelegt. Mögliche Mechanismen sind Sockets, serielle Leitungen oder gemeinsam genutzter Speicher (Shared Memory). Allerdings werden Format und Semantik des serialisierten Bitstroms, der über diesen Kanal fließt, vom JDWP festgelegt. Die meisten IDEs und Debugger unterstützen, so wie die Referenzimplementierung von Sun, zwei Arten von Transport: Shared Memory (falls Debuggee und Debugger auf demselben Rechner ausgeführt werden) und Socket (wobei Debuggee und Debugger sich auf beliebigen Rechnern befinden können, auch auf demselben).

Seit J2SE 5.0 umfasst JPDA auch Service Provider Interfaces für Entwicklung und Deployment von Connector- und Transport-Implementierungen. Diese Service Provider Interfaces erlauben den Anbietern von Debuggern und anderen Tools die Entwicklung neuer Connector-Implementierungen und die Bereitstellung zusätzlicher Transport-Mechanismen neben Socket und Shared Memory, wie sie von Sun bereitgestellt werden.

Die Kommunikation zwischen Debuggee und Debugger ist verbindungsorientiert. Daher muss eine Seite als Server dienen, der auf eine Verbindung wartet. Die andere Seite fungiert als Client und stellt die Verbindung zum Server her. JPDA erlaubt sowohl der Debugger-Anwendung als auch der VM auf dem Zielrechner, als Server zu fungieren.