Eclipse 5 years later – common formatter quest

It was 5 years ago when I compared IntelliJ IDEA and Eclipse IDE in a series of blog posts (links to all installments at the bottom of that post). I needed to migrate from IDEA to Eclipse, tried it for couple of months and then found out that I actually can go on with IDEA. More than that, couple of years later many other developers used IDEA – some in its free Community edition, others invested into the Ultimate (comparison here).

Today I have different needs – I just want to “develop” formatter for our project that would conform to what we already use in IDEA. I don’t know about any automatic solution. So I’ll install Eclipse, tune its formatter until reformat of the sources produces no differences in my local version of the project and then I’ll just add that formatter into the project for convenience of our Eclipse developers.

Importing Maven project in Eclipse

I went to their download page, downloaded, started the executable and followed the wizard. There were no surprises here, Eclipse Mars.2 started. With File/Import… I imported our Maven project – sure that wizard is overwhelming with all the options, but I handled. Eclipse went on with installing some Maven plugin support. This is unknown for IDEA users – but it’s more a problem of Maven model that doesn’t offer everything for IDE integration, especially when it comes to plugins. It also means that plugins without additional helper for Eclipse are still not properly supported anyway. In any case, it means that Eclipse will invade your POM with some org.eclipse.m2e plugins. Is it bad? Maybe not, Gradle builds also tend to support IDEs explicitly.

Eclipse definitely needed to restart after this step (but you can say no).

SVN support

We use Subversion to manage our sources. I remembered that this was not built-in – and it still is not. Eclipse still has this universal platform feeling, I’m surprised it knows Java and Maven out of the box.

But let’s say Subversion is not that essential. I wasn’t sure how to add this – so I googled. Subversive is the plugin you may try. How do I install it? Help/Install New Software… does the trick. I don’t know why it does not offer some reasonable default in Work with input – this chooses the software repository which is not clear to me at all from that “work with”. I chose an URL ending with releases/mars, typed “subv…” in the next filter field and – waited without any spinner or other notification.

Eventually it indeed found some Subversive plugin…s – many of them actually. I chose Subversive SVN Team Provider, which was the right thing to do. Confirm, OK, license, you know the drill… restart.

But this still does not give you any SVN options, I don’t remember how IDEA detects SVN on the project and just offers it, but I definitely don’t remember any of torturing like this. Let’s try Subversive documentation – I have no problem reading. Or watching Getting started video linked therein. 🙂

And here we go – perspectives! I wonder how other IDEs can do it without reshuffling your whole screen. Whatever, Eclipse == perspectives, let’s live with it. But why should I add repository when the URL to it is already somewhere in the .svn directory in the root of the project? Switching to SVN Repository Exploring perspective, Eclipse asked for SVN connector. Oh, so much flexibility. Let’s use SVN Kit 1.8.11, ok, ok, license, ok. Restart again? No, not this time, let’s wait until it installs more and do it at once. This was wrong decision this time.

I followed the video to add the SVN repository, but it failed not having the connector. Were I not writing this as I go, I’d probably remember I have installed one. 🙂 But I wasn’t sure, maybe I cancelled it, so let’s try SVN Kit, sounds good. It failed with “See error log for details.” Ok, I give up, let’s try Native JavaHL 1.8.14 (also by Polarion). This one works. Restart needed. Oh, … this time I rather really restarted as my mistake dawned on me.

I checked the list of installed software, but SVN plugins don’t seem to be there – this is rather confusing. But if you go to Windows/Preferences, in the tree choose Team/SVN, then tab SVN Connector – there you can find the connectors you can use. Sure I had both of them there. My fault, happy ending.

So I added SVN repository, but as the Getting started video went on, I knew I’m in trouble. It doesn’t say how to associate existing SVN project on my disk with a repo. I found the answer (stackoverflow of course). Where should I right click so that Team menu shows enabled Share project…? In Package explorer of course. I added one project, hooray! Now it shows SVN information next to it. But I noticed there is Share projects…, I don’t want to do it one by one, right? Especially when Eclipse does not show the projects in the natural directory structure (this sucks). I selected it all my projects but Team menu didn’t offer any Share at all now!

