June 28, 2011 4 Comments
It has been some time since I wrote last installment of this series – and much happened in the meantime. IDEA 10.5 was released (with full support of JDK 7) – and the whole beast is again a bit faster and better – though not without bugs. I’ll probably write a dedicated monologue about things I don’t like in IDEA and why. Then, very recently, Eclipse Indigo was released as well (without Java SE 7 language level support, not that it is make/break feature). One thing I’m very interested in about it is Xtext 2.0, which now seems to be the most driven DSL solution if you want to write text based grammars, models, whatever. (Aside from Xtext, I’m even more interested in MPS by JetBrains, but MPS as of now is a bit rugged if you expect the same fluency as with IDEA.)
This gives me opportunity to recheck some features I collected in previous months and haven’t published yet, though I don’t expect some big improvements in Eclipse core features (not sure why, but when I think about it like this, big blue logo always appears somewhere in my mind – I’m not sure how much IBM is to be blamed, really).
One big thing I don’t like about Eclipse is SVN integration – and I honestly don’t know how can anyone compare and criticize SVN in IDEA. While I don’t know about Synchronization feature in IDEA, truth is I never needed it! IDEA’s workflow is more in line with SVN – especially when it comes to adding files to the repository (before you actually commit them).
Another and probably more important thing is merging. In IDEA I’ve never been afraid of version conflicts – at least not technically. Conflict should be about decision making, but with Eclipse it’s a real nightmare instead. Most Eclipse users don’t know what 3-way diff is, there is no way how I can see my version, after-merge version (the result) and incoming version on one screen. This way you can always compare your code with the resulting code, you can move changes from your code to the result, etc. In Eclipse you can only change your code directly – and hardly see the differences in the end. I often close Eclipse and start Idea on the same project just to resolve conflicts and do commits.
Also files that can be merged perfectly are reported as in-conflict, because two (or more) people were working on them – this is ridiculous! Eclipse is confusing reporting conflicts, it’s also confusing about files added locally to repository. You have little control over it as new file is again and again suggested as an outgoing change (so you are forced to use SVN ignore, information that is stored in repository, to solve Eclipse’s own problems) – instead of you being in control and deciding whether the file is in revision control or not. You can add it, but there is no difference.
Let’s compare some refactorings, completion and shortcuts again!
You can easily do basic refactorings on classes in IDEA – shortcuts are familiar from Norton/TotalCommander (F5 copy, Shift+F5 clone, F6 move, Shift+F6 rename). This works consistently whether you are in editor with cursor on the class name or in the project tree. In Eclipse you have to go to the project tree and do it there. Clone/copy is Ctrl+C and Ctrl+V, not sure if that is refactoring. F2 in Eclipse works in project tree, on the class name in the editor you have to use Alt+Shift+R.
Ctrl+Space is the same, but in Eclipse many other features are bound to the same “completion” functionality while in IDEA you have the following: Ctrl+O (override), Ctrl+I (implements), Alt+Insert (toString, setters/getters – but if you want more than just one of them use Alt+S, R in Eclipse rather than Ctrl+Space – or bind it to your key somehow) – and of course also IDEA’s smart completion Ctrl+Shift+Space. Here – while it may seem stupid to have so many keys in IDEA for every different thing I never had problem with that (because you always know what to do). Also the lists are more focused for various functions while in Eclipse it’s all in one list. The rest is probably just the matter of taste. However, smart completion (Ctrl+Shift+Space) from Idea works much better for me than Eclipse’s all-embracing completion. Not to mention Eclipse doesn’t offer enum value completion in method parameters or equals as IDEA naturally does.
Class name completion in non-java files – IDEA is far superior compared to virtually no completion in (for instance) XML files in Eclipse (may vary in Java EE version).
God/Devil is in the details when it comes to how to accept the completion. In Idea you can press Tab or Enter. The difference is when you “overwrite” some existing code, identifier, value, whatever. Tab is natural for us, Idea crowd, and it replaces the previous stuff. I made the test, check this animated GIF – funny that Enter behavior differs with and without smart completion (Ctrl+Space vs. Ctrl+Shift+Space) – but as it’s mostly not what you want, it doesn’t really matter, right? Eclipse behavior is different when finishing enum and the class (animated GIF, in 3rd case it does what it should, ignore the syntax error) – to simplify things one can say that Ctrl+Enter is always what you want (probably). Many users may not know about the difference or haven’t thought about it, but it indeed is a difference. Here “know your IDE” is the most important thing – then you can get what you want quickly in both.
Eclipse’s Ctrl+Space has one additional feature – when you press it repeatedly it cycles through a few filtered views (Template Proposals, SWT Template Proposals, JPA Proposals) – this can be further customized in Preferences/Java/Editor/Content Assist/Advanced.
Don’t miss other posts on this topic:
Eclipse vs IntelliJ IDEA
From IntelliJ IDEA to Eclipse (2)
Why to synchronize with SVN in Eclipse?
From IntelliJ IDEA to Eclipse (3)
From IntelliJ IDEA to Eclipse (4)