@equals... and useful debug messages

[Mark Goldthorp]

auto-generated equals is nice for promoting stability of product, but it'd be nice if it could be made to debug-out just before it returns false.

I ask because I am testing stuff that uses plump objects (loadsa fields) and when they fail the equals test, I have to do some manual comparison to find out the offending inequality - not hard work, but...

I suppose the sticky bit comes when the components of the object have components?

[Reinier Zwitserloot]

This is a feature for IDEs, not lombok. Good news though. They already implemented it (At least, eclipse did. Which means VSCode, which uses eclipse under the hood for this stuff, at least has the feature, perhaps not the UI to enable it. I do not know if IntelliJ does, but probably!)

Here's how to do this in eclipse. If you are in the 'debug' perspective all these views I speak of are open by default.

* Open the outline view. This is a generalized go-to answer for anything 'how do I do IDE method-level feature stuff when the method doesn't exist?? Ordinarily I'd right click somewhere on the declaration of that method and do this stuff but this only half works if I attempt to right click the lombok annotation, and stuff like `@Value` makes many methods, help!' - just go to the outline view, all generated methods are there, right click from there. So, right click the `equals` method.

* Select 'toggle method breakpoint'.

* Now in the breakpoint view, you see the method level breakpoint. In its properties you can choose to breakpoint on entry or on exit. Tick 'exit' and you're now quite a ways towards what you desire.

Of course, breakpointing inside lombok is always a bit tricky, IDEs have a prevailing abstraction of 'debugging is line based', and this is fundamentally broken and leaky once you dig deep enough: Actually, breakpointing is a thing you do to bytecode, and the link between bytecode and java source line numbers is tenuous at best. In practice, 'debugging is line based' works great and the failure of the abstraction is rarely relevant. But with lombok it is, and thus, wanting to 'fix' this is tantamount to asking IDEs to completely chuck their debug UI and core code and start from scratch, now building with less of a 'line number based!' mindset. Basically as long as its line based, 'step 1' generally means 'next line', and with lombok, that means 'skip over everything', probably not what you wanted.

This isn't lombok specific. For example, if you `switch` on a string, javac generates a ton of code: The string is hashed, the hash is actually switched on, and the cases do some equality checks, all injected code. You can't breakpoint those either. You should treat lombok code the same way.

For what its worth, if truly you insist lombok should do this, it's so incredibly complicated (basically involves making entirely new API inside the debug infra of major IDEs), that we're never going to get around to writing it, and we wouldn't even accept a PR, as such a beast would be far too large a maintenance burden. The only PR we could accept in light of our duties to maintain it, is one written by the IDE dev team itself.

I do have an easy alternative: If there is a specific equals method of some specific type that you want to investigate further, just.. breakpoint the equals method of that. You can breakpoint entry/exit of methods you don't have the source code for in the same fashion (from outline views and the like). Or, write a method with the same name as the field, stick a `@EqualsAndHashCode.Include` on that, and now lombok will call that method to derive the value instead of just checking the field (or just make a getter, same result), now you can breakpoint that, do your debug work, and once you're done, delete this method again.

[Mark Goldthorp]

Thank you, Reinier, for coming back to me.

I did not explain myself well. Basically, I was trying to offload work onto someone else. If someone else could be persuaded to load-up their code, then I would not have to fire-up an IDE. 

I can dimly (I am not a dev, as you can probably guess) see the problem, so thank you, anyway, for telling me more about it.