Ok, this would throw me out of balance at 20, but now I know that what can go wrong goes wrong. That only project associated with SVN already – I had to deselect to let Eclipse understand what I want. Strictly speaking there is some logic in eliminating that menu item, but as a user I think otherwise. So now we are SVN ready after all!

I updated the project (not using other perspective), no information whether it did something or not – IDEA shows you updated files without getting into your way. Should have used synchronize, I know…

Oh, and it’s lunch time, perfect – I really need a break.

Quick Diff

This one is for free with IDEA, with Eclipse we have to turn it on. It’s that thing showing you changes in a sidebar (or gutter).

Windows/Preferences, filter for “quick” and there you see it under General/Editors/Text Editors. Well it says enabled, but you want to check Show differences in overview ruler too. In my case I want to change colours to IDEA-ish yellow/green/red. (Who came with these Sun/enterprise violetish colours for everything in Eclipse?) What to use as reference source? Well, with IDEA there is no sense for “version on disk” option. I chose SVN Working Copy Base in hope it does what I think it does (shows my actual outgoing changes that are to be committed).

Outgoing changes contain unmanaged files!

Ah yeah, I recall something like this. This is the most stupid aspect of SVN integration – it does not respect how SVN work. After seeing my outgoing changes in Team Synchronizing perspective (probably my least favourite and most confusing one for me) I was really afraid to click on Team/Commit… But as the three dots indicate, there is one more dialog before any damage is done – and only managed files are checked by default. So commit looks good, but disrespect of outgoing changes to the SVN underlying principles is terrible. Eclipse users will tell you to add files to ignore, but that is just workaround – you can then see in the repository all the files people needed to ignore for the sake of stupid team synchronization. Just don’t auto-add unmanaged files, show some respect!

Eclipse Code Style options

With quick diff ready I can finally start tuning my formatter. There are some good news and some bad news. Well, these are no news actually, nothing has changed since 2011. Code Style in IDEA is something you can set up for many languages in IDEA. It also includes imports. In Eclipse when you filter for “format” in Preferences you see Formatter under Java/Code Style and more options for XML/XML Files/Editor. These are completely separated parts and you cannot save them as one bunch. For Imports you have Java/Code Style/Organize Imports.

In my case it doesn’t make sense to use project specific settings. What I change now will become workspace specific, which is OK with me – but only because I don’t want to use Eclipse for any other projects with different settings (that would probably either kill me or I’d have to put them into separate workspaces).

And then we have Java/Code Style/Clean Up configuration (this is what Source/) and Java/Editor/Save Actions to configure and put into project(s) as well. Plenty of stuff you need to take care of separately.

Line wrapping and joining

One of the most important thing we do with our code in terms of readability is line wrapping – and one thing I expect from any formatter is an option that respects my line breaks. Eclipse offers “Never join lines” on Line Wrapping and Comment tab. It seems you have to combine them with “Wrap where necessary” option for most options on Line Wrapping tab, but it still does not allow you to split line arbitrarily – it joins the lines back on reformat, to be precise.

Sometimes I want to say “wrap it HERE” and keep it that way. In IDEA I can wrap before = in assignment or after – and it respects it. I don’t know about any specific line-break/wrapping option for this specific case. Eclipse respects the wrap after, but not the one before – it re-joins the lines in the latter case. Sure I don’t mind, I prefer the break after = as well. But obviously, Eclipse will not respect my line breaks that much as IDEA.

