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. Thank you for your time and consideration. David Alayachew
