Java ausführen und debuggen

Visual Studio Code ermöglicht Ihnen das Debuggen von Java-Anwendungen über die Erweiterung Debugger for Java. Es handelt sich um einen leichtgewichtigen Java-Debugger, der auf dem Java Debug Server basiert und die Language Support for Java™ by Red Hat erweitert.

Hier ist eine Liste der unterstützten Debugging-Funktionen

• Starten/Anhängen (Launch/Attach)
• Haltepunkte
• Ausnahmen (Exceptions)
• Pause & Fortsetzen
• Einzelschritt (Step In/Out/Over)
• Variablen
• Aufrufstapel (Call Stacks)
• Threads
• Debug-Konsole
• Bewertung
• Hot Code Replace

Der Java-Debugger ist ein Open-Source-Projekt, das Mitwirkende zur Zusammenarbeit über GitHub-Repositories einlädt.

• Debugger for Java
• Java Debug Server für Visual Studio Code

Wenn bei der Verwendung der unten aufgeführten Funktionen Probleme auftreten, können Sie uns kontaktieren, indem Sie ein Problem melden.

Installation

Um die vollständige Java-Sprachunterstützung in Visual Studio Code zu erhalten, können Sie das Extension Pack for Java installieren, das die Debugger for Java-Erweiterung enthält.

Extension Pack for Java installieren

Einzelheiten zum Einstieg in das Extension Pack finden Sie im Tutorial Erste Schritte mit Java.

Konfigurieren

Standardmäßig ist der Debugger sofort einsatzbereit, indem er automatisch die Hauptklasse findet und eine Standard-Startkonfiguration im Arbeitsspeicher generiert, um Ihre Anwendung zu starten.

Wenn Sie Ihre Startkonfiguration anpassen und dauerhaft speichern möchten, können Sie den Link create a launch.json file in der Ansicht Ausführen und Debuggen auswählen.

Die Datei launch.json befindet sich in einem .vscode-Ordner in Ihrem Arbeitsbereich (Projektstammordner).

Weitere Einzelheiten zum Erstellen der launch.json finden Sie unter Startkonfigurationen; weitere Details zu Konfigurationsoptionen für Java finden Sie unter Konfigurationsoptionen.

Ausführen und Debuggen

Die Debugger-Erweiterung bietet mehrere Möglichkeiten, Ihre Java-Anwendung auszuführen und zu debuggen.

Ausführen über CodeLens

Sie finden Run|Debug in der CodeLens Ihrer main()-Funktion.

Ausführen über das Editor-Menü

Eine weitere Möglichkeit, das Debugging zu starten, ist die Auswahl des Menüs Run Java oder Debug Java in der oberen Titelleiste des Editors.

Ausführen durch Drücken von F5

Wenn Sie F5 drücken, sucht der Debugger automatisch nach dem Einstiegspunkt Ihres Projekts und startet den Debugging-Vorgang. Sie können eine Debugging-Sitzung auch über die Ansicht Ausführen und Debuggen in der Seitenleiste von VS Code starten. Weitere Informationen finden Sie unter Debuggen in VS Code.

Einzelne Dateien debuggen

Neben der Unterstützung für das Debuggen von Java-Projekten, die von Build-Tools verwaltet werden, unterstützt VS Code auch das Debuggen einzelner Java-Dateien ohne ein Projekt.

Eingaben für Debug-Sitzungen

Die Standard-Debug-Konsole in VS Code unterstützt keine Eingaben. Wenn Ihr Programm Eingaben über ein Terminal benötigt, können Sie das Integrierte Terminal (⌃` (Windows, Linux Ctrl+`)) innerhalb von VS Code oder ein externes Terminal verwenden, um es zu starten. Sie können auch die Benutzereinstellung java.debug.settings.console verwenden, um eine globale Konsole für alle Java-Debug-Sitzungen zu konfigurieren.

Haltepunkte

Der Debugger for Java unterstützt verschiedene Breakpoints, wie Zeilen-Breakpoints, bedingte Breakpoints, Daten-Breakpoints und Logpoints.

Breakpoint - Bedingter Breakpoint

Mithilfe der Ausdrucksauswertung unterstützt der Debugger auch bedingte Breakpoints. Sie können Ihren Breakpoint so einstellen, dass er anhält, wenn der Ausdruck zu „true“ ausgewertet wird.

Breakpoint - Daten-Breakpoint

Sie können den Debugger anhalten lassen, wenn eine Variable ihren Wert ändert. Beachten Sie, dass der Daten-Breakpoint nur innerhalb einer Debug-Sitzung gesetzt werden kann. Das bedeutet, Sie müssen Ihre Anwendung starten und zuerst an einem regulären Breakpoint anhalten. Danach können Sie ein Feld in der Ansicht VARIABLEN auswählen und einen Daten-Breakpoint setzen.

