Community
Participate
Working Groups
Up to the latest Eclipse 3.1.1 hot code replacement never worked during debugging. I just browsed Eclipses help "tips & tricks" and it says: "The debugger supports Hot Code Replace when debugging with a 1.4 or higher VM, or the J9 VM. This lets you make changes to code you are currently debugging. Note that some changes such as new or deleted methods, class variables or inner classes cannot be hot swapped, depending on the support provided by a particular VM." I use JDK 1.5.0_05 (it also never worked with former versions) and just try to insert e.g. a simple String test = "hello"; in a method that I debug, but it never shows up in the variables view or a System out also doesn't get printed during debug. I find it also strange that although I set my breakpoints in the Java source files, the debugger stops in the class file. So, as I can't find a preferences switch to "enable" hot code replacement, I wonder if this ever works?
The is a feature that eclipse developers use everyday. What is the exact scenario that is failing for you? What is the error message when it fails?
Also note that you have to have autobuild turned on for HCR to work. HCR is triggered after a build changes a class file that is active in the VM being debugged.
Here is some a solution (hack) to this problem by a jboss guy : http://www.jboss.com/?module=bb&op=viewtopic&t=65783 Would be nice not to have to do this kind of things..
Not sure that comment#3 is the problem that MH is seeing. It also sounds like there is another configuration problem, as the debugger stops in classfiles rather than source files. Are there multiple copies of your classfiles in the workspace? are they packaged as a jar or run from the folder of classfiles? where does the project build path point? how are your building/compiling your project?
(In reply to comment #4) > Not sure that comment#3 is the problem that MH is seeing. Ok, his problem may come from misconfiguration. But mine, not ;-) (well, I don't think) I get exactly what is described in the url I gave. Could we discuss this point here, or is it better to open another issue (But the issue title seems appropriate) ?
Please open a differnt bug report - although you are having trouble with hot swap, I believe the cause is different.
Marking as remind, without further input from reporter.
(In reply to comment #2) > Also note that you have to have autobuild turned on for HCR to work. HCR is > triggered after a build changes a class file that is active in the VM being > debugged. Uh? I didn't read that anywhere! I switched off autobuild because it slows down Eclipse too much too often. Now, that I turned autobuild on, and change the code during debugging, right when I save the changes, the debugger performs a "Drop to Frame" (jumps to the beginning of method) and the changes take effect! :-) So, is this "Drop to Frame" result usual for Hot code replacement?
Closing. Yes, the drop to frame is expected when you change code that is on the stack. We automatically drop methods that have changed, as they become obsolete. You have to have autobuild on to compile the new methods/changes.
Okay. Just 2 notes: it would be nice to have this requirement (switch on autobuild) somewhere in the online help for the search words "hot code replacement". And: another reason we switch off autobuild is, that we also heavily use ANT scripts that are called within Eclipse. And many of the targets also trigger compilation of the source. With autobuild on, this leads to hundreds of errors (red cross markers) in the project whenever such an ANT target is executed ... and this leads to forced "clean" whenever the application is to be started within Eclipse. Without autobuild we can execute the ANT targets and savely also can start the Eclipse projects (run as application) without being forced to do a clean before. It would be nice to have at least an option to automatically switch on autobuild when starting in debug mode (and automatically switch it off again, when debugging session ends). Is this possible?
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