Just to be absolutely clear, I don’t mind when a standalone { is joined to the previous line when rules say so. There are good cases when control structures should be reformatted even when wrapped – but these are cases revolving mostly around parentheses, braces or brackets.

When I investigated around “Never join lines” behaviour I also noticed that people complain about Eclipse Mars formatter when compared to Luna one. Do they rewrite them all the time or do they just make them better? Do they have good tests for them? I don’t know. Sure, formatters are beasts and we all want different things from them.

Exporting Eclipse settings

Let’s say you select top right corner link Configure Project Specific Settings… in particular settings (e.g. Organize Imports). This opens dialog Project Specific Configuration – but do I know what is the scope of it when I select my top-level project? Actually – I don’t even see my top level project (parent POM in our case), only subset of my open projects based on I don’t know what criteria. That is ridiculous.

I ended up exporting settings using Export All… button – but you have to do it separately for whatever section you want. In our case it’s Clean Up, Formatter, Organize Imports and Save Actions. I simply don’t know how to do it better. I’ll add these XML exported configs into SVN, but everybody has to import them manually.

IDEA with its project (where project is really a project in common sense) and modules (which may be Maven “project”, but in fact just a part of the main project) makes much more sense. Also, in IDEA when you copy the code style into the project you feel sure we’re talking about all of the code style. If I add it to our SVN everybody can use it.

You can also export Code Style as XML – but a single one. Or you can export all of IDE settings and choose (to a degree) what portions you want to import. While this is also manual solution you need to do it once with a single exported config.

(This situation is still not that bad as with keybinds where after all these years you still can’t create your own new Scheme in a normal fashion inside the Eclipse IDE.)


Maybe the way of Go language, where formatting is part of the standard toolchain, is the best way – although if it means joining lines anywhere I definitely wouldn’t like it either.

I can bash IDEA formatter a bit too. For me it’s perfectly logical to prefer annotations for fields and methods on separate line, but NOT wrapping them when they are on the same line. Just keep the damn lines a bit different when I want it this way! Something like soft format with prefered way how to do the new code. This is currently not possible all the way. I can set IDEA formatter in such a way that it keeps annotations on separate lines and respects them at the same line as well – but all the new code has annotations by default on the same line.

This concept combining “how I prefer it” with “what I want to keep preserved even if it’s not the way I’d do it” is generally not the way formatters work now. I believe it would be a great way how they should work. This can partially be solved by formatting only changed lines, but that has its own drawbacks – especially when the indentation is not unified yet.


IntelliJ IDEA – subscription renewed

It has been over 16 months now since JetBrains presented their IntelliJ IDEA Personal Licensing Changes. The discussion under the post speaks for itself – there was hardly anybody who really liked it. Before you paid 100% when you bought it the first time (not to mention sales they offered ;-)) and 50% anytime you bought an upgrade. That means, you skipped major version or two (roughly a year each) and then bought the one you liked/needed for an upgrade price of 50%.

Now you buy it the first time for 100% and every next year you pay 50% without worrying anymore. Or you don’t renew your subscription and buy next year for 75% as a returning customer. That is like 50% + 50% of it. Long story short – version skipping is now more expensive, whatever your reasons for skipping are.

New model is not all bad…

One good point is that nobody can now complain that they bought version X and the next day you can get X and upcoming major version X+1 for the same price. What can still happen is that the next major version will be released the day after your subscription ran out. Which is more or less the same problem actually, except that now you can make decision that costs you with more information (before you had to be an oracle).

Again – long story short – if all customers stayed and all subscribed, JetBrains will have more money for their (and our favourite!) IDE. I guess there are ever more features, broader scope of problems, and whatnot. Price difference for every version skipping would be 50€ here in Slovakia. Nothing terrible actually.

JetBrains defence of this step was based also on possibility to release more often, even major versions. With IDEA 13 coming on Dec 3rd, 2013 and IDEA 14 on Nov 5th, 2014, we can’t say they lied, but it’s far from radical. And the question is whether it shows in reality, not just on the splash-screen.

…but I can’t see any big change

So that’s how I feel. I more or less (rather less actually) agreed to continuing partnership with the producer of my favourite IDE. It costs a little bit more, obviously there are no sales you can speculate on, etc. Business. But then, it’s not really anything that would ruin me and it’s worth the productivity you get, especially when you’re used to it. There is still Community Edition, if that’s all you need. And man, if you need just Java, version control and build tool support, it’s just incredible.

I wasn’t sure what to imagine regarding potentially faster release cycle and we’ve got just that – nothing radical, no harm done. Some versions are better, some worse, fresh 14.1 definitely needs some refinement as sometimes it stops checking files and finding usages altogether, but it restarts quickly and I hope it will be fixed soon.

What I miss

