Debugging lombok in Eclipse is acting strangely

[caleb.johnson]

Hi, I'm trying to debug some custom annotations in lombok, and I can get onto the break point in my custom handler but then the debugger "times out" or something between 1 - 5 seconds and it always goes to the first line of TransformEclipseAST.transform() even though I have no breakpoint set there. This makes debugging nearly impossible. I've tried setting Eclipse's Java debug options to have a 30 second debugger timeout and to suspend the VM (not just the thread) on break points but that hasn't made a difference, and no other project I've used in Eclipse has done this, so I suspect it may have something to do with this project in particular. Has anyone run into this issue before?

Regards,
Caleb

[Roel Spilker]

Hi Caleb,

We've sometimes observed the same behavior. To get some data points:

- What OS are you using?

- what version and edition of Eclipse are you using?

- When does the breakpoint trigger? On save, autocomplete, refactor, opening java file, etc.

Roel

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Reinier Zwitserloot]

Our theory is that eclipse notices that the class file, as it is in the JVM process memory, is not an exact match to the class file as eclipse finds it on disk, and uses / tries to use hotswap to reload the class.

Lombok is an agent and 'rewrites' the class as it is loaded. Eclipse reloading it simply means our agent will see it _again_ and will _again_ rewrite it, causing an endless loop, because the next time eclipse scans that class file, it notices a mismatch and we start this song and dance routine all over.

We're not actually sure if this is it, we should probably check if our live class rewriting gets fired continually (I think we checked this and the conclusion was: Yes, it is). That means the next fix would be to try and rewrite the class files 'statically' on disk, or to try and disable eclipse's hot replace feature.

 --Reinier Zwitserloot

[caleb.johnson]

OS: Mac OS 10.9.5
Eclipse: Luna Service Release 1 (4.4.1)
From within Lombok-ized Eclipse, breakpoint hits on file load, on save, and on edit (without save)

The Java Handler I can get to okay because the tests I write that run under TestWithDelombok hit the break point, but tests run under TestWithEcj don't hit the breakpoints in the Eclipse Handler (even though they seem to use the code from it) so I was trying to do it via LombokizedEclipse in debug mode but ran into this issue. Are TestWithEcj tests supposed to hit the breakpoint in the Eclipse handlers?

Thanks,
Caleb

[Reinier Zwitserloot]

They are supposed to work, and I think they do, although generally when we test eclipse, we actually fire a complete eclipse in debug mode from within the main eclipse, and breakpoints definitely work there, although if you step into any class file that we patched, wonky stuff starts happening and the stack view starts blinking every 5 seconds or so.

 --Reinier Zwitserloot