Hello @Alan Bateman <[email protected]>, Ty vm for the response.
That's fair. I can see how this is more effort than I am communicating. But let me be the loudest voice in the room to say that under no circumstances should we deprecate jdb. Lol, it saved my project weeks of approval time to get a tunnel opened up to the instance (assuming it would even get approved). And considering this is a government environment? lol, it's less painful to pull your own teeth than to try and get anything non-standard approved, and their definition of non-standard is archaic. JDB needs to stay, else people in positions like mine will suffer. Even if it is in a feature freeze state, that's fine. But ty vm, I accept that a graphical wrapper isn't the write move for the JDK. I'll keep it as a personal utility for me and my team. On Wed, Apr 29, 2026 at 9:18 AM Alan Bateman <[email protected]> wrote: > > > On 29/04/2026 09:37, David Alayachew wrote: > > Hello @[email protected] <[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. > - Linking sources is repetitive and tedious. A simple JFileChooser > would simplify that greatly. > - Being able to see help in a separate JDialog/JOptionPane would > make the UI less cluttered. > - Placing breakpoints/traces/watches is nice when you are actually > looking at the code itself too in a separate text area. > - 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 > >