If I could channel IDEA developer’s energy into any particular area it would be fixing already existing Youtrack issues in general. I was rather a vigorous reporter – sometimes even successful. (Did you know you can copy the error message from status bar clicking on it with right mouse button? How handy is that when you want to paste it into a bug report!) But there are open issues that are probably obsolete already, some cleanup would be great. “Forgotten” issues are no good.

I remember how long it took to bring reasonable javadoc formatting into IDEA – and it still lacks here and there, although it was postponed one or two major versions. These are the things were I’d like to see more effort. But I understand there are customers waiting for support of their favourite framework as well.

Final words

So that’s it. Not a big change in the price, especially if IDEA is your primary axe, or whatever you like as a metaphor for a sharp tool (of course we can talk about tens of percent, but really…). Perceived quality is good, although varying – like anytime before. No tens of percent change there. 🙂 But anytime I see my colleagues struggling with something in Netbeans (“you can’t run normal main method from test sources?!”) or Eclipse (SVN and Maven working normally already?) I know that IDEA is still worth it. Although some people should learn their IDEs in the first place, whatever they use. Sometimes what I see is like a woodcutter beating the tree with the axe instead of cutting it – when we used that metaphor before. But that’s beyond the scope of this post.

Dear IntelliJ IDEA, I love you, but…

No, no, it’s not that I’m leaving. Where would I go? To that total eclipse of sense? Or should I get some beans or what? No way… I’m with you – in good times and in bad! We’ve been through so much together! Do you remember your version 4? How we all couldn’t understand why we can’t have web application support in the same source tree with all EJBs? Not that your free version have any Java EE support now – but then, it is free! Back to that version 4, right?

We got it after all. We partially mavenized our projects (without using Maven while possible and hell, how easy was our life even with all those libraries we had to manage!), we split artifacts into their respective modules and we felt… well, reformed. Thank you.

With every version you brought refactorings that made sense and helped, templates that were really useful, and your completion… it was just all so normal and obvious until any of us had to use those other incompetent IDEs around. Where, tell me, where would we go? We’re not masochists, we know why we use you, it’s hardly possible to live without you anymore.

I declare here and now – I DO love you. You know it, I know it, everybody who knows me knows it – why to hide it anymore? I don’t care what my “normal” friends say (those that are not programmers, you know), I don’t care what people kept in the dark (you know, those living in umbra) may think, they never got it anyway what it is like when enum literals are just completed and foreach template asks for the collection first and the rest is just derived correctly.

My wife can hardly bear it, she’s jealous, but I just don’t care! I love you. But…

There are those times when it’s harder then it should be. Consider, my dear, just a few things. I did my part, I reported stuff, I was faithful – and I’d love to stay it that way. But there are things that are hard to forgive. Hard to go around. Sometimes I just have to use Eclipse – not because I want, not even because the project requires me to do so – but because you are so stubborn and can’t get better with just a few things. While Eclipse is just beyond any chance to be mended, you, my dear, have just a few bugs that are – I’m sure! – easy to fix and all those problems would be gone! All those little situations when Eclipse crowd can just laugh back for all my laughing on their pathetic SVN, Maven (or whatever you name) support.

Not that my list is short, but then there is clear line between things I can easily forgive (though not forget, you know how it goes after many years in relationships) and those I can’t however hard I try. You know that search widget introduced years ago… it would be just so good if Enter worked like in Firefox and Escape really cancelled the search and forgot whatever I wrote in there. No, you’re stubborn. But OK, however stupid it is, maybe all other users love your way and not the Firefox way. I can forgive this.

What I can’t, you ask? Well… the first thing is caused by the existence of Eclipse. You know, we store our resources with Unicode escapes – that is using transparent native-to-ASCII conversion. And the problem is that you and Eclipse just can’t agree on the same casing of those escape sequences. My dear, my dear, I know… it may be Eclipses fault too, but as pointed here, you are not in line with native2ascii tool in the first place. This bug might actually be close to some resolution IF… there wasn’t that resistant bug that appears in a few variants and prevents us from changing the file encoding. Quite serious, don’t you think?

