Debugging mit der Java TM Platform Debugger Architecture

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Debugging mit der Java TM Platform Debugger Architecture im Rahmen des Seminars Qualitätssicherung in der Software-Entwicklung Katja Walentowitz Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Prof. Dr. Herbert Kuchen Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen des Debugging Begriffe Ansätze Eigenentwicklung eines Debuggers Grundlagen der Spezifikation der Java TM Platform Debugger Architecture Definition und Zweck Architektur Spezifikation der nativen Interfaces Java TM Virtual Machine Tool Interface Java TM Debug Wire Protocol JDI Spezifikation Zweck Packagestruktur Aufbau der Verbindung Definition von Anfragen Behandlung von Ereignissen Vorstellung eines Beispieldebuggers Übersicht Behandlung des Output- und des Error-Stream der debuggten Anwendung Bearbeiten der EventQueue Setzen von Breakpoints Fazit 19 A Ergänzende Erläuterungen zu JDI 21 A.1 Die Type- und Value-Hierarchie A.2 Verfügbare Ereignisse B Dokumentation der Beispielanwendung 22 B.1 Architektur i

3 B.2 Ausgewählte Methoden der Beispielanwendung B.2.1 Vollständige Methode getvalue B.2.2 Die Methode findvalue(primitivevalue) B.2.3 Schrittweises Debugging Literaturverzeichnis 27 ii

4 Kapitel 1: Einleitung 1 Einleitung Qualitätssicherung ist ein besonders wichtiger Bestandteil der Softwareentwicklung, da mangelnde Softwarequalität hohe finanzielle Schäden hervorrufen und den Ruf einer Firma nachhaltig schädigen kann. 1 Um Softwarequalität zu gewährleisten, ist nach DIN ISO 9162 u. a. sicherzustellen, dass die Software richtige bzw. vereinbarte Ergebnisse liefert. Um dieses Ziel zu erreichen, sind umfangreiches Testen und Debuggen notwendig. Da diese Aufgaben bis zu 50% des Gesamtentwicklungsaufwands ausmachen [ST04, S. 2], ist es von großer Bedeutung, sie besonders effizient und effektiv zu erfüllen. Im Rahmen dieser Arbeit soll daher speziell das Debugging in das Zentrum der Betrachtung gestellt werden, für das in der einschlägigen Literatur verschiedene Vorgehensmodelle existieren. Einige davon greifen auf spezielle Debuggingtools zurück. Diese Arbeit stellt die Java TM Platform Debugger Architecture (JPDA), eine spezielle Interfacesammlung, vor, mit deren Hilfe Tools entwickelt werden können, die möglichst effizientes und effektives Debugging ermöglichen. Der Schwerpunkt liegt dabei auf dem Java TM Debug Interface (JDI), da dieses vollständig in Java TM implementiert ist und am häufigsten zur Entwicklung verwendet wird. Dazu werden in Kapitel 2 zunächst einige Grundbegriffe erläutert und verschiedene Ansätze des Debugging beschrieben. Schließlich wird dargelegt, warum es nicht nur für Anbieter kommerzieller Entwicklungsumgebungen sinnvoll ist, eigene Debugger zu entwickeln. Kapitel 3 stellt im Anschluss daran die Java TM Platform Debugger Architecture vor und beschreibt zwei der drei enthaltenen Interfaces genauer. In Kapitel 4 wird das Java TM Debug Interface detailliert erläutert. Dabei wird nicht nur die Spezifikation beschrieben, sondern darüber hinaus die Verwendung von JDI anhand eines Beispiels genauer erläutert. Den Abschluss der Arbeit bildet ein Fazit, in dem auch kurz auf die Grenzen von JDI eingegangen wird. 2 Grundlagen des Debugging 2.1 Begriffe Für eine geeignete Abgrenzung des Begriffs Debugging ist es zielführend, zunächst den bereits erwähnten Begriff der Softwarequalität zu definieren und den Fehler- 1 Beispiele hierfür sind in [TH01, S ] aufgeführt. 1

5 Kapitel 2: Grundlagen des Debugging begriff zu erläutern. Dies erleichtert eine sich daran anschließende Erläuterung des Zwecks und der Bedeutung von Debugging. Nach DIN ISO 9162 ist Softwarequalität die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Diese umfassen u. a. Funktionalität, d. h. die Software muss u. a. die richtigen Ergebnisse liefern, dem Zweck angemessene Funktionen implementieren und sicher sein, und Zuverlässigkeit, d. h. die Software darf selten versagen, muss fehlertolerant und bei Systemabstürzen wiederherstellbar sein. Des Weiteren muss die Software einfach benutzbar, effizient sowie änder- und übertragbar sein. [Ba98, S f.] Um die beiden erstgenannten Anforderungen zu erfüllen, sind Fehler in der Software zu beseitigen. Ein Fehler bezeichnet dabei das Nichterfüllen einer festgelegten Anforderung. Dieser Fehler entsteht in der Implementierungsphase, zeigt sich aber erst während des Testens. Dieses Auftreten eines Fehlers wird als Fehlerwirkung bezeichnet. Sie hat ihren Ursprung in einer fehlerhaften Anweisung im Programmcode, die als innerer Fehler bezeichnet wird. [ST04, S. 7] Mit diesen Begriffen bezeichnet Testen das gezielte Ausführen der Software zum Auffinden von Fehlerwirkungen. Tritt in einem Test eine Fehlerwirkung auf, so ist zunächst eine Vorgehensweise zu entwickeln, mit der die Fehlerwirkung resproduziert werden kann. Auf Basis dieser bekannten Fehlerwirkung und der Reproduktion ist das Programm zu debuggen, um den unbekannten, inneren Fehler zu lokalisieren und zu beheben. Einige Methoden, mit deren Hilfe dies geschehen kann, sollen im Folgenden näher beschrieben werden. 2.2 Ansätze Obwohl es viele verschiedene Methoden gibt, mit deren Hilfe ein Programm debuggt werden kann, wird unter Debugging häufig bereits eine bestimmte Methode verstanden: das Beobachten des Programmzustands. Auf Basis einer Vermutung darüber, wo sich der innere Fehler befindet, wird hierbei versucht, den tatsächlichen Programmzustand, d. h. die Werte von Variablen etc., an dieser Stelle zu beobachten. Die einfachste Art, dies zu tun, besteht im Einfügen von Ausgabebefehlen in den Code. Eine Entlastung des Programmierers kann durch automatische Überprüfung von Variablenwerten mittels assert-befehlen erreicht werden [Ze06, S.257], wobei 2