Breakpoint - Logpoints

Logpoints werden ebenfalls vom Java-Debugger unterstützt. Mit Logpoints können Sie Ausgaben an die Debug-Konsole senden, ohne den Code zu bearbeiten. Sie unterscheiden sich von Breakpoints dadurch, dass sie den Ausführungsfluss Ihrer Anwendung nicht unterbrechen.

Breakpoint - Getriggerte Breakpoints

Ein ausgelöster Haltepunkt ist ein Haltepunkt, der automatisch aktiviert wird, sobald ein anderer Haltepunkt getroffen wird. Sie können sehr nützlich sein, um Fehlerfälle im Code zu diagnostizieren, die nur nach einer bestimmten Vorbedingung auftreten.

Ausgelöste Haltepunkte können durch Rechtsklick auf den Glyph-Rand gesetzt werden, indem Ausgelösten Haltepunkt hinzufügen ausgewählt und dann gewählt wird, welcher andere Haltepunkt den Haltepunkt aktiviert.

Auswertung von Ausdrücken

Der Debugger ermöglicht es Ihnen außerdem, Ausdrücke im ÜBERWACHUNG-Fenster sowie in der Debug-Konsole auszuwerten.

Hot Code Replace

Ein weiteres fortgeschrittenes Feature, das der Debugger unterstützt, ist der "Hot Code"-Austausch. Hot Code Replace (HCR) ist eine Debugging-Technik, bei der der Debugger for Java Klassenänderungen über den Debugging-Kanal an eine andere Java Virtual Machine (JVM) überträgt. HCR erleichtert die experimentelle Entwicklung und fördert iteratives Trial-and-Error-Programmieren. Mit dieser neuen Funktion können Sie eine Debug-Sitzung starten und eine Java-Datei in Ihrer Entwicklungsumgebung ändern; der Debugger ersetzt daraufhin den Code in der laufenden JVM. Ein Neustart ist nicht erforderlich, weshalb es als "hot" bezeichnet wird. Nachfolgend sehen Sie eine Darstellung, wie Sie HCR mit dem Debugger for Java in VS Code verwenden können.

Sie können die Debug-Einstellung java.debug.settings.hotCodeReplace verwenden, um das Auslösen von Hot Code Replace zu steuern. Die möglichen Einstellungs-Werte sind:

• manual - Klicken Sie auf die Symbolleiste, um die Änderungen anzuwenden (Standard).
• auto - Änderungen automatisch nach der Kompilierung anwenden.
• never - Hot Code Replace deaktivieren.

Step-Filtering

Step-Filtering wird von der Erweiterung unterstützt, um Typen herauszufiltern, die Sie beim Debuggen nicht sehen oder durchlaufen möchten. Mit dieser Funktion können Sie in Ihrer launch.json konfigurieren, welche Pakete gefiltert werden sollen, damit sie beim Durchlaufen übersprungen werden.

Konfigurationsoptionen

Es gibt viele Optionen und Einstellungen, um den Debugger zu konfigurieren. Beispielsweise lässt sich das Konfigurieren von JVM-Argumenten und Umgebungsvariablen einfach über Startoptionen bewerkstelligen.

Konsultieren Sie die Dokumentation der Erweiterung Language Support for Java™ by Red Hat für Hilfe bei der Einrichtung Ihres Projekts.

Für viele häufig verwendete Setups gibt es Beispiele unter VS Code Java Debugger Configuration. Das Dokument erklärt, wie der Java-Debugger automatisch Konfigurationen für Sie erstellt, und falls Sie diese ändern müssen, wie Sie dies mit der Hauptklasse, verschiedenen Argumenten, Umgebungsvariablen, dem Anhängen an andere Java-Prozesse und der Nutzung fortgeschrittener Funktionen tun.

Nachfolgend sind alle für Launch (Starten) und Attach (Anhängen) verfügbaren Konfigurationen aufgeführt. Weitere Informationen zum Schreiben der launch.json-Datei finden Sie unter Debuggen.

Launch (Starten)

