The current version of
NetBeans Debugger shows all static /
private / ... fields for variables in
Watches & Variables tabs. It
is useful when you want to find some details
of implementation, but it
can be uncomfortable for many other
purposes. For example if I am inspecting
an instance of java.util.Vector, I
probably want to see its
content not its serialVersionUID,
capacityIncrement etc.
Where it
can be used:
primitive
filters: filter variables according
its "static / public
/ private ... / generated by compiler /
null" features
hierarchy
filters:
Collections
filter: displays
"important" children and
properties for
Vectors,
Hashtables ... only. For
example it can
display <key, value> as
children of Hashtable, and
"size" as property
if it.
Component filter: can be
useful if we want to focus on a
hierarchy of
java.awt.Components
Object
filter: designed to show
dependencies of objects (for example
objects from some package) only.
Values of primitive types can be
shown as
properties.
Beans filter:
This feature should be
useful for debugging non-java languages too.
For some languages compiled to Java
(JSP) may be useful to hide (or
rename, represent in the different way) some
Java variables (generated
variables). Such a module should redefine
the default filter of Java debugger.
-
Debugger Window is too small, mainly
for browsing variables.
- There is no good support for
watching more than one debugger
views (Debugger
Window's tab).
- Separate PropertySheet on
each debugger view.
- PropertySheet does not
display such important information
to take 1/2 of
Debugger Window.
- We will need some toolbar for
variables view.
It is a good
idea to logically organize breakpoints in
the case of large projects. Grouped
in a group, they can be enabled, disabled,
or removed as a single unit.
A group can be visually implemented by a
node in the Debugger Window, tab
Breakpoints. Descendant nodes should
represent all breakpoints (eventually
sub-groups) belonging to the group.
We plan to add a special
glyph to the editor window for debugger.
It could:
contain
information if some bytecode is
produced for this line. It means
that this line can be a current line
of debugger and some breakpoint can
be added on it.
allow to add
breakpoints quickly (click on
glyph)
contain info if some stack trace of
some thread currently contains this
line. It also can display state of
this thread (like thread waits on
this line...)
allow to
traverse (up, down) stack trace
quickly (click on some up, down
icons)
It could be useful to have a
new view (tab in the Debugger
Window) which provides quick evaluation
(execution) of expressions. Value
of expression written to some input line
will be displayed similar to value
of watches in watches tab of Debugger Window
(in tree of variables).
We have "Global
Options/Debugger Settings/Workspace"
property which defines which
workspace should be used for debugging (when
debugging starts IDE
switches to it). But we do not returns to
the previous workspace after
debugger finish.
Configurable Format
of Display Text for Watches (Daniel
Prusa): Format of display
text for watched variables can be
configurable. The user could chose what
information about variables he/she
prefers (name, type, toString() value,
value - in case of primitive type, hash
code, identity hash code, internal
id, etc.) and in what format it should
be displayed.
Predefined watch name (Jan Stola):
When I place a caret
on some variable definition and try to
create a new breakpoint
the name of this variable is offered to
me (so, I can easily create my
variable breakpoint). I think it would
be nice to have the same support
for watches.
Enable to call some
method on variable selected in
Watches tab
Displaying Integral
Values in Various Formats (Daniel
Prusa): We support displaying
integral values in the decimal format
only. The ability of displaying integral
values in the hexadecimal, octal and
binary format can be added. Every
variable can have property
"Format" with the default
value "decimal". Format
can be specified in Add Watch dialog:
i,x (means watch on variable x +
display it in hexadecimal).
Better support for watching two
(and more) dimensional arrays (10490).
Add Breakpoint on Line / Method
/... to Explorer: We plan to add
"Add Breakpoint on Line / Method /
..." everywhere it is possible.
Explorer Nodes of Java DO, editor's
popup menu,
editor's margin etc.
Creation of exception
breakpoints from Classes tab (10103).
Creation of variable
breakpoints from Classes tab (10102).
Add some debugger related actions to
the Tools Actions:
"Go to
Breakpoint" to the
editor's popup on the
breakpoint line, which
transfers focus to the Debugger
Window / Breakpoints tab and selects
proper
breakpoint.
"Go to Thread" to the
editor's popup on the current
line, which transfers
focus to the Debugger Window /
Threads tab and expands &
selects proper
thread.
Write different reports when method
vs. constructor is reached (11133).
Property editor for
Print text property of breakpoints
(Jan Stola): It would
be nice to have property editors for
print text properties of
breakpoints. In the
present situation the user don't
know which substitutions could
he/she use, e.g. {lineNumber},
{className} etc.
Info dialog could
appear when user put breakpoint into
white line.
Disabled breakpoints
could have different icon (Svatopluk Dedic)
Use dialog boxes for
breakpoint notification (Kurt
Westerfeld): Current version
of NetBeans Debugger uses output window
for breakpoint event notifications.
We could add some "Pop-up
dialog" option as an breakpoint
action (like "Print
text" option - see properties of
breakpoint).
There should be
access/modification variable
breakpoint. (Jan Stola)
Ability to change code while
debugging (recovery from the changes
and ability to continue in code processing
after it was changed). This
feature significantly improves the
effectiveness of writing and debugging
code.