6 Kapitel 2: Grundlagen des Debugging automatisch ein vom Programmierer spezifizierter Sollwert einer Variablen mit dem tatsächlichen Wert während der Testausführung verglichen wird. Als wissenschaftliches Debugging wird die folgende Methode bezeichnet, die sich am Vorgehen von Forschern, bspw. in naturwissenschaftlichen Bereichen, orientiert. Dabei wird zu Beginn eine Anfangshypothese über den inneren Fehler aufgestellt, die durch weitere Tests zu konkretisieren ist. Diese Tests überprüfen Vorhersagen, die auf Basis der Hypothese gemacht wurden. Bestätigen die Tests die Hypothese, so kann diese durch die neu gewonnen Informationen verfeinert werden. Andernfalls ist eine neue Hypothese aufzustellen. Dieses Verfahren ist solange fortzuführen, bis die Hypothese nicht weiter verfeinert werden kann und die fehlerhafte Anweisung gefunden ist. Auch die Methode des Beobachtens verwendet implizit den wissenschaftlichen Ansatz, da dort mit Hilfe des Programmzustands versucht wird, die Vermutung über die Stelle, an der der Code fehlerhaft ist, immer stärker einzugrenzen. Allerdings wird dem wissenschaftlichen Ansatz nicht strikt gefolgt, da keine Iteration über mehrere Hypothesen stattfindet. [Ze06, S. 147] Um den Hypothesenraum bereits im Vorhinein einzugrenzen, kann eine Untersuchung des Kontrollflusses durchgeführt werden. Dabei wird untersucht, welche Codezeilen bei der Ausführung eines Tests, der eine Fehlerwirkung aufgedeckt hat, durchlaufen wurden. Nur diese kommen als Ursache für die Fehlerwirkung in Frage. [Ze06, S. 168 f.] Neben diesen Ansätzen, bei denen der Programmierer Hypothesen aufstellt und verwirft, gibt es Debuggingmethoden, bei denen diese Aufgaben automatisch erfüllt werden. Zwei dieser Methoden sollen im Folgenden vorgestellt werden. Das Delta Debugging geht davon aus, dass Fehler von bestimmten Einflussfaktoren hervorgerufen werden. Aus allen möglichen Faktoren werden automatisiert diejenigen bestimmt, die für den Fehler verantwortlich sind. Dies geschieht durch Bilden eines Testfalls, bei dem der Fehler auftritt, und eines Testfalls, bei dem dies nicht der Fall ist. Die Isolation der relevanten Einflussfaktoren geschieht durch Hinzufügen von Faktoren zum fehlerfreien Testfall und Entfernen von Faktoren vom fehlerhaften Testfall. [Ze06, S. 335 f.] Die zweite automatisierte Methode ist das Deklarative Debugging. Dabei wird aus den zur Berechnung eines fehlerhaften Ergebnisses durchgeführten Teilberechnungen eine Baumstruktur aufgebaut. Die Kinder eines jeden Knoten enthalten dabei die Berechnungen, die für das Ergebnis des betrachteten Knoten verknüpft wurden. Ein innerer Fehler liegt in solchen Knoten vor, deren Kinder sämtlich fehlerfrei sind, die aber dennoch ein falsches Ergebnis liefern. [CHK06, S. 3-8] Diese Vorgehensweise eignet sich am besten für Programme, die in funktionalen und logischen Program- 3

7 Kapitel 2: Grundlagen des Debugging miersprachen entwickelt wurden, [Ze06, S. 155] lässt sich mit geeigneten Tools aber auch auf objektorientierte Sprachen übertragen, wie in [CHK06, S. 3-8] gezeigt wird. 2.3 Eigenentwicklung eines Debuggers Für die im Vorigen beschriebenen Methoden ist Computerunterstützung sehr hilfreich. Die beiden zuletzt beschriebenen, automatischen Methoden können nicht ohne Softwareunterstützung durchgeführt werden. Aber auch die anderen Methoden sowie die sich an die automatischen Methoden anschließende Fehlersuche können mit Hilfe einer Software sehr viel effizienter gestaltet werden. Ein typischer Debugger, der hierfür herangezogen werden kann, ermöglicht das Anhalten der Zielanwendung an einer festgelegten Stelle. So erlaubt er es dem Programmierer, den Wert verschiedener Variablen, und damit den Programmzustand, an genau dieser Stelle abzufragen und zu verändern. [Ze06, S. 215 f.] Auf diese Weise kann z. B. die Beobachtung des Programmzustands erheblich vereinfacht werden, da nicht mehr mit jedem neu eingefügten Ausgabebefehl der Code neu compiliert und u. U. auch deployt, d. h. auf einem Server veröffentlicht, werden muss. Ein weiterer Vorteil eines solchen Debuggers ist das Offenlegen von Seiteneffekten und der inneren Funktionsweise von Programmiersprachen, was ein tieferes Verständnis der Sprache ermöglicht. [Mi00, S. 180] Solche Debugger sind in fast allen gängigen Entwicklungsumgebungen integriert. Dennoch gibt es einige Szenarien, in denen die Entwicklung neuer Debugger nicht nur für Anbieter solcher Entwicklungsumgebungen sinnvoll ist. Zum Beispiel erscheint es durchaus sinnvoll, für die Betrachtung des Kontrollflusses, die in 2.2 beschrieben wurde, nicht nur auf Ausgaben zurückzugreifen oder Vermutungen über den Kontrollfluss anzustellen, sondern während der Laufzeit zu einem bestimmten Test ein Sequenzdiagramm oder Ähnliches zu erstellen, um verlässliche Informationen darüber zu erhalten, welche Funktionen bzw. Methoden zu welchem Zeitpunkt an welcher Stelle des Programms aufgerufen wurden. Eine Situation, in der nicht auf andere Mittel, wie z. B. die Analyse von Programmausgaben, zurückgegriffen werden kann, ist die Entwicklung eines deklarativen Debuggers. Hierbei ist es ebenfalls wichtig, den Kontrollfluss zu betrachten. Es werden jedoch deutlich umfangreichere Informationen benötigt als im ersten Beispiel. Soll bspw. ein deklarativer Debugger für in Java TM programmierte Software implementiert werden, so werden neben dem Ergebnis einer Methode Angaben über die Parameter, mit denen diese Methode aufgerufen wurde, sowie die (Klassen-)Attribute des 4

