On 29/04/2026 09:37, David Alayachew wrote:
Hello @[email protected]
<mailto:[email protected]>,
Today, I managed to debug a pretty ugly CVE with one of our services,
and was forced to use jdb because of restrictions on the environment.
It was fairly straightforward, but tedious in many ways. I understand
that jdb is better served as an ingredient in a larger tool (which is
how most IDE's do it), but every now and then, you get forced down to
it if a system is locked down enough.
Would it make sense to have a simple GUI that exposes only the most
basic parts of JDB? Similar to EditPad for JShell, where you can type
/edit if the cli ends up making things uglier than it needs to.
* It would be super low effort to implement and maintain in the JDK.
EditPad
<https://github.com/openjdk/jdk/blob/master/src/jdk.editpad/share/classes/jdk/editpad/EditPad.java>
is
in the JDK, and it is less than 150 lines of basic boilerplate
code. I foresee a JDB implementation being less than 300. Happy to
produce a prototype if anyone wants.
* It smooths out several rough points of JDB.
o Linking sources is repetitive and tedious. A simple
JFileChooser would simplify that greatly.
o Being able to see help in a separate JDialog/JOptionPane would
make the UI less cluttered.
o Placing breakpoints/traces/watches is nice when you are
actually looking at the code itself too in a separate text area.
o Reduces the tunnel vision feeling of only being able to see
one thing at one time in JDB. Each thing we want to support
can be its own dialog.
Let me know if it makes sense.
FWIW, the original JPDA effort in the late 90s included a prototype GUI
debugger named "javadt" (Debug Tool). It was included as a JDK sample
along with "jdb".
I don't see a compelling case for adding a graphical debugger to the JDK
in 2026. There is a JDWP socket transport on all platforms and most/all
of the IDEs support remote debugging. I don't agree that it would be a
"super low effort" because such as tool is going to attract feature
requests and grow legs. There are also topics such as accessibility and
automated tests that would like require a lot of work. So while it
might be fun to create this debugger then maybe it would be better to
work on this in your own project?
BTW: The question as to whether to deprecate the jdb tool comes up
periodically. It used by a lot of tests for JDI and the debugger
architecture so it would be disruptive to remove it. Some people have
also made the case that it's useful to have something when you need to
ssh into a remote system.
-Alan
