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.

[aclement]

@benkiefer Did you try remote debugging as mentioned above? "Setting up remote debug completely fixes the problem for me."

[benkiefer]

Yes sir. It does work, but I'm working on several boot microservices at the same time. I'd need a remote debug config for all of them, which gets a bit noisy. Multirun at least makes it manageable.

[cjemison]

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

[dwelch2344]

+1 to this on IntelliJ 14.1. Forked process route still cannot access breakpoints on reloaded classes (whether launched in run or debug mode w/ custom agentlib declaration)

[MaximeGaudin]

+1 For IntelliJ 14.1.2 (141.713)

[cunhaax]

Forget all IDEs, springloaded is really messing up with debug, it doesn't matter which IDE you are using... I just tried to debug using the JVM standard debugger JDB (http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jdb.html), and after I did a file touch on a class to trigger loading (notice that I didn't even recompiled the code, just changed .class access/modified time), I could no longer see the debugger stopping at my breakpoint. I'm working on linux 64bit running java 1.8.0_45 and tomcat 7.0.55. Any news/work around on this issue?

EDIT I did one more test with JDB.. At JDB promt, the output of "class" command of a freshly started jvm is like this:

class my.package.MyJavaClass Class: my.package.MyJavaClass extends: java.lang.Object

when I recompile the first time, the breakpoints stop working and the output is like:

class my.package.MyJavaClass Class: my.package.MyJavaClass extends: java.lang.Object nested: my.package.MyJavaClass$$DPDoXWlc nested: my.package.MyJavaClass$$EPDoXWlc

recompiled a second time:

class my.package.MyJavaClass Class: my.package.MyJavaClass extends: java.lang.Object nested: my.package.MyJavaClass$$DPDoXWlc nested: my.package.MyJavaClass$$DPDoXWlc nested: my.package.MyJavaClass$$DPDoXjm4 nested: my.package.MyJavaClass$$EPDoXWlc nested: my.package.MyJavaClass$$EPDoXWlc nested: my.package.MyJavaClass$$EPDoXjm4

(increasing number of nested classes) @aclement ...any ideas on where might be the problem?

[guaido79]

+1 For IntelliJ 14.1.4

[TLN2]

I can confirm that remote debugging does NOT help on NetBeans 8.0.2. I voted for the bug in their Bugzilla: https://netbeans.org/bugzilla/show_bug.cgi?id=250626

However, I'm not sure it's their job to fix it. Given the behavior that Spring Loaded creates a new class with a new name each time it is reloaded I understand that a normal Java debugger can't be expected to work here out of the box. I guess it would be better to create a renamed class, convert all instances to that class, then unload the original, re-load it from the latest .class file, and convert all instances again.

[jtulach]

I found springloaded very useful in context of DukeScript: https://dukescript.com/best/practices/2015/04/12/no-redeploys.html - but yeah, the breakpoints in NetBeans really don't work after reload.

[evgenycherny]

2 year later - the issue is still there, at least with IntelliJ

[AbdullahG]

I could not debug a spring boot application when I run with maven plugin. SHIT !