8 Kapitel 3: Grundlagen der Spezifikation der Java TM Platform Debugger Architecture aufrufenden Objekts benötigt. [CHK06, S. 4] Eine Programmausgabe, die all dies beinhalten würde, wäre sehr unübersichtlich. Zudem kann ein Tool die optimale Auswahl der zu betrachtenden Knoten unterstützen. [CHK06, S. 4] Die Entwicklung eines Debuggers ist hier also unumgänglich. Die Java TM Platform Debugger Architecture, die Thema dieser Arbeit ist, bietet Mittel, um diese Aufgaben zu erfüllen. Im Folgenden soll sie detailliert beschrieben werden. 3 Grundlagen der Spezifikation der Java TM Platform Debugger Architecture 3.1 Definition und Zweck Die Java TM Platform Debugger Architecture (JPDA) ist eine modulare Architektur, die es Entwicklern ermöglicht, Debugger zu implementieren, ohne der Plattform Beachtung zu schenken, auf der der Debugger laufen soll. Sie überträgt somit die Idee von Java TM, dass einmal entwickelte Programme auf jeder Plattform laufen können, auf Debugger. Diese Debugger sollen zudem Programme debuggen können, die auf einem anderen Server oder einer anderen Plattform ausgeführt werden als der Debugger. Darüber hinaus können mit JPDA andere Programme entwickelt werden, die Informationen über den Zustand eines laufenden Programms benötigen, wie z. B. Profiling-Tools. JPDA bietet außerdem die Möglichkeit, in Ausführung befindliche Programme zu manipulieren, d. h. ihren Zustand zu verändern und sogar bestimmte Methoden aufzurufen. Im Fokus dieser Arbeit stehen die Möglichkeiten, die JPDA im Rahmen des Debugging bietet. Neben der Bereitstellung einer solchen modularen Architektur ist das Ziel von JPDA, eine Referenzimplementierung anzubieten, auf deren Basis eigene Debugger entwickelt und von der einzelne Bestandteile durch eigene Entwicklungen ausgetauscht werden können. JDPA besteht aus zwei Interfaces, dem Java TM Debug Interface (JDI) und dem Java TM Virtual Machine Tool Interface (JVMTI), einem Protokoll zur Übertragung von Nachrichten, dem Java TM Debug Wire Protocol (JDWP), sowie zwei Softwarekomponenten, die die Interfaces miteinander verknüpfen. Häufig wird auch JDWP als Interface bezeichnet. [JPDAb06] JVMTI beschreibt die Funktionalität, die eine virtuelle Maschine erbringen muss, damit auf ihr laufende Java TM -Programme debuggt werden können, während JDWP 5

9 Kapitel 3: Grundlagen der Spezifikation der Java TM Platform Debugger Architecture das Format und die Semantik von Nachrichten beschreibt, die zwischen der debuggten Anwendung und dem Debugger versandt werden. JDI ist ein reines Java TM - Interface, das eine Sicht auf das entfernt laufende, debuggte Programm darstellt. [JPDAc06] Theoretisch könnten allein mit Hilfe von JDWP Debugger entwickelt werden, die sowohl plattformunabhängig sind als auch Programme debuggen können, die entfernt ausgeführt werden. Allerdings würde dies deutlich mehr Aufwand bei der Implementierung einer Debugger-Architektur bedeuten. JDI ermöglicht es dem Entwickler, bei der Implementierung des Front-end vom Format und der Semantik der zur Anwendung geschickten Nachrichten zu abstrahieren und Anfragen an die debuggte Anwendung als gewöhnliche Aufrufe von Java TM -Methoden zu formulieren. Analog dazu kann dank JVMTI bei der Entwicklung einer virtuellen Maschine von JDWP abstrahiert werden. [JPDAd06] Die Entwicklung eines Debuggers ist also sehr einfach und in der Mehrzahl aller Fälle mit Hilfe von JDI möglich, weswegen in dieser Arbeit der Fokus auf der Debuggerentwicklung mit JDI liegt. Trotzdem soll darauf hingewiesen werden, dass in einigen Fällen auf die Entwicklung auf Basis von JDWP oder JVMTI nicht verzichtet werden kann. JDWP ist z. B. nicht zu umgehen, wenn das Front-end des Debuggers nicht in Java TM implementiert ist. Soll das zu entwickelnde Tool sehr spezialisierte Funktionalitäten bieten, die JDWP und JDI nicht anbieten, muss auf JVMTI zurückgegriffen werden. [JPDAe06]. 3.2 Architektur Nachdem im vorigen Abschnitt beschrieben wurde, welche Interfaces und Komponenten es in JPDA gibt, sollen nun die Architektur von JDPA und das Zusammenwirken dieser Komponenten genauer erläutert werden. JDPA ist eine Dreischichtarchitektur, die grundsätzlich aus dem debuggten Prozess, einem Kommunikationskanal und dem Debugger besteht. Abbildung 1 zeigt die Bestandteile der grundsätzlichen Komponenten [JPDAf06], die im Folgenden genauer erläutert werden. Der debuggte Prozess besteht aus der debuggten Anwendung und der virtuellen Maschine, auf der diese Anwendung läuft. Die virtuelle Maschine muss JVMTI implementieren, während an die debuggte Anwendung lediglich die Anforderung zu stellen ist, dass sie in Java TM implementiert sein muss. Das Back-end des Debuggers realisiert die Kommunikation zwischen dem Front-end des Debuggers und der virtuellen Maschine, d. h. es transformiert eingehende Nachrichten in ein Format, 6

10 Kapitel 3: Grundlagen der Spezifikation der Java TM Platform Debugger Architecture Abbildung 1: Architektur von JPDA das die virtuelle Maschine umsetzen kann, bzw. transformiert ausgehende Nachrichten in eine Form, die JDWP entspricht. Es muss in nativem Code geschrieben sein. Die angesprochenen Nachrichten werden über einen Kommunikationskanal zwischen Front-end und Back-end verschickt. Dieser besteht aus zwei Teilen: einem Konnektor, der die Verbindung herstellt, und einem Transportmechanismus, der definiert, auf welche Weise die Kommunikation stattfindet, z. B. mit Hilfe von gemeinsamem Speicher oder einer Socket-Kommunikation. Der Transportmechanismus ist nicht Bestandteil von JDWP. Es gibt drei Arten von Konnektoren: Listening Connectors, mit deren Hilfe das Front-end auf eingehende Verbindungsanfragen des Back-end lauscht, Attaching Connectors, bei denen sich das Front-end mit einer bereits laufenden virtuellen Maschine verbindet, Launching Connectors, bei deren Verwendung, das Front-end die zu debuggende Anwendung startet.[jpdaf06] Ein Konnektor definiert neben der Art des Verbindungsaufbaus genau einen Transportmechanismus, den die aufzubauende Verbindung verwendet.[jdia06] Die Referenzimplementierung von JPDA umfasst zwei Transportmechanismen und einige Konnektoren. [JPDAf06] Seit Java TM 5.0 beinhaltet JPDA die Service Provider Interfaces, die es dem Entwickler ermöglichen, eigene Transportmechanismen und Konnektoren zu implementieren. [JPDAg06] Da diese sich nicht auf die Debuggingfunktionalitäten des zu entwickelnden Tools auswirken, werden sie in dieser Arbeit nicht weiter betrachtet. Das Front-end des Debuggers implementiert JDI und stellt das andere Ende des 7

