alt Hacker News> it was the worst debugging experience one could have.
Hard disagree. I'm not going to argue that Java debugging was the best, however:
1. You could remote debug your code as it ran on the server.
2. You could debug code which wouldn't even compile, as long as your execution path stayed within the clean code.
3. You could then fix a section of the broken code and continue, and the debugger would backtrack and execute the code you just patched in during your debugging session.†
This is what I remember as someone who spent decades (since Java 1.0) working as a contract consultant, mainly on server side Java.
Of course this will not convince anyone who is determined to remain skeptical, but I think those are compelling capabilities.
† Now I code in Rust a lot, and I really enjoy it, but the long compile times and the inability to run broken code are two things which I really miss from those Java days. And often the modern 2025 debugger for it is unable to inspect some for the variables for some reason, a bug which I never encountered with Java.
Replies
About your †, I think that new Rust tooling like dx will eventually enable hot patching code during debugging
https://lib.rs/crates/subsecond
(Note, it was created by Dioxus, but it's usable in any Rust project)
> 2. You could debug code which wouldn't even compile, as long as your execution path stayed within the clean code.
In Java? How?
That's how I felt at the time, it was my first job and I only had better experiences since then (and I gave it a try again in 2019 and the experience was way, way better). You're right, it probably wasn't the worst of the era, it will still be inferior than any experience a dev would have in 2025.
For the 1: not really applicable in my case. For 2: I didn't know this. For 3: yes, but it worked only for a subset of issues, and honestly much more usable with Clojure and Scala.
I primarily worked with Hadoop and ETLs, you probably won't be able to convince me to be fair.