Viewing Loaded Classes

See Also

The Classes view shows the class loaders and all of the classes that each class loader has loaded into the debuggee. The list of classes are shown in sorted order by name within their respective packages. The packages are shown in tree form to ease navigation within the list of classes.

The view updates its contents when ever the session is suspended, whether by hitting a breakpoint, or if the Pause action is invoked. To cause the view to refresh while the debuggee is running, simply invoke the Refresh item in the view context menu.

Finding Classes

Because the classes in this view are organized by class loader, it can sometimes be a daunting task to locate a particular class. This is made easy by the Find feature. Simply select the Classes view (i.e. give it the focus) and the Find item in the Edit main menu will enable (likewise, the toolbar button also enables). Invoking this action will display a find bar at the bottom of the classes view. Simply type in the name of a class, unqualified, and click the Next or Previous buttons to find matching classes. Each result will be expanded and selected in the tree, making it easy to find the one you are looking for.

Trace Methods

By selecting a class and invoking the Trace Methods item in the node context menu, a trace breakpoint will be created. It will be filtered by the name of the class and indicate every time when any method in that class is entered or exited. The output will be in the debugger console (in the Output window).

Fix and Continue (hotswap)

This view offers a hotswap function to replace the bytecode of a class without having to restart the debuggee. This attempts to locate the .class file for the corresponding class in the classpath of the debuggee. This means the Java code that you want to fix should be compiled prior to invoking this operation. This requires that the class is available to the debugger on the file system, as it cannot be retrieved over the network.

Breakpoints in a redefined class will be invalidated for the remainder of the active session. As a work-around, disable and re-enable the breakpoints.

From the JDI documentation

This function does not cause any initialization except that which would occur under the customary JVM semantics. In other words, redefining a class does not cause its initializers to be run. The values of preexisting static variables will remain as they were prior to the call. However, completely uninitialized (new) static variables will be assigned their default value.

If a redefined class has instances then all those instances will have the fields defined by the redefined class at the completion of the call. Preexisting fields will retain their previous values. Any new fields will have their default values; no instance initializers or constructors are run.

If a method that gets modified by a redefineClasses operation has current activations, those activations will continue to execute the old version of the method. New calls will get the new version of the method. In this case, all information about the old version of the method (eg, its local variables, line numbers, ...) is lost and cannot be recovered by the JDI client. All operations that return information about the method will return information about the new version of the method. Breakpoints that are set in the method will be set in the new version, not the old version.

Some JVMs do not offer unrestricted class redefinition. Restricted class redefinition disallows the following:

See Also


Legal Notices