11 Kapitel 3: Grundlagen der Spezifikation der Java TM Platform Debugger Architecture Kommunikationskanals dar. Ebenso wie im Back-end werden hier ein- und ausgehende Nachrichten transformiert. Der Client des Front-end ist die Benutzerschnittstelle des Debuggers. Sie ist nicht Bestandteil von JPDA. Das Zusammenspiel dieser Komponenten soll am vereinfachten Beispiel einer Abfrage des aktuellen Wertes einer Variable in der virtuellen Maschine verdeutlicht werden. Wird in der Implementierung der graphischen Benutzeroberfläche die Abfrage ei- Abbildung 2: Zusammenwirken der Komponenten von JPDA nes Variablenwertes initialisiert, so wird im Front-end auf dem Objekt, dessen Feld abgefragt werden soll, die Methode getvalue(field field) aufgerufen. Hier wird diese Anfrage JDWP entsprechend umkodiert und über den Kommunikationskanal an das Back-end des Debuggers weitergeleitet. Das Back-end transformiert die Anfrage und leitet sie an die virtuelle Maschine weiter. Es wurde bereits darauf hingewiesen, dass JPDA aus drei Interfaces besteht. Diese werden im Folgenden genauer dargestellt. JDI soll ein eigenes Kapitel gewidmet werden, da hier der Fokus der Arbeit liegt. Zuvor soll allerdings auf die Interfaces JVMTI und JDWP eingegangen werden. 3.3 Spezifikation der nativen Interfaces Java TM Virtual Machine Tool Interface JVMTI ist ein natives Interface, das von der virtuellen Maschine implementiert werden muss, auf der die Zielanwendung ausgeführt werden sollen. Es handelt sich dabei um ein Zwei-Wege-Interface, d. h. die virtuelle Maschine kann mit Hilfe von JVMTI den Client über das Auftreten bestimmter Ereignisse informieren. Gleichzeitig kann der Client mit Hilfe von JVMTI Abfragen an die virtuelle Maschine schicken. Da- 8

12 Kapitel 3: Grundlagen der Spezifikation der Java TM Platform Debugger Architecture durch, dass er im selben Prozess wie die virtuelle Maschine läuft und JVMTI ein natives Interface ist, kann das zu debuggende Programm stärkst möglich kontrolliert werden, dabei aber nur minimal Einfluss auf die Ausführung des Programms nehmen. [JVMTI06] JVMTI wird für die hier besprochenen Zwecke nur äußerst selten verwendet, weil meist auf Interfaces höherer Ebenen zurückgegriffen werden kann. Da eine detailliertere Beschreibung darüber hinaus keinen Beitrag zum Verständnis von JDPA liefert, soll auf weitere Erläuterungen an dieser Stelle verzichtet werden Java TM Debug Wire Protocol JDWP ist ein zustandsloses, paketbasiertes Protokoll, welches Format und Layout von Nachrichten definiert, die zwischen dem debuggten Prozess und dem Debugger verschickt werden. Nicht definiert ist der Transportmechanismus zur Übertragung der Nachrichten, der frei gewählt werden kann. Durch JDWP können mit demselben Debugger sowohl Prozesse, die auf dem gleichen Computer ausgeführt werden, als auch entfernt laufende Prozesse debuggt werden. Nach dem Herstellen einer Verbindung wird zunächst ein Handshake durchgeführt, bei dem beide Partner signalisieren, dass sie bereit sind, über die Verbindung Daten auszutauschen. Dabei sendet zunächst der Debugger die Daten JDWP-Handshake an die debuggte virtuelle Maschine, worauf diese mit denselben Daten antwortet. Anschließend können über die Verbindung Pakete in beide Richtungen gesendet werden. Diese Pakete können entweder Befehle enthalten oder Antworten auf solche Befehle. Abbildung 3 verdeutlicht die Struktur der Pakete. Um eine Antwort der zugehörigen Anfrage zuordnen zu können, enthält der Header Abbildung 3: Sequenzdiagramm zum Ablauf einer Variablenabfrage eine ID, die bei zusammengehörenden Paketen identisch ist. Sie ist unter allen noch 9

13 Kapitel 4: JDI unbeantworteten Anfragen aus derselben Quelle eindeutig. Von den vier für Flags reservierten Bytes wird bisher nur ein Bit verwendet, das angibt, ob es sich bei einem Paket um einen Befehl oder eine Antwort handelt. Alle Befehle, die in einer solchen Anfrage abgesetzt werden können, sind in so genannten Befehlssätzen strukturiert. Bereits von Sun vorgegebene Befehle sind nach den JDI-Interfaces gruppiert, deren Methoden durch die jeweiligen Befehle übertragen werden. Das Feld des Headers für den Befehl gibt an, um welchen Befehl innerhalb des Befehlssatzes es sich handelt. Der Header eines Antwortpaketes enthält keine Angaben zum zugehörigen Befehl sondern lediglich einen Fehlercode, der im Falle einer fehlerfreien Ausführung auf Null gesetzt ist. Im Anschluss an den Header enthält das Paket befehlsspezifische Daten. Bei der Abfrage eines Wertes einer Variablen enthält der Datenteil z. B. Informationen darüber, welche Werte abgefragt werden sollen. Die Antwort enthält die aktuellen Werte der Variablen. In einigen Fällen enthalten Pakete keine Daten. Dies ist bspw. bei Anfrage- und Antwortpaketen für die Kontrolle der Threads im debuggten Prozess der Fall. [JDWP06] 4 JDI 4.1 Spezifikation Zweck JDI ist ein reines Java TM -Interface und definiert die höchste Schicht von JPDA. Es wird vom Front-end des Debuggers implementiert und enthält Methoden, mit deren Hilfe auf den aktuellen Zustand des zu debuggenden Programms zugegriffen werden kann. [JDIa06] Ein Front-end, das JDI implementiert, kann auf den anderen Komponenten der zu JPDA gehörenden Referenzimplementierung aufsetzen. Es kann allerdings auch zusammen mit selbstentwickelten Komponenten arbeiten, welche die anderen, in JPDA definierten Interfaces implementieren. Sun empfiehlt, einen Debugger auf dieser Schicht aufsetzend zu implementieren. [JDIa06] Im Folgenden soll zunächst ein Überblick über die Aufgaben der verschiedenen Packages von JDI gegeben werden. Im Anschluss daran werden an Hand des Ablaufs einer Debugging Session die wichtigsten Interfaces vorgestellt. 10

14 Kapitel 4: JDI Packagestruktur Wird von den Interfaces für Transportservices abgesehen, so besteht JDI aus vier Packages. 2 Das Kernpaket ist das Paket com.sun.jdi. Es enthält Interfaces zur Abbildung 4: Strukturierung der Pakete an Hand einer Debugging Session Abbildung von Objekten, lokalen Variablen, Klassen, Threads, dem Stack und der virtuellen Maschine selbst und unterstützt somit den gesamten Ablauf einer Debugging Session. Zudem enthält es die Klasse Bootstrap, mit deren Hilfe eine Debugging Session initialisiert werden kann. Eine solche Sitzung beginnt mit dem Aufbau der Verbindung mit Hilfe von Konnektoren, wie in Abschnitt 3.2 bechrieben. Diese Phase wird von dem Paket com.sun.jdi.connect unterstützt, das Interfaces für Transportservices, die verschiedenen Konnektortypen und die Argumente von Konnektoren enthält. Ist die Verbindung hergestellt, so ist festzulegen, von welchen Ereignissen in der virtuellen Maschine der Debugger informiert werden soll. Solche Requests können bspw. für den Start eines Threads, das Auftreten einer Exception oder den Eintritt in eine Methode definiert werden. Das Paket com.sun.jdi.request unterstützt diese Phase. Ist die zu debuggende Anwendung gestartet so beginnt ein Zyklus, in dem der Debugger auf Ereignisse wartet und darauf reagiert. Dazu werden die Interfaces des Pakets com.sun.jdi.event genutzt. Auch in dieser Phase besteht die Möglichkeit, z. B. als Reaktion auf ein Ereignis, neue Anfragen zu definieren. Im Folgenden soll genauer beschrieben werden, welche Interfaces in den verschiedenen Phasen von Bedeutung sind und wie sie eingesetzt werden Aufbau der Verbindung Zu Beginn einer Debugging Session ist ein Manager für Verbindungen des Debuggers zur virtuellen Maschinen zu laden, der das Interface VirtualMachineManager aus dem Kernpaket implementiert. Dieser Zugriff findet mit Hilfe der Klasse Bootstrap 2 Die folgende Beschreibung von JDI und die Entwicklung des Beispieldebuggers beruhen auf der Dokumentation von JDI unter [JDIb06]. 11

