Hacker News Reader

Comment by legerdemain | Hacker News Reader

I can say one thing in favor of Eclipse. Out of the box, it would show you compile errors across your whole Java project, so you could do interface refactors and method renames fearlessly.

In Intellij, for years and years and years and years and years, and possibly even still, you had to enable a changing and unpredictable set of options to get the same set of behavior, maybe. You'd try to find the most recently edited answer in this question[1] and hope that it worked. Note how one of the upvoted suggestions is "use the Eclipse compiler instead."

So yeah, switching to Intellij killed off like 30% of what made Java development bearable for me.

[1] https://stackoverflow.com/questions/19364949/how-to-view-the...

View on HN

As an IntelliJ user since 2003 I've heard this comment from Eclipse users multiple times, and always been puzzled about it. I think there is an IntelliJ "problems view" or something like it.. but in my entire career I don't think I ever looked for it. I could run a build whenever I wanted to find out if things were broken in some way. When it came to refactoring, renames, etc, I felt empowered with IntelliJ to safely do those with their refactoring tools in way which Eclipse was a very slow follower.

I suspect there are two components to the Eclipse vs IntelliJ bias in folks. 1st is which IDE they used first, and like every editor war, this is all about habit and finding that the workflow you built around one tool doesn't fit another, and then the second is about which phase you adopted the tool in. IntelliJ was so far ahead of Eclipse in terms of pure usability and delightful advanced completion and refactoring features in the early days, but eventually Eclipse - and other IDEs which will not be named - took inspiration from Jetbrains innovation to narrow the gap.

You can ask IntelliJ to analyze your code and then it will tell you the places where a method could be static, for example. As far as I know the Java compiler doesn’t warn about this. So building the project will not tell you.

Eclipse has a “problems” view which shows you all these kinds of problems across your whole workspace, all the time. I find that to be very nice: you configure Eclipse to show you the kinds of warnings you care about. Then you get a list of places to fix. And you can make sure that the list is empty at all times.

In IntelliJ you have to start analysis, and the CPU fan spins up and it takes some minutes. And then the list of problems goes away after a while and you have to rerun analysis.

In IntelliJ I make do with the annotations in the file I’m currently editing. IntelliJ also has smarter warnings than Eclipse does. But still, the problems view is very nice and I miss it.

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.

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.

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.

I thank InteliJ for making me love Eclipse again.

Reply on news.ycombinator.com