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.
When using JavaRebel it is possible to change source code, compile and have the container reload the changed class. When debugging JavaRebel enabled applications in NetBeans the annotations (different colored lines to indicate where is the current cursor in debug session) get messed up. I've pinpointed the problem to /debugger.jpda.projects/src/org/netbeans/modules/debugger/jpda/projects/EditorContextImpl.java around line 294. The offending line is: Line l = LineTranslations.getTranslations().getLine ( url, lineNumber, (timeStamp instanceof JPDABreakpoint) ? null : timeStamp ); The timeStamp gets too old as an instance of JPDADebugger is given as a timestamp but the change to the source code has been made during the debug session so the timeStamp is old. I'll attach a simple patch.
Created attachment 63949 [details] EditorContextImpl Diff - I did mess up the imports
can we please have this evaluated applies in 6.7 timeframe? with javarebel 2.0 having support for maven projects, we can expect users to make use of javarebel more frequently. Thanks.
I think this is already outdated as our binary releases of the nb debugger jars have not been working with later versions of NB but I think the ideas behind the patch apply. See also http://www.netbeans.org/issues/show_bug.cgi?id=139047
Sorry, but I will NOT apply this patch. The time stamps are there for a reason. This would break debugging of application that do not update the binary class files. Debugger would have to be somehow notified that the classes were changed. Can that be made somehow? It's strange not to use debugger's "Apply Code Changes", which work correctly with the time stamps. Unfortunately I believe that JavaRebel's update of classes work much better that the almost unusable implementation of "Apply Code Changes" in Sun's JDK. If you can provide some notification, I can clear the time stamp based on that notification.
FYI: this and issue #139047 needs much more analysis than just this. E.g.: 1) What happens with breakpoints submitted to original classes when new classes are loaded? Probably JPDADebuggerImpl.fixBreakpoints() needs to be called. 2) What happens with the code execution in the replaced methods? Are there old obsolete methods around like when VirtualMachine.redefineClasses() is called? Is execution popped off the affected stack frames? 3) Possible interferention with debugger objects needs to be checked - are JDI objects like ReferenceType, Location, etc. updated? How debugger state is affected when class are reloaded while some threads are suspended by debugger? ...
JR can't notify the debugger of a change but when adding breakpoints we can add the breakpoint to all versions of a class and as program flow will go though only one of them it won't be a problem. Can the timestamps be made smarter in a sense that they will update themselves while debugging when src & class happen to change on disk meanwhile?
@toomasr: IMHO this issue is obsolete!? I read a slide from zt months ago, that is was fixed in 7.2?