Well, this I had on my heart today (and actually for many days, weeks, even months) and I just needed to get it out. I hope you’ll not take it the wrong way. I told you about my feelings and those are true. Yet I think love is not about being blind, you know. Whatever romantics may say. Of course, my nitpicking list could go longer, but let’s separate serious stuff from details, shall we…

And yes, I don’t want to repeat myself… but if I must. I love you. Of course. 🙂

From IntelliJ IDEA to Eclipse (5)

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.

Finally – here are two IDEA-positive resources – about IDEA knowing what you want (there are more articles in the same month) and one quite an active blog.

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)

From IntelliJ IDEA to Eclipse (4)

Today I’ll try to focus on key shortcuts more. And also the way you can customize them. In all cases when comparing shortcuts, the first one mentioned is Idea’s, the second is from Eclipse.

While Idea has static Default Keymap Reference in its Help menu, Eclipse has Key Assist (Ctrl+Shift+L) – which is more handy if you don’t know what you’re looking for (name of the features are not always the same between both products). Idea’s Search Action (Ctrl+Shift+A) can compensate for this. Talking about Help menu – you can check some JetBrains TV videos about IDEA to get better idea how to be productive or just for some tips.

There is Idea keymap for Eclipse (plugin), but I wasn’t satisfied with it’s completeness, plus I wasn’t happy with Idea shortcut acting the Eclipse way – and you can’t change that. 🙂 And I also want to be able use Eclipse on colleague’s computers too – so why not to learn it with its shortcuts? Well…

One recommendation actually – duplicate (called copy line in Eclipse) and delete line – you may want to change those. You can mostly live with rest (yes even with Enter vs Tab to confirm completion) but Ctrl+D will soon kill you, especially if you are forced to work in Eclipse more than you can in Idea. I changed it in the Default scheme, because when I wanted to create a new one, I found out it’s not possible in any simple way.

Shortcut Schemes cannot be copied inside of Eclipse. If you’re wondering how to create a new one, wonder no more – you have to do it this way (not that I understand that page too much). I’m also not sure how you can add more binds to one action (not a sequence, but two different combinations). Long way to catch Idea on this one.

OK, and now some “Idea-Eclipse remapping” right?

  • Alt+Enter is Ctrl+1 – called quick fix
  • Ctrl+H is F4 – view type hierarchy
  • Ctrl+B or F4 is F3 (Ctrl+left click works the same, though a bit lazily – you have to wait till Eclipse underlines the stuff – maybe even move the cursor a bit, sometimes I can’t force Eclipse to understand this) – you’ll probably mess F3 with F4 a bit
  • F3, Shift+F3 is Ctrl+K and Ctrl+Shift+K – next/previous search, in Eclipse you can just select stuff and press Ctrl+K, in Idea you have to Ctrl+F it or highlight it with Ctrl+Shift+F7, then F3
  • F2, Shift+F2 is Ctrl+. and Ctrl+, – next/previous error/warning, in both IDEs you can set to focus on errors first instead of mixing warnings in too – in Eclipse go to Preferences, General, Editors, Text Editors, Annotations and there you can include many things into this kind of search
  • Ctrl+Y is Ctrl+D – what a shock for delete a line 🙂
  • Ctrl+D is Ctrl+Alt+Down/Up (but only for whole lines) – now you see why I recommend to switch at least this, Eclipse’s option to copy up or down is quite nice, though minor feature
  • Ctrl+W/Ctrl+Shift+W is Alt+Shift+Up/Down – but the selection jumps differently than in Idea and you will probably not like it at all, in Idea it really starts with word – even inside of strings, but not in Eclipse; funny enough, while word selection is way too eager in Eclipse, Ctrl+Left/Right jumps to camel humps inside words (which in most cases is too slow for me, but YMMV of course, you can switch it in Preferences); you will also probably hate selection expansion on property names, where I want to start with one word again, not the whole property
  • Eclipse has Ctrl+J for incremental search – this is mostly similar to Ctrl+F in Idea, though Idea’s Enter/Escape workflow in the search bar could be better for smoother feel (but maybe nobody feels the same)
  • Ctrl+G is Ctrl+L – go to line
  • Ctrl+Alt+V (as variable) is Alt+Shift+L (as local)
  • Ctrl+Alt+C (constant) is only in menu – Alt-T (T as refactor :-)) and there press A (as … well, constant). This leads us to menu mnemonics. Maybe in Eclipse they are problematic because of some history (that is shorter than Idea, BTW), I don’t know. But however you look at it, refactor is not so important, so intuitive, you have to remember strange shortcuts or add your own (which means changes to the Default key scheme for most normal users)
  • Instead of File Structure View (Ctrl+F12) you have Outline (Ctrl+O) in Eclipse. While in outline you can lookup any member from nested classes (something I suggested for Idea a few days back) you can’t use camel humps lookup (gF for getFilter for instance)
  • Ctrl+N is Ctrl+Shift+T to find class quickly – camel humps work nicely in both
  • Ctrl+Shift+N is Ctrl+Shift+R to find any resource (file)