15 Kapitel 4: JDI und deren statischer Methode virtualmachinemanager() statt. Bei Aufruf der Methode werden außerdem alle in der Implementierung verfügbaren Konnektoren erzeugt. Auf diese Konnektoren kann mit Hilfe der Methode allconnectors() oder konnektortypspezifischer Methoden des VirtualMachineManager zugegriffen werden. Das Interface Connector bietet Zugriff auf die Argumente des Konnektors, mit deren Hilfe, der gewünschte Konnektor auszuwählen ist. Anschließend müssen die Argumente des Konnektors zum Start der Anwendung gesetzt und die Verbindung zur virtuellen Maschine aufgebaut werden. Dies geschieht ebenfalls mit Hilfe des Connector-Interfaces und dessen Kindinterfaces. Im Falle von Konnektoren, die eine virtuelle Maschine starten bzw. sich zu einer solchen verbinden, liefern die Methode launch(args) bzw. attach(args) eine Abbildung der virtuellen Maschine. Diese ist ein Objekt einer Klasse, die das Interface VirtualMachine implementiert. Im Fall eines Listening Connectors wird zunächst durch Aufruf von startlistening(args) die Bereitschaft zur Akzeptanz einer Verbindung signalisiert. Nach Eingehen einer entsprechenden Anfrage wird mit accept(args) die Verbindung hergestellt. Der beschriebene Prozess ist in Abbildung 5 am Beispiel eines Launching Connectors dargestellt. Abbildung 5: Aufbau einer Verbindung mit Hilfe eines Launching Connectors Definition von Anfragen Ist die Verbindung mit der virtuellen Maschine hergestellt, so müssen Ereignisse definiert werden, über die der Debugger informiert werden soll, wenn sie in der virtuellen Maschine auftreten. Dies geschieht mit Hilfe des EventRequestManager der virtuellen Maschine, der 12

16 Kapitel 4: JDI durch eventrequestmanager() aufgerufen wird. Er bietet Methoden an, um Requests für verschiedene Ereignisse zu definieren. Beispiele für solche Ereignisse sind Methodeneintritte, das Erreichen von Breakpoints und das Auftreten von Exceptions. 3 Die meisten dieser Methoden sind parameterlos. Wurde z. B. mit createmethodentryrequest() ein solcher Request erzeugt, können Filter definiert werden, die Ereignisse vor der Weiterleitung an den Debugger selektieren. Diese Maßnahme kann die Performanz eines Debuggers erheblich verbessern, da so verhindert werden kann, dass Methoden in Klassen, die nicht debuggt werden sollen, z. B. Methoden der Klassen Integer oder String, einen solchen Request verursachen. Anschließend ist zu definieren, ob und welche Threads in der virtuellen Maschine bei Auftreten des entsprechenden Ereignisses angehalten werden sollen. Schließlich wird der Request aktiviert. Abbildung 6: Definition von Requests Behandlung von Ereignissen Sind alle Requests definiert, so kann die Anwendung mit resume() gestartet und mit der Behandlung der Ereignisse begonnen werden. Alle auftretenden Ereignisse, für die eine Anfrage definiert wurde, werden in die EventQueue der virtuellen Maschine eingereiht, wobei gleichzeitig auftretende Ereignisse in einem EventSet gruppiert sind. Durch eventqueue() kann auf diese Ereignisse zugegriffen werden. Abhängig davon, welche Art von Ereignis vorliegt, werden vom betrachteten Debugger definierte Schritte ausgeführt. Zwei häufig durchzuführende Aufgaben sollen hier hervorgehoben werden: die Behandlung eines ClassPrepareEvent und das Auslesen 3 Tabelle 1 im Anhang listet alle Ereignisse von JDI auf. 13

17 Kapitel 4: JDI des Programmstatus z. B. nach Auftreten eines Breakpoint. Zwar ist das Auftreten eines ClassPrepareEvent selten direkt interessant für den Entwickler, allerdings können manche Anfragen erst nach dem Laden einer Klasse definiert werden. Deshalb wird, um bspw. BreakpointRequests für Codezeilen innerhalb einer Klasse und WatchpointRequests für die Attribute einer Klasse zu definieren, ein ClassPrepareRequest definiert. Bei Auftreten des entsprechenden Events werden dann die eigentlich gewünschten Requests definiert. Ein Debugger wird hauptsächlich eingesetzt, um den Zustand eines Programms in Ausführung zu beobachten. Aus diesem Grund wird an dieser Stelle beschrieben, wie sich das konkrete Auslesen von Werten der beobachteten Objekte gestaltet. Abbildung 7 zeigt ein vereinfachtes Diagramm der Interfaces, die zum Auslesen von Abbildung 7: Klassen des Pakets com.sun.jdi zum Auslesen von Variablenwerten Variablenwerten benötigt werden. 4 Alle dargestellten Interfaces, bzw. deren Implementierungen, stellen nicht die Objekte in der virtuellen Maschine sondern lediglich deren Abbildungen dar. Über den aktuellen StackFrame kann, wie der folgende Programmcode zeigt, auf die lokalen Variablen und das aktuelle Objekt this zugegriffen werden. /** get current stackframe from event s thread argument 0 gets stack frame of current method*/ currentframe = event.thread().frame(0); /** get this Object*/ ObjectReference currentthis = currentframe.thisobject(); /** get local variables*/ List<LocalVariable> localvars = currentframe.visiblevariables(); 4 Das vollständigen Hierarchien sind in Abbildung 8 dargestellt. 14