• mainClass (erforderlich) - Der vollqualifizierte Klassenname (z. B. [java modulname/]com.xyz.MainApp) oder der Pfad zur Java-Datei des Programmeinstiegs.
• args - Die an das Programm übergebenen Befehlszeilenargumente. Verwenden Sie "${command:SpecifyProgramArgs}", um zur Eingabe von Programmargumenten aufzufordern. Es akzeptiert einen String oder ein Array von Strings.
• sourcePaths - Die zusätzlichen Quellverzeichnisse des Programms. Der Debugger sucht standardmäßig in den Projekteinstellungen nach Quellcode. Diese Option erlaubt es dem Debugger, in zusätzlichen Verzeichnissen nach Quellcode zu suchen.
• modulePaths - Die Modulpfade für den Start der JVM. Falls nicht angegeben, löst der Debugger diese automatisch aus dem aktuellen Projekt auf.
  • $Auto - Automatische Auflösung der Modulpfade des aktuellen Projekts.
  • $Runtime - Die Modulpfade innerhalb des 'runtime'-Scopes des aktuellen Projekts.
  • $Test - Die Modulpfade innerhalb des 'test'-Scopes des aktuellen Projekts.
  • !/path/to/exclude - Den angegebenen Pfad von den Modulpfaden ausschließen.
  • /path/to/append - Den angegebenen Pfad an die Modulpfade anhängen.
• classPaths - Die Klassenpfade für den Start der JVM. Falls nicht angegeben, löst der Debugger diese automatisch aus dem aktuellen Projekt auf.
  • $Auto - Automatische Auflösung der Klassenpfade des aktuellen Projekts.
  • $Runtime - Die Klassenpfade innerhalb des 'runtime'-Scopes des aktuellen Projekts.
  • $Test - Die Klassenpfade innerhalb des 'test'-Scopes des aktuellen Projekts.
  • !/path/to/exclude - Den angegebenen Pfad von den Klassenpfaden ausschließen.
  • /path/to/append - Den angegebenen Pfad an die Klassenpfade anhängen.
• encoding - Die file.encoding-Einstellung für die JVM. Falls nicht angegeben, wird 'UTF-8' verwendet. Mögliche Werte finden Sie unter Unterstützte Kodierungen.
• vmArgs - Die zusätzlichen Optionen und Systemeigenschaften für die JVM (z. B. -Xms<size> -Xmx<size> -D<name>=<value>), akzeptiert einen String oder ein Array von Strings.
• projectName - Das bevorzugte Projekt, in dem der Debugger nach Klassen sucht. Es kann doppelte Klassennamen in verschiedenen Projekten geben. Diese Einstellung funktioniert auch, wenn der Debugger beim Starten eines Programms nach der angegebenen Hauptklasse sucht. Sie ist erforderlich, wenn der Arbeitsbereich mehrere Java-Projekte enthält, andernfalls funktionieren die Ausdrucksauswertung und bedingte Breakpoints möglicherweise nicht.
• cwd - Das Arbeitsverzeichnis des Programms. Standardmäßig ${workspaceFolder}.
• env - Die zusätzlichen Umgebungsvariablen für das Programm.
• envFile - Absoluter Pfad zu einer Datei, die Definitionen von Umgebungsvariablen enthält.
• stopOnEntry - Das Programm nach dem Start automatisch pausieren.
• console - Die angegebene Konsole zum Starten des Programms. Falls nicht angegeben, wird die Konsole verwendet, die in der Benutzereinstellung java.debug.settings.console festgelegt wurde.
  • internalConsole - VS Code Debug-Konsole (Eingabestream nicht unterstützt).
  • integratedTerminal - Integriertes VS Code-Terminal.
  • externalTerminal - Externes Terminal, das in den Benutzereinstellungen konfiguriert werden kann.
• shortenCommandLine - Wenn das Projekt einen langen Klassenpfad oder große VM-Argumente hat, kann die Befehlszeile zum Starten des Programms die vom Betriebssystem zugelassene maximale Länge überschreiten. Dieser Konfigurationspunkt bietet mehrere Ansätze zur Verkürzung der Befehlszeile. Standardmäßig auto.
  • none - Programm mit der Standard-Befehlszeile 'java {options} classname {args}' starten.
  • jarmanifest - Klassenpfad-Parameter in eine temporäre classpath.jar-Datei generieren und das Programm mit der Befehlszeile 'java -cp classpath.jar classname {args}' starten.
  • argfile - Klassenpfad-Parameter in eine temporäre Argument-Datei generieren und das Programm mit der Befehlszeile 'java @argfile {args}' starten. Dieser Wert gilt nur für Java 9 und höher.
  • auto - Die Länge der Befehlszeile automatisch erkennen und entscheiden, ob die Befehlszeile über einen geeigneten Ansatz verkürzt werden soll.