Find in path (Idea’s Ctrl+Shift+F) is quite a pain really. There is no item for this in context menu on the project tree, you have to select the directory, go to menu Search and select File… I don’t feel like searching for file, I take it more like searching for occurrences, but whatever. After this you have to switch radio button to “Selected resources” (I honestly wouldn’t understand that without help, though directory is kinda resource too, right?) and there you go finally. Many Eclipse users don’t know what that radio button means and they rather go with working sets or just change pattern for files if possible. Very, very non-intuitive.

Find usages (Alt+F7) is here (Ctrl+H) but funny enough my Eclipse mates wondered why I ask if I can see the actual lines with occurrence in the search results. Maybe just to know how the same method was used without going to the source! 🙂 I’m sure we (Idea users) miss some funny features from Eclipse too and we don’t know about them yet. Sometimes I’m in doubt if we all code in Java really – so many mindset differences. Also be aware that Eclipse might open all your search results in a single tab – you can change this in Preferences. Also the behavior of this find is very annoying. In non-java files it mostly offers File Search (text search) tab as default, but in Java it offers Java Search with File Search tab missing altogether. That’s the famous “context-awareness” of Eclipse in its worst moments, if you ask me.

Comment the line (Ctrl+/ in both IDEs) works in Java but not in XML/HTML/CSS [EDIT: reportedly it does for JavaEE version]. (CSS doesn’t work in Idea Community Edition either, but then – CSS syntax is officially not supported there.)

Alt+Shift+Insert for column selection mode is Alt+Shift+A. No problem with selection behavior either.

Open recently closed editors with Ctrl+E? Depends… there is no list of files recently closed (quite a shame if you ask me), but you can quickly reopen the last one using Ctrl+Q (last edit location) or hope that your recently closed tab was one of those recently open and then you can use Alt+F and some number (default last 4 can be changed to 9, I strongly recommend that if you need it in your workflow). This is feature I really miss in Eclipse – and from what I asked, many Eclipse users too.

Finally two more links:

I have a bunch of other things prepared, completion comparison mostly with some animated gifs, so stay tuned!

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 (5)

From IntelliJ IDEA to Eclipse (3)

Today I’ll be clearly positive towards Eclipse and critical to IntelliJ IDEA. I have a lot of other stuff (originally saved for this part), but today I’ll make it short. I really found one area where Eclipse beats IDEA without any doubts!

It’s really been for some time I have this code on my disk (just lately reformatted for your better reading):

* This lovely class is simple Hello world like program - but IntelliJ IDEA can't understand it.
* I guess this is the area of Java development, where Eclipse is clearly better!
* public class Hi {
* public static void
* main(String[]
* args) {
* System.out.
* println("Hi"); }}

You have to know that when the compiler looks at the code, one of the first thing is to translate all Unicode UTF-16 escape sequences to characters – and after that it goes on with anything more sophisticated. Check the part in JLS here.

Isn’t the code lovely? And now how ugly IDEA treats this awesome product of years of experience in Java? Check this animated GIF:

Idea Unicode Code

Idea Unicode Code

Eclipse – on the other hand – clearly understands the code, underlines errors, and if I dared, maybe it would even refactor something (not sure if the result would stay in Unicode escapes though ;-)). Check it for yourself!

