Java Debugger/en
| Language: | Deutsch • English |
|---|
Introduction
The Java Debugger plugin provides basic Java debugging facility. It allows for debugging of Groovy blocks and any other Java code run in remote JVM directly within expecco.
The plugin provides a way to place breakpoints into a Java or Groovy code. When breakpoint hits (particular location in the code is reached), the program is stopped and a visual debugger appear. The debugger then can be used to inspect the state of the execution and/or single-step through the code.
Groovy Block Debugger
expecco has a built-in debugger for Groovy blocks. It is part of expecco itself; neither the Java Debugger plugin nor its license is needed. It talks directly to the JVM of the Java bridge (via its debug port) and works with the Groovy version the bridge uses (Groovy 4 and 5). The sections after this one describe the Java Debugger plugin, which is still needed for debugging plain Java code.
Line Breakpoints
- To set a breakpoint, click left of the line number in the Groovy block editor; a red circle marks it. Click it again to remove it. The debugger attaches to the bridge automatically.
- When the line is reached, the debugger window opens. While it is stopped, the whole JVM of the bridge is suspended.
- Breakpoints work in the block's code, in closures, and in classes, traits and records defined in the block.
- A breakpoint on a line without executable code (e.g. an empty line or a method header) is marked with a warning icon once the block's code has been loaded, and a warning is written to the Transcript. A line inside a closure is only checked after the closure has been created for the first time.
- "Breakpoints..." in the context menu of the Groovy code editor opens a list of all breakpoints. Breakpoints can be removed there, and exception breakpoints added or changed.
Stepping
- The debugger offers Continue, Next (line step), Into (into a called method or closure), Out (until the current method returns) and Abort.
- The execution stack shows the block's methods and closures; frames of the Groovy runtime and of the JDK are hidden.
- Abort (or closing the debugger window) throws a java.lang.RuntimeException: aborted in the debugger in the stopped thread; the action then fails with this exception.
Variables and Objects
- The variable list shows the local variables of the selected frame, including variables captured by a closure, and this (shown in the receiver inspector).
- Collections show their elements ([apple, banana, cherry]), maps their entries, objects of classes defined in the block their fields (Item(name:apple, price:1.25, qty:1)), records like Point[x=3, y=6]. Enum constants, GStrings (as text), BigDecimal/BigInteger (as numbers) and the values of the block's input and output pins are shown as well.
- A double-click opens an inspector on a value; nested collections and objects can be opened from there. At most 100 elements of a collection are shown.
- The values are read without running code in the JVM (no toString() calls), so looking at variables never changes the program state.
Evaluating Code
- Select Groovy code in the debugger's source view or in the workspace of the variable inspector and use doIt, printIt or inspectIt. The code is evaluated in the selected frame: its local variables, the methods and fields of this and the classes defined in the block can be used.
- At a stop caused by an exception breakpoint, the variable exception holds the exception.
- Errors (an exception thrown by the code, a compilation error) are shown in a dialog.
- The code runs in the stopped thread; the other threads stay suspended. Breakpoints are not hit during an evaluation.
Changing Values
- Select a variable in the variable inspector, enter a Groovy expression in the value pane and accept it: the variable is set to the expression's value. For primitive variables (int, long, double ...) the value must fit the type.
- In an inspector on an object, fields of objects, elements of arrays and lists and the values of map entries can be changed the same way. Groovy converts the value to the field's type.
- Values which cannot be modified are rejected with an error message: immutable collections (e.g. the result of toList() or List.of()), the fields of records, enum constants and this.
Exception Breakpoints
- "Break on Exception..." in the context menu of the Groovy code editor asks for an exception class (default java.lang.Throwable, i.e. any exception; a selected class name in the code is taken as default) and when to stop: "when it is caught in the block" and/or "when it leaves the block (not caught there)". Unchecking both removes the exception breakpoint.
- The bridge catches every exception of a Groovy block, so "uncaught" means: not caught by the block's own code. Exceptions which the Groovy runtime throws and catches internally never stop.
- At the stop, the debugger shows the frame of the block's code in which the exception occurred, and the variable exception with the exception's class and message.
Limitations
- Only the stopped thread is shown (there is no thread list), and there is no "run to line".
- While the debugger is stopped, the JVM of the bridge is suspended - this also affects other actions using the same bridge.
- Collections are displayed by reading the internal fields of the common JDK collection classes; other collection classes are shown as plain objects with their type name.
Debugger
The overall layout of Java debugger window is similar to debuggers for Smalltalk and JavaScript blocks. It consists of 5 panes:
1 Execution Stack - organized top-to-bottom, i.e., the currently executing method is the first entry in the list.
2 Source Code View - shows the source code of the currently selected method (in execution stack pane). Source for particular method may or may not be available. For details refer to section Managing Sources
3 this object inspector - an embedded inspector of this objects, i.e., on the receiver of the method.
4 Method parameters and locals inspector - an embedded inspector showing all method parameters and local variables which are visible at current scope.
5 Thread List - list showing all threads in the remote JVM. The Execution Stack pane shows execution stack of selected thread.
Following debugging operations are available:
- Continue - resumes execution until remote JVM terminates or another breakpoint is reached.
- Abort - aborts execution of currently executing expecco Groovy block. If the selected thread does not execute a Groovy block abortion is not allowed.
- Next - aka Step-over. Single-step to next line in currently selected method. Does not enter into called methods.
- Next - aka Step-into. Single-step to next line in currently selected method or into a called method.
- Out - aka Step-out. Run until currently selected method returns and stop's at the method's caller.
Breakpoints
Java Debugger plugin supports two kinds of breakpoints:
- Line Breakpoints - a traditional breakpoint set on particular line in particular method.
- Exception Breakpoints - a breakpoint that suspends execution when an exception of specified type is thrown.
Line Breakpoints
A line breakpoint could be placed to a Groovy block or to any other Java code. When a line breakpoint is hit whole JVM is suspended, i.e., all running Java threads are suspended.
To put a breakpoint in a Groovy block, just click in Groovy block editor left to the line number. The line breakpoint is indicated by a little red circle icon. To remove a breakpoint, just click on the breakpoint icon again.
To put a breakpoint in any other Java code, open a Java browser window, navigate to desired class and method and click left the line number.
Exception Breakpoints
An exception breakpoint hits when an exception of given type (or it's subtype) is thrown, i.e., at the point just before Java throw statement is executed. This is useful when an exception is thrown and possibly caught and re-thrown again to find out the original cause and debug there.
Exception breakpoints could be configured to trigger in two cases:
- For caught exceptions - the breakpoint will hit (program will be suspended) if an exception is thrown and would be caught by some handler deeper in the execution stack. Note, that any finally or synchronized block creates an implicit exception handler for type java.lang.Throwable.
- For uncaught exception - the breakpoin will hit only if an exception is thrown but it is not handled by any handler, i.e., it is unhandled.
Warning: The JVM cannot always reliably tell whether a given exception is actually caught or uncaught. For details, refer to JDI documentation
Object Inspector
TBW...
Managing Sources
Java Debugger plugin uses Java Browser/en fro accessing source code. The source code for particular class / method is looked up in Java Browser's default workspace. This means that if the default workspace does not contain a source code for the class, Java debugger will not show source code. However, it is still possible to inspect parameters and other local variables and even single-step.
If the sources does not match the sources which the Java code has been compiled from, Java debugger may show invalid source code or line numbers may not match. There is no way to validate the sources matches the code loaded in remote JVM.
For more information about default workspace and how to add classes and sources to it, please refer Java Browser plugin documentation
Limitations
The current version of JDebugger has some limitations:
- A line breakpoint cannot be placed to a nested classes, i.e., to inner classes and to anonymous classes. Note, that UI event handlers, such as button click handlers, are usually implemented using anonymous classes.
- A breakpoint cannot be placed on a class which is loaded more than once in remote JVM.
These limitations will be addressed in a future versions.