18 Kapitel 4: JDI Während der Zugriff auf this bereits den Wert (Value) des zugehörigen Objekts liefert, gibt die Methode visiblevariables() lediglich die Abbildungen der lokalen Variablen selber zurück. Diese Abbildungen enthalten nur die statischen Informationen über ihre Deklaration. Um den Wert der Variablen zu erhalten, muss er mit Hilfe des StackFrames abgefragt werden. Die unterschiedlichen Arten von Werten, wie z. B. Objekte und Werte primitiver Datentypen, Booleans und Integerwerte, sind in einer Vererbungshierarchie strukturiert, die sich nahezu exakt in der Vererbungshierarchie der Typen widerspiegelt. Die weitere Behandlung konkreter Werte, also lokaler Variablen oder des Objekts this, hängt davon ab, ob es sich um Objekte oder Werte primitiver Datentypen handelt. Liegt ein primitiver Datentyp vor, kann der Wert mit der Methode value() des entsprechenden Interfaces abgefragt werden. Handelt es sich bei einer lokalen Variablen um ein Objekt, so kann mit Hilfe des zugehörigen ReferenceType auf die Attribute des Objekts zugegriffen werden. Der folgende rekursive Programmcode liefert alle Werte der lokalen Variablen des aktuellen StackFrame und ihrer Attribute. 5 private StringBuffer getvalue(value value){... if (value instanceof PrimitiveValue) { //get string representation of primitive value return result.append(findvalue((primitivevalue) value)); }... if (value instanceof ObjectReference) { // get all attributes of the object List<Field>fields=((ReferenceType)value.type()).allFields(); // get values of all fields for (Field current : fields){... result.append(current.name()+"="+ getvalue(((objectreference)value).getvalue(current))); } } 5 Es handelt sich hier um vereinfachten Code, der Gesamtcode incl. Behandlung von Arrays, Strings und inneren Klassen ist in Abschnitt B.2.1 des Anhangs abgedruckt. 15

19 Kapitel 4: JDI } return result; Um das Beschriebene zu verdeutlichen und auf weitere Aspekte von JDI genauer eingehen zu können, wird im Folgenden eine Anwendung von JDI genauer dargestellt. Zunächst sollen dabei einige, grundlegende Aspekte der Architektur der Anwendung erläutert und auf die grundsätzliche Funktionaltiät eingegangen werden. Im Anschluss werden einige, wichtige Funktionen detailliert erläutert. 4.2 Vorstellung eines Beispieldebuggers Übersicht Der im Rahmen dieser Arbeit entwickelte Debugger nutzt die Referenzimplementierung von JPDA, der er eine Benutzerschnittstelle hinzufügt, die mit Hilfe von JDI auf das Front-end von JPDA zugreift. Die Anwendung besteht aus drei Paketen: einem Paket mit Kontrollklassen, das die eigentliche Debuggingfunktionalität implementiert, einem Paket mit Grenzklassen, das die graphische Benutzerschnittstelle realisiert und einem Paket mit Entitätsklassen, das die Kommunikation zwischen Objekten beider Pakete unterstützt. Innerhalb des Pakets debugger stellt die Klasse Debugger die einzige Schnittstelle zur Benutzeroberfläche dar. 6 Zum Aufbau der Verbindung zwischen dem Debugger und der Zielanwendung wird der in der Referenzimplementierung enthaltene Konnektor com.sun.jdi. CommandLineLaunch verwendet, der unter Windows gemeinsam genutzten Speicher als Mechanismus zur Nachrichtenübermittlung nutzt. Nach dem Start der Anwendung gibt der Nutzer die zu debuggende Klasse und die zugehörigen Attribute an. Dabei ist darauf zu achten, dass die Verzeichnisse, in denen sich die *.class-dateien aller in der Anwendung verwendeten Klassen befinden, im Class-Path des Systems enthalten sind. Anschließend legt der Nutzer Zeilen fest, in denen Breakpoints gesetzt werden sollen und definiert, über welche Ereignisse er informiert werden will. Erreicht die Anwendung nach ihrem Start eine Programmzeile, in der ein Breakpoint gesetzt ist, so öffnet sich ein Fenster, mit dessen Hilfe der Nutzer die Werte der aktuellen Variablen inspizieren kann. Außerdem hat er die Möglichkeit, die Anwendung abzubrechen, sie schrittweise fortzuführen oder im normalen Modus weiterlaufen zu lassen. Nach Beendigung der Anwendung zeigt der Debugger in gesonderten Textfeldern 6 In Kapitel 9 des Anhangs ist das Klassendiagramm der Anwendung abgebildet. 16

20 Kapitel 4: JDI den Output- und den Error-Stream der Anwendung und die Ausgabe des Debugvorgangs, also Informationen über angeforderte Ereignisse, an. Auf die Realisierung einiger dieser Funktionen, die nicht bereits in 4.1 vorgestellt wurden, wird nun genauer eingegangen Behandlung des Output- und des Error-Stream der debuggten Anwendung Wird wie im Fall der vorgestellten Anwendung die Verbindung zur debuggten virtuellen Maschine mit Hilfe eines Launching Connectors hergestellt, so müssen der Output- und der Error-Stream der Anwendung regelmäßig gelesen werden. Andernfalls bricht die Ausführung ab, wenn einer der beiden Streams überläuft. Hierzu kann mit folgendem Code auf die betreffenden Streams der Anwendung zugegriffen werden. [JDIa06, Connector] Process process = vm.process(); error = new ReadStreamsThread("error",process.getErrorStream(), this,true); In der entwickelten Anwendung wird die Aufgabe, die Streams zu lesen, von separaten Threads der Klasse ReadStreamsThread wahrgenommen. Diese lesen in einer Schleife die Daten der ihnen übergegebenen InputStreams, wandeln die ByteStreams in CharacterStreams um und geben das Ergebnis an den Debugger zurück, wenn die Anwendung beendet ist Bearbeiten der EventQueue Nach dem Start der Anwendung werden die auftretenden Ereignisse in einer EventQueue hinterlegt. Diese kann mit Hilfe eines speziellen EventIterator bearbeitet werden, wie der folgende Programmcode zeigt. // quasi endless loop will be exited on VMDisconnectEvent or // VMDisconnectException while(connected){ try{ EventSet eventset = queue.remove();//get EventSet EventIterator iterator = eventset.eventiterator(); 17

21 Kapitel 4: JDI //iterate over events in EventSet while (iterator.hasnext()){ if (!(event instanceofbreakpointevent event instanceof StepEvent)) { String result = handler.handle(event);... } else BreakpointHit bphit = new BreakpointHit(client,this, handlesteporbreakpoint((locatableevent)event)); }} eventset.resume();//resume suspended Threads of EventSet }catch (VMDisconnectedException e){...} Es wird deutlich, dass die Behandlung der meisten Ereignisse in eine andere Klasse ausgelagert ist. Dies dient lediglich der Übersichtlichkeit der Klassen. StepEvents und BreakpointEvents werden in der Klasse Debugger behandelt, da sie eine Interaktion mit der Benutzerschnittstelle erfordern, um die aktuellen Werte von Variablen anzuzeigen Setzen von Breakpoints Vor dem Start der Zielanwendung definiert der Nutzer den vollqualifizierten Klassennamen und die Zeile der Quellcodestelle, an die ein Breakpoint gesetzt werden soll. Diese Angaben werden zunächst nur dem Debugger als Objekte der Klasse BreakpointLocation übergeben. Das wirkliche Setzen eines Breakpoint kann erst zur Laufzeit der Zielanwendung stattfinden, da dieser Schritt die Angabe einer konkreten Location voraussetzt. Die Location zu einer bestimmten Codezeile wird jedoch erst erzeugt, wenn die zugehörige Klasse geladen wird. Folglich werden Breakpoints bei Auftreten eines ClassPrepareEvents gesetzt. Dies geschieht in der folgenden Methode der Klasse EventHandler. private void handleclasspreparation(classprepareevent event){... //uses List<BreakpointLocation> with Bps for type //get type of class being prepared ReferenceType type = event.referencetype();... 18

22 Kapitel 5: Fazit if (breakpoints.size()<=0) return; //no Bps in type try{ //load locations of type locations = type.alllinelocations(); }catch(absentinformationexception e){//handle} for (BreakpointLocation currbp : breakpoints){ for (Location location : locations){ if (location.linenumber()==currbp.getline()){ //create request if location matches Bp BreakpointRequest request = manager.createbreakpointrequest(location);... }} if (!bpset) //alert user } } Nachdem die wichtigsten Elemente von JPDA und insbesondere JDI vorgestellt wurden, wird im Folgenden ein Fazit gezogen. 5 Fazit Ziel dieser Arbeit war es, die Java TM Platform Debug Architecture vorzustellen. Dazu wurden zunächst grundlegende Begriffe erklärt und Ansätze des Debugging aufgezeigt. Nachdem die Bedeutung der Entwicklung von Debuggern verdeutlicht wurde, wurde in Kapitel 3 zunächst die Struktur von JPDA beschrieben und anschließend auf die Interfaces JVMTI und JDWP eingegangen. Schließlich wurde das Java TM Debug Interface detailliert erläutert. Hierzu wurden die Packagestruktur und wichtige Interfaces beschrieben, damit im Anschluss ein auf Basis von JPDA entwickelter Beispieldebugger vorgestellt werden konnte. Die Entwicklung des Beispieldebuggers hat gezeigt, dass auf Basis von JPDA in relativ kurzer Zeit ein Debugger entwickelt werden kann, der die wichtigsten Funktionen einer solchen Software bietet. Grund hierfür ist, dass JPDA diese Funktionen als Java TM -Methoden anbietet. In [CHK06] wurde dargelegt, dass auf Basis von JPDA ein deklarativer Debugger entwickelt werden kann. Auch für die Entwicklung umfangreicher, kommerzieller Debugger ist die von JPDA gebotene Funktionalität ausreichend. [JPDAh06] Ein weiterer Vorteil von JPDA ist, dass ein auf Basis von JPDA entwickelter Debugger Programme, die auf anderen Servern laufen, debuggen kann. Zudem können 19

23 Kapitel 5: Fazit solche Debugger auch bereits laufende Anwendungen debuggen, so dass ein Neustart des Programms zu Debuggingzwecken umgangen werden kann. Allerdings beschränkt die Verwendung von JPDA die Funktionalität des Debuggers an einigen Stellen. So können nur bestimmte Ereignisse abgefangen und behandelt werden und bei Auftreten einer Exception ist es bspw. nicht möglich den kompletten Stacktrace auszulesen. Um solche Funktionalität in einem Debugger anzubieten, müsste das Back-end erweitert werden, was die Verwendung von JVMTI und folglich Programmierung in nativen Sprachen erfordert. Nachteilig wirkt sich außerdem aus, dass die Verwendung von JDI nur möglich ist, wenn zur Entwicklung des Debuggers ausschließlich Java TM verwendet wird. Andernfalls muss ein neues Front-end implementiert werden, wozu auf JDWP zurückgegriffen werden muss, was wesentlich komplexer ist. Darüber hinaus enthält die Referenzimplementierung lediglich zwei Transportmechansimen. Ist eine andere Form des Transports gewünscht, müssen hierfür explizite Methoden entwickelt werden. Durch die Implementierung auf Basis tieferer Schichten von JPDA kann jedoch die Funktionalität von JDI umfassend erweitert werden. Zusammenfassend ist also zu sagen, dass JPDA die Entwicklung eines Debuggers gut unterstützt und dass bereits die durch JDI verfügbare Funktionalität in der Mehrzahl der Fälle ausreichend ist. 20

24 Kapitel A: Ergänzende Erläuterungen zu JDI A Ergänzende Erläuterungen zu JDI A.1 Die Type- und Value-Hierarchie In Abbildung 7 wurde bereits ein vereinfachtes Klassendiagramm der Klassen des Pakets com.sun.jdi vorgestellt. Im Folgenden sollen die Hierarchien der Typeund Value-Interfaces detaillierter dargestellt werden. Die Hierarchien zu Typen Abbildung 8: Hierarchien der Type- und Value-Interfaces und Werten sind nahezu exakt gegeneinander gespiegelt. Allerdings gibt es an einigen, wenigen Stellen Unterschiede. Während in der Hierarchie der Typen alle Interfaces bis auf die Interfaces der untersten Ebene abstrakt sind, ist das Interface ObjectReference in der Hierarchie der Werte nicht abstrakt, obwohl es nicht auf der untersten Ebene ist. Werte, deren Typ ein gewöhnliches Objekt ist, also eine Class-Reference, sind von diesem Typ. Zudem gibt es in der Hierarchie der Werte detailliertere Interfaces als in der Type-Hierarchie. Beispiele hierfür sind 21

25 Kapitel B: Dokumentation der Beispielanwendung StringReference, ThreadReference oder ClassObjectReference. A.2 Verfügbare Ereignisse Die folgende Tabelle listet alle in JDI verfügbaren Ereignisse auf und beschreibt sie kurz. Name des Requests MethodEntryEvent MethodExitEvent ClassPrepareEvent ClassUnloadEvent ModificationWatchpointEvent AccessWatchpointEvent ExceptionEvent StepEvent BreakpointEvent ThreadStartEvent ThreadDeathEvent VMDeathEvent Beschreibung des Ereignis Eintritt in eine Methode Verlassen einer Methode Vorbereitung einer Klasse Entladen der Klasse Veränderung eines Felds Zugriff auf ein Feld Auftreten einer Exception Ausführung einer Anweisung Erreichen eines Breakpoints Start eines Thread Beendung eines Thread Beendung der Anwendung Tabelle 1: Ereignisse in JDI Darüber hinaus gibt es das abstrakte Interface LocatableEvent. Von diesem können Ereignisinterfaces erben, wenn der Thread eines Ereignisses des entsprechenden Typs abgefragt werden soll. B Dokumentation der Beispielanwendung B.1 Architektur Wie in Kapitel bereits kurz beschrieben, besteht die Beispielanwendung 7 aus drei Paketen für Kontroll-, Grenz- und Entitätsklassen. Zur Verdeutlichung der Zusammenhänge ist im Folgenden das Klassendiagramm der Anwendung abgebildet. Um das Zusammenwirken der wichtigsten Klassen zu verdeutlichen zeigt Abbildung 10 ein Sequenzdiagramm des grundsätzlichen Ablaufs einer Debugging Session. Von 7 Die komplette Dokumentation, sowie der Programmcode und ein ausführbares jar-archiv der Anwendung liegen der Arbeit auf CD-Rom bei. 22

26 Kapitel B: Dokumentation der Beispielanwendung Abbildung 9: Klassendiagramm der Beispielanwendung der Möglichkeit Breakpoints zu setzen wurde in diesem Beispiel abgesehen. Die Methode debug(options) ruft nacheinander die Methoden auf, die die einzelnen Phasen einer Debugging Session behandlen. Diese wurden bereits in Kapitel 4 erläutert. Abbildung 10: Sequenzdiagramm einer einfachen Debugging Sessions 23

27 Kapitel B: Dokumentation der Beispielanwendung B.2 Ausgewählte Methoden der Beispielanwendung B.2.1 Vollständige Methode getvalue Die Methode getvalue(value) der Klasse Util diente in Kapitel dazu, zu verdeutlichen wie auf rekursive Weise der Zustand von Objekten ermittelt werden kann. Sie ist nicht Bestandteil des im Rahmen dieser Arbeit entwickelten Debuggers, sondern wurde lediglich zu Illustrationszwecken entwickelt. 8 Im Folgenden wird der vollständige, kommentierte Programmcode vorgestellt. public static StringBuffer getvalue(value value, int indent){ StringBuffer result = new StringBuffer(); // avoid endless loops due to objects referencing // each other or to nested classes if (indent >=5) return result; if (value instanceof PrimitiveValue) { //find result gets a string representation return result.append (findvalue((primitivevalue) value)+"\n"); }else if (value instanceof StringReference) // return the string value return result.append(((stringreference)value).value()+"\n"); result.append("\n"); if (value instanceof ObjectReference) { if (value instanceof ArrayReference){ ArrayReference array = (ArrayReference) value; // for each array component for (int i=0;i<array.length();i++){ //indent text to structure output for (int j = 0;j<indent;j++){ //call this method to treat component result.append( ); } result.append("value of index"+i+"= "+ getvalue(array.getvalue(i),indent+1)); } return result; } 8 Sie kann allerdings durch Einkommentieren von Zeile 453 der Klasse Debugger getestet werden. 24

28 Kapitel B: Dokumentation der Beispielanwendung } B.2.2 // if it is a non array object // get all attributes of the object List<Field> fields = ((ReferenceType)value.type()). allfields(); // for each field for (Field current : fields){ //indent text to structure output for (int i = 0;i<indent;i++){ result.append(); } //call this method to treat resolve field result.append(current.name()+"= "+ getvalue(((objectreference)value). getvalue(current),indent+1)); } } return result; Die Methode findvalue(primitivevalue) Die Methode findvalue(primitivevalue) überprüft, welchen primitiven Typs die übergebene Variable ist. Anschließend wird der entsprechende Wert aus der Variablen ausgelesen und in eine String-Variable konvertiert. Diese Schritte sind im folgendem Code für zwei beispielhafte Datentypen aufgezeigt. public static String findvalue(primitivevalue value){ if (value instanceof BooleanValue) return new Boolean(value.booleanValue()).toString();... if (value instanceof IntegerValue) return new Integer(value.intValue()).toString();... } B.2.3 Schrittweises Debugging Der entwickelte Debugger ermöglicht es dem Nutzer, die Ausführung der Anwendung nach dem Auftreten eines Breakpoints schrittweise fortzuführen, d. h. jede Anwei- 25

29 Kapitel B: Dokumentation der Beispielanwendung sung einzeln auszuführen. Hierzu werden so genannten StepRequests verwendet, die nach jeder Anweisung ein StepEvent auslösen. public void steppressed(){ EventRequestManager manager = vm.eventrequestmanager(); deletesteprequestifneeded(manager); StepRequest request = manager.createsteprequest (threadofcurrentbreakpoint, StepRequest.STEP LINE, StepRequest.STEP OVER ); request.setsuspendpolicy(eventrequest.suspend ALL ); request.addclassexclusionfilter("java.*");... // we only want the application to break at the next step // not at all future steps request.addcountfilter(1); request.enable(); } Pro Thread kann nur ein StepRequest definiert sein. Deswegen wird mit Hilfe der Methode deletesteprequestifneeded(eventrequestmanager) überprüft, ob bereits ein solcher Request definiert wurde und dieser ggf. gelöscht. Die Definition eines StepRequest erfordert neben der Angabe des Threads, für den der Request gelten soll, die Auswahl zweier Optionen: der Schrittweite und der Schritttiefe. Bei der Schrittweite sollte in den meisten Fällen StepRequest.STEP LINE gewählt werden, da auf diese Weise jedes Mal, wenn die Zeile des Quellcodes sich ändert, eine StepEvent ausgelöst wird. Bei der Schrittweite besteht die Auswahl zwischen STEP OVER, STEP INTO und STEP OUT. Durch die Verwendung der ersten Alternative werden StepEvents immer in der Methode ausgelöst, in der auch der StepRequest definiert wird. Durch StepRequest.STEP INTO erfolgen auch Sprünge in aufgerufene Methoden hinein und mit Hilfe von StepRequest.STEP OUT wird ein StepRequest erst bei Verlassen der aktuellen Methode ausgelöst. [JDIb06] 26

30 Literaturverzeichnis Literatur [TH01] Matt Telles, Yuan Hsieh: The Science of DEBUGGING, Coriolis, [ST04] Andreas Spillner, Thilo Linz: Basiswissen Softwaretest, 2. Aufl., dpunkt.verlag, [Ba98] Helmut Balzert Lehrbuch der Software-Technik, Software-Management Software-Qualitätssicherung Unternehmensmodellierung, Spektrum Akademischer Verlag, [Ze06] Andreas Zeller Why programs fail, dpunkt.verlag, [CHK06] Rafael Caballero, Christian Hermanns, Herbert Kuchen: Algorithmic Debugging of Java Programs, Proceedings of International Workshop on Functional and Logic Programming (WFLP), Madrid,. [Mi00] Will David Mitchell: DeBUGGING JAVA, McGraq-Hill, [JPDAa06] Sun Microsystems, Inc.: Java TM Platform Debugger Architecture, Sun Developer Network (SDN). URL: Abrufdatum: 29. Oktober [JPDAb06] Sun Microsystems, Inc.: Java TM Platform Debugger Architecture - Overview, Sun Developer Network (SDN). URL: Abrufdatum: 29. Oktober [JPDAc06] Sun Microsystems, Inc.: FAQ - Java TM Platform Debugger Architecture - Architecture, Sun Developer Network (SDN). URL: Abrufdatum: 29. Oktober [JPDAd06] Sun Microsystems, Inc.: FAQ - Java TM Platform Debugger Architecture - Architecture Q1, Sun Developer Network (SDN). URL: Abrufdatum: 29. Oktober [JPDAe06] Sun Microsystems, Inc.: FAQ - Java TM Platform Debugger Architecture - Architecture Q2, Sun Developer Network (SDN). URL: Abrufdatum: 29. Oktober