• stepFilters - Angegebene Klassen oder Methoden beim Durchlaufen (Stepping) überspringen.
  • classNameFilters - [Veraltet - ersetzt durch skipClasses] Die angegebenen Klassen beim Durchlaufen überspringen. Klassennamen sollten voll qualifiziert sein. Platzhalter werden unterstützt.
  • skipClasses - Die angegebenen Klassen beim Durchlaufen überspringen. Sie können integrierte Variablen wie '$JDK' und '$Libraries' verwenden, um eine Gruppe von Klassen zu überspringen, oder einen spezifischen Klassennamen-Ausdruck hinzufügen, z. B. java.*, *.Foo.
  • skipSynthetics - Synthetische Methoden beim Durchlaufen überspringen.
  • skipStaticInitializers - Statische Initialisierungsmethoden beim Durchlaufen überspringen.
  • skipConstructors - Konstruktormethoden beim Durchlaufen überspringen.

Anfügen

• hostName (erforderlich) - Der Hostname oder die IP-Adresse des Remote-Debuggees.
• port (erforderlich) - Der Debug-Port des Remote-Debuggees.
• processId - Den Prozess-Auswähler verwenden, um einen Prozess zum Anhängen auszuwählen, oder Prozess-ID als Ganzzahl.
  • ${command:PickJavaProcess} - Den Prozess-Auswähler verwenden, um einen Prozess zum Anhängen auszuwählen.
  • Eine Ganzzahl PID - An den angegebenen lokalen Prozess anhängen.
• timeout - Timeout-Wert vor dem Wiederverbinden, in Millisekunden (Standard 30000 ms).
• sourcePaths - Die zusätzlichen Quellverzeichnisse des Programms. Der Debugger sucht standardmäßig in den Projekteinstellungen nach Quellcode. Diese Option erlaubt es dem Debugger, in zusätzlichen Verzeichnissen nach Quellcode zu suchen.
• projectName - Das bevorzugte Projekt, in dem der Debugger nach Klassen sucht. Es kann doppelte Klassennamen in verschiedenen Projekten geben. Diese Einstellung ist erforderlich, wenn der Arbeitsbereich mehrere Java-Projekte enthält, andernfalls funktionieren die Ausdrucksauswertung und bedingte Breakpoints möglicherweise nicht.
• stepFilters - Angegebene Klassen oder Methoden beim Durchlaufen (Stepping) überspringen.
  • classNameFilters - [Veraltet - ersetzt durch skipClasses] Die angegebenen Klassen beim Durchlaufen überspringen. Klassennamen sollten voll qualifiziert sein. Platzhalter werden unterstützt.
  • skipClasses - Die angegebenen Klassen beim Durchlaufen überspringen. Sie können integrierte Variablen wie '$JDK' und '$Libraries' verwenden, um eine Gruppe von Klassen zu überspringen, oder einen spezifischen Klassennamen-Ausdruck hinzufügen, z. B. java.*, *.Foo.
  • skipSynthetics - Synthetische Methoden beim Durchlaufen überspringen.
  • skipStaticInitializers - Statische Initialisierungsmethoden beim Durchlaufen überspringen.
  • skipConstructors - Konstruktormethoden beim Durchlaufen überspringen.

Benutzereinstellungen

• java.debug.logLevel: Mindeststufe der Debugger-Protokolle, die an VS Code gesendet werden, Standard warn.
• java.debug.settings.showHex: Zahlen im Hex-Format unter Variablen anzeigen, Standard false.
• java.debug.settings.showStaticVariables: Statische Variablen unter Variablen anzeigen, Standard false.
• java.debug.settings.showQualifiedNames: Vollqualifizierte Klassennamen unter Variablen anzeigen, Standard false.
• java.debug.settings.showLogicalStructure: Die logische Struktur für Collection- und Map-Klassen unter Variablen anzeigen, Standard true.
• java.debug.settings.showToString: Den 'toString()'-Wert für alle Klassen, die die 'toString'-Methode überschreiben, unter Variablen anzeigen, Standard true.
• java.debug.settings.maxStringLength: Die maximale Länge von Strings, die unter Variablen oder in der Debug-Konsole angezeigt werden. Längere Strings werden gekürzt. Standard ist 0, was bedeutet, dass kein Kürzen durchgeführt wird.
• java.debug.settings.hotCodeReplace: Geänderte Java-Klassen während des Debuggens neu laden, Standard manual. Stellen Sie sicher, dass java.autobuild.enabled für die Java Language Support-Erweiterung nicht deaktiviert ist. Siehe die Hot Code Replace-Wiki-Seite für weitere Informationen zu Nutzung und Einschränkungen.
• manual - Klicken Sie auf die Symbolleiste, um die Änderungen anzuwenden.
• auto - Änderungen automatisch nach der Kompilierung anwenden.
• never - Änderungen niemals anwenden.