Thanks for the info, Maciej!I didn't know NB had an "Apply Changes." Last time I investigated this problem with NB (back in 2022), I posted my problems to this group. Either NB didn't have that ability back then, or no one told me about it. I'm not completely sure how to even try it now because of the multiple sourceroot issue.
In terms of getting dynamic microservices to work with Tomcat, I had no idea it would be a problem under Tomcat. I just built what made sense, tried it, and it worked.It has been and is being used in several commercial apps for probably about five years. One app, in particular, is quite large (9,000 Java classes) and works perfectly with about 1,000 users. I've never had a problem. I guess I accidentally did it the right way. I do not compile on save. The source file just sits there.It gets recompiled at runtime only under the sum of both conditions: 1. The service is being called 2. The source file has changed or never been loaded If it isn't being used, it never gets loaded. Once it gets compiled and loaded (far less than a second), I keep it in memory and reuse it rather than recompiling it. There is no redeploy. My code knows if it is in development mode or production mode. In development mode, it just picks up the file from your source directory, so nothing needs to be copied, compiled, deployed, or anything. The same in production mode, except it gets the file from the production directories. Since Kiss <https://kissweb.org> is open-source, you can see exactly what I am doing. Thanks. Blake On Sun, Sep 21, 2025 at 7:16 AM Maciej Jaros <[email protected]> wrote: > 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 >> >> >> >
