unable to break into re-loaded class code

[smoothello]

Hi,

I'm working on a win7 64bit box, JDK 7.0.40.
I'm unable to make breakpoints work for classes re-loaded through spring-loaded java-agent. I've tried Netbeans and IntellJ without success (any newly added code will work, it's just that I can't break into it)

1. Is this functionality not yet implemented in spring-loaded OR is it a bug OR am I doing something wrong ?
   A simple way to reproduce this problem is to use the sample code provided by the link below:
   http://www.leveluplunch.com/java/tutorials/004-hot-deploy-java-applications-with-spring-loaded/
   (the code itself is here: https://github.com/leveluplunch/004-hotdeploy-java-applications-with-spring-loaded )

Thank you very much in advance for your feedback.

Regards

Karl

[neesonqk]

Same issue here(tested intellij 13.1.3 and netbeans 8.0), once reloaded class code breakpoint doesn't work.

[aclement]

Last time I tried it, it worked. That was in Eclipse. I don't have any regression tests for the process though, so it did possibly break down. Can you try eclipse?

[smoothello]

I just tried Eclipse (STS to be exact) and it did in fact work ! (in the sense that I'm able to break into the new code) ...I then retried one more time with Netbeans and IntellJ (with exactly the same sample project -see my email above-) but I failed once again to break into the code on those two platforms...
I would be interested to know if anyone managed to make it work for one of those IDEs ?

Regards

Karl

[aclement]

I'd like to hear from someone else confirming it doesn't work in those tools. If that is true then I suspect I know what has to be done to enable it. There is an extra attribute we could set in the classfiles.

[smoothello]

Hi Andi,
To give you more information about this issue, please note that even in Eclipse I'm getting a warning about the IDE being unable to install the breakpoint because of "Absent Line Number Info" (please refer to screenshot below), but if I ignore this warning, I'm still able to break into the code (of course if I use javap -v OR javap -l, I can see that the line number info does exist in the modified class code, and yes, my compiler option in the IDE is properly set to generate debug info). In Netbeans and IntellJ, the situation is different: The IDE simply refuses to put a breakpoint in the reloaded code.

[mschorsch]

Hi,
Does Not work with netbeans. Tested with with netbeans 7.4 and different jdks.

[aclement]

I actually tried it on netbeans, yep, doesn't behave nicely at all. Behaves better in Eclipse with the one gotcha I noticed that after setting a breakpoint you need to trigger a reload (I was just making a whitespace change to the file and saving it) in order to be able to stop at that new breakpoint.

I committed some changes to address the dialog you show above, I made those dispatch methods synthetic.

[smoothello]

The warning message in Eclipse is now indeed gone when using the latest snapshot, but the situation seems to be unchanged as far as Netbeans an IntellJ are concerned. Do you any short-term plan to make Spring-Loaded compatible with Netbeans' debugger ? (I guess that since JRebel managed to make it work with Netbeans's debugger, there's nothing fundamentally broken with that IDE, but that doesn't imply that it will be easy either).
Thank you very much in advance for your feedback.
Regards
Karl

[mschorsch]

I have tested the latest snapshot. Unfortunately, it is not possible to set a breakpoint in netbeans after the source code has been changed. This project is so great, please try to fix the bug. Thank you very much in advance.

[corycomer]

Just adding another confirmation, tested latest snapshot with Intellij 13.1.3, could not break on re-loaded classes.

[NoUsername]

Is there any update on this? Any workarounds maybe?

Just tested it with the latest 1.2.2 Version (springloaded-1.2.2.BUILD-20141008.215157-2) and can confirm that the issue still exists there (tested with IntelliJ Idea 13.1.4)

[aclement]

No updates at the moment. I thought I read someone had gotten it to behave if they ran the app as a forked process and then attached to it via the remote debugging capability in eclipse (rather than the more usual direct debugging). But I haven't had a chance to try that myself.

[gillius]

I can confirm that IntelliJ 14 release candidate also has this problem. Setting up remote debug completely fixes the problem for me. To do that in IntelliJ you create a remote debug configuration, and IntelliJ will give you the JVM argument to add (by default -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005). Add that argument to your run configuration and start run configuration and remote debug and IntelliJ works like a normal debug.

Credits: I found this post before this issue http://stackoverflow.com/questions/25353602/breakpoints-does-not-work-after-reloading-classes-with-springloaded-in-intellij, which is what gave me the workaround.

I've also tried IntelliJ with DCEVM and JRebel, and in both of those cases, IntelliJ debugger works perfectly. The problem is that our org decided to drop JRebel subscription, and DCEVM works flawlessly with Java code but cannot reload Groovy code most of the time -- the metaclasses and/or callsites are not getting updated, despite everyone saying that it should work and I'm also using IDEA's Groovy hotswap agent. That's how I came to try out SpringLoaded, and it works to reload my Groovy 2.3.7 code just fine. The only issue I've found so far is this debugger issue.

[benkiefer]

Any update on this issue? I'm still seeing the issue in Intellij 14.