Eclipse Unicode Code

Eclipse Unicode Code

I don’t think anything can be added to this. Stay tuned for the next part where things will be a bit different. 🙂

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 (4)
From IntelliJ IDEA to Eclipse (5)

Why to synchronize with SVN in Eclipse?

Today we had an interesting experience with SVN. I always thought SVN Update and Commit is safe way how to do stuff, that you have to either hit conflict or everything is merged without any losses. After so many years with SVN I was proved wrong. We create incremental diff files for our SQL model – and today both me and my colleague created the file with the same name. He committed first. I updated. I didn’t check that file (it was just one of many). I committed. And he complained I had overwritten his changes.

How could that happen? Why team synchronization in Eclipse helps? Why update didn’t complain in the first place?! Is SVN to blame? Why it never happened to me in Idea? Actually could it? Have I ever committed the same files created the same day along with my team-mate before? If not, can it happen in Idea too? (It doesn’t have the synchronization as you know it from Eclipse, remember.)

First test with Eclipse – we did it again. Synchronization warns you about conflicting incoming changes. But you can update without any punishment from SVN itself. You have to check the file. When you create a file in Eclipse it is not added locally to the repository (actually, many of Eclipse users don’t know SVN basics “thanks” to this). After the update it becomes locally added and you can clearly see the changes in quick diff – or in outgoing changes – IF you diff them that is. Why would you care when there is no warning, right? Normally it’s not expected two of you create the same file in the same time. The whole process looks like update without any problem followed by your modifications (like they were done afterwards).

This means you should avoid creating the same files (we actually don’t need daily SQL changes tracking – in the end we have to aggregate a lot of files when we’re about to release the next version) or be very careful – or use Synchronize feature before you update. Or check newly added files for differences (who would think about that!).

I check the behavior with Tortoise, just to be sure it’s SVN here cheating me and not Eclipse. I checked out the same project twice and added files to both versions. I didn’t add it locally to the repository in checkout A. Then I added it in the local version B, committed and updated local copy A. File showed differences against HEAD, but no conflict, no warning – except for info that the file was added (and came from the repository).

If you add the file locally to both copies, then conflict is detected and you have to resolve it. When you know your file will be committed sooner or later, that it indeed is part of the project, the best way is to add it locally as soon as possible. You can do this in Eclipse too with Team, Add to version control – but I didn’t find any preferences that would do it automatically.

You can safely rely on update and checkout with IntelliJ IDEA, because Idea typically adds the file locally right after the creation – unless you go against its suggestions, which is not rational (R is not capital :-)). Actually why should you? If you want to have the file in the SVN, there is no reason not to add it. Not to mention you can see nicely whether the file is “under control” or not.

Eclipse tries to handle it differently – I actually don’t like this way (with or without today’s incident, which I consider non-essential, really). I want to know which file is going to SVN and which one is not. Actually, not only know – I want to be the one in control. Of course, you are in control with Eclipse too – but much later. In Synchronization perspective you can remove the file from view. Again – none of my colleagues knows how to remove particular file from this view forever without using svn:ignore feature – which is (I hope you agree) stupid. You’re using SVN ignore (that is SVN’s mechanism) because Eclipse doesn’t make any difference between files locally added and files out of control.

I nearly wanted to finish – but now I realized that I haven’t specified the plugin we use for SVN in Eclipse! Subclipse was used – and if this problem is approached differently with the other plugin (can’t recall the name) let me know in comments and I’ll probably switch. Idea has SVN support fully built-in and you can have only single problem with that (from what I experienced). When we had some older Idea and I “upgraded” local repository version (using newer SVN client for instance) my Idea couldn’t commit or update anymore. But currently with Idea’s free community edition I don’t expect this problem to occur again. 🙂

Happy synchronizing, updating and committing with as few conflicts as possible. And even less wannabe-no-conflicts. 😉

Don’t miss other posts on this topic:
Eclipse vs IntelliJ IDEA
From IntelliJ IDEA to Eclipse (2)
From IntelliJ IDEA to Eclipse (3)
From IntelliJ IDEA to Eclipse (4)
From IntelliJ IDEA to Eclipse (5)