This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 152153 [details] Hg repository with sample matematika application It maybe necessarily bug in debugger, but something in co-operation between NetBeans debugger and springloaded[1] is not working as well as it should. Probably easier to workaround that on NetBeans side than deal with spring guys... $ mkdir mat $ cd mat $ hg init $ hg unbundle matematika.hg $ hg up -C default $ mvn clean install -DskipTests $ netbeans.exe client # open client project in NetBeans put breakpoint to DataModel.java line 33. Debug the project. Solve one equitation and press Test button (in case the screen goes black, resize, its bug 236961). Once the Test button is pressed, the breakpoint@33 is hit. Continue. Now trigger the springloaded functionality. Go to DataModel.java line 60 and change it for example to res = Integer.parseInt(result) - 5; save. In the application try to solve another equitation. If the modified code is active (e.g. correct solution needs to be higher by five), press Test button: The breakpoint on line 33 is ignored. [1] https://github.com/spring-projects/spring-loaded
The problem is likely related to the fact that springloaded creates new classes on background. For example my old cz.xelfi.math.DataModel is replaced by cz.xelfi.math.DataModel$$DP56mUYq in my case and the new class probably does not have the breakpoint set.
Then it's probably not fixable on NetBeans side without knowing what exactly springloader does... In the past, Hanz submitted breakpoints to all classes named cz.xelfi.math.DataModel* if the appropriate location was found. This would fix this. But this required query to all loaded classes, which is slow. We know the appropriate classes from Java, therefore we do not need the query. We would probably need some provider to ElementUtilities.getBinaryName(), that would be able to return cz.xelfi.math.DataModel$$DP56mUYq.
First issue is to decide whether springloaded is on or not. That could probably be done by detecting its Agent class being available and/or checking the the parameters to the virtual machine. The second issue is how to emit breakpoint. Here we would need to understand more what springloaded does. I don't have much of such insight yet.
Here is my (naive) plan how to address the second issue: As soon as we know springloaded is active, the debugger starts to listen on class redefinition and whenever ExistingClass$$HASH1234 is defined, it checks its SourceFile attribute - it seems to me the source points back the old ExistingClass.java and the line numbers are exactly as at the time of save - e.g. it would be possible to re-submit the line breakpoints from the ExistingClass.java to the new Existing$$HASH1234 class. As far as I can say the re-defined classes have all methods static and if necessary they use "thiz" argument - ultimately debugger could provide a view to fix the names, but it is really low priority issue compared to ability to stop on line breakpoints. Btw. exception breakpoints work fine and my findings are based on inspection of stack frames when in a redefined class I throw exception which hits the breakpoint.
If you can listen on class redefinition, then calling LineBreakpoint.setPreferredClassName() should re-submit the breakpoint for the new class. Then it depends on the correct debugging info in these classes. Hope that helps.
As there hasn't been any activity on this issue for a while: Is this solved? Is there a workaround? I'm experiencing the same problem and I can't find out what to do. Actually Spring Loaded is intended to remove the need for redeployments, but if reloaded classes don't work in the debugger, you still have to redeploy rather often. Some people report that the issue has been solved for them by switching to remote debugging (http://stackoverflow.com/questions/25353602/breakpoints-does-not-work-after-reloading-classes-with-springloaded-in-intellij), but this didn't help for me here. Perhaps this solution only works in IntelliJ. It would be okay for me as a workaround if I had to press a button in NetBeans to trigger whatever is necessary to make debugging work again after a class has been reloaded (NetBeans wouldn't have to detect Spring Loaded on its own). Thanks.
I had no time to play with this issue and/or push Martin (owner of debugger) to bring it forward. So for 8.1 FCS, this issue will not be solved. But thanks for your comment, it helps to know I am not the only one who has the problem.
Well, after thinking about it I'm coming to believe it's not NetBean's responsibility to detect Spring Loaded and adapt to it, but Spring Loaded should rather make sure that class names remain intact as a reasonable debugger expects them to be. It is possible somehow, I tested JRebel in the meantime, and it works with NetBeans. I also read somewhere that even the command line debugger shipped with each JDK doesn't work with current versions of Spring Loaded. That being a truth, *IF* the NetBeans team could make NetBeans compatible with Spring Loaded through some minor adjustments that wouldn't have side effects for anyone else, then I'd wolcome it if they could do so. PS: I also left a comment here 3 days ago: https://github.com/spring-projects/spring-loaded/issues/67