[m34]

Not sure how properly implemented refactoring would lead to compile errors that were not there before (maybe due to some Spring configurations or @Annotations not being considered?)

My usual pain point with eclipse was mostly package refactoring always leading to tree conflicts with SVN repos.

But that was ages ago and back then using Idea was way ahead of eclipse wrt refactoring and overall developer experience/productivity for us.

[legerdemain]

I'm sure Intellij is very nice with refactors that just push code around. Renaming or extracting a method in an automated way should obviously maintain working state.

But I'm not religious about TDD. I might try different ways to modularize the same code or sketch out several different interfaces or service stubs. This is not something that you can automate.

And when I'm done laying out the major pieces, the problems view in Eclipse helps me climb out of the sea of red that I've created by pointing out where I need to wire up methods together, or think more about type signatures, or whatever.

Tangentially, this is why we chose Dagger over Guice for dependency injection in Java. Dagger generates the wiring code at compile time, so you get all the niceties of static type checking in plain view, right away.

[m34]

Thanks for the clarification. I understand it's more about "exploratory" refactoring.

Thinking further I might have silently adopted a self-imposed "keep track of edit states and memoization in the wetware stack" approach, which I realize now is something that is far more exhausting than offloading to the tools whose purpose it is to show where the missing bits are.