Haven't tested your code, but in NB you can "Apply Code Changes". This
works for reloading the body of any function in Java/JVM. It works when
a project is opened in NB (specific module) and the project is run in
debug mode in NB (e.g., deployed to Tomcat). Reloading method bodies
even worked in Tomcat 7 and JDK7 (both via NB and IJ). It's not
automatic, you have to click the "Apply Code Changes" button.
But… AFAIK Tomcat doesn't support reloading whole classes (adding or
removing methods). So that's a Tomcat limitation, not an NB thing. If
you managed to make that work in your JVM/server, that actually sounds
quite interesting. I tried, but I wasn't able to make class reloading
work in Tomcat via IJ either. I last tried IJ in 2023, so that might
have changed, but back then I added a method to a class, reloaded code,
and IJ crashed the server. So it seems NB detects that the JVM cannot
handle adding a method, while IJ just tries anyway and breaks (or at
least it did in 2023).
There is an option to compile on save and to re-deploy on save, but that
is slow and heavy for big apps so YMMV. Re-deploy might also break
session, so that is not great for dev-testing either. I guess that
"deploy on save" would work for micro-services (I did use that with some
success for a small-ish SpringBoot project).
Regards,
Maciej Nux.
Blake McBride (2025-09-19 20:25):
I presume that this ability is somewhat new since NetBeans of 2022
could not handle changing classes. I spent a bunch of time with it, as
well as on this group on that matter, in 2022.
(I can't test it now because I am having trouble indicating multiple
source roots to NetBeans.)
Thanks.
Blake
On Fri, Sep 19, 2025 at 1:12 PM Laszlo Kishalmi
<[email protected]> wrote:
NetBeans works well in those use cases, just needs to be aware of
the project structure, so when a change is detected in the class
it can reload that for the debugger.
On 9/19/25 07:57, Blake McBride wrote:
Greetings,
Some time ago, I reported the fact that the Java debugger in
NetBeans cannot debug dynamically changing code.
(My Kiss <https://kissweb.org> system uses a microservice
architecture that recompiles files at runtime if they change.
NetBeans cannot debug classes that have changed, meaning you
can't develop while the system is running - a chief benefit of
the system.)
I wanted to see if, years later, the problem was fixed, but I ran
into other problems (multiple source roots).
At the time (years ago), I was looking for commercial support to
fix that problem. Being unable to find a reasonable solution, I
just dropped the whole matter. I realized two things:
1. The IntelliJ Java debugger works correctly. (It is the only one.)
2. IntelliJ has an open-source version that has all of the
correct code for its debugger to handle dynamically changing code.
So, if there is interest in fixing the problem, the code is in
the open-source release of IntelliJ.
Thanks.
Blake
