IntelliJ IDEA and yFiles diagrams

I have a long history with IntelliJ IDEA and in overall I love it. Sure there are tons of minor (and also more than minor) issues but it’s just like with a marriage – you have to find a partner who’s flaws you can tolerate. IntelliJ IDEA is such a partner for me.

But there is a thing I really don’t understand at all – for years I hoped JetBrains reconsiders, but it seems to be a lost cause. I believe their diagramming is just plain terrible. And the reason is not how the diagrams look like – even though while some UMLs are nice most dependency diagrams generated from any bigger POM file are virtually unusable.

The worst part of the whole experience is mouse control over the diagram:

  • Mouse wheel scrolls vertically, but terribly slow. Zoom would be much better. Use Ctrl+wheel. But even if you unzoom as much as possible, you often don’t see anything because the canvas is much bigger and the diagram gets lost somewhere. Tip: Try to find it in the middle using scrollbars for orientation.
  • If you ever tried to drag the viewport (aka hand tool or something) you find out that all the intuitive ways don’t work. Even worse, they stand in your way. Use Ctrl+left mouse, BTW.
  • If you try middle mouse on its own you’ll experience the most weird thing – after you drag with middle mouse, nothing happens. But the moment you move the mouse cursor a magnifier appears on the spot where you ended dragging. No clicking makes it go away. Tip: Just press Alt, seriously. Don’t ask. With Alt you can actually move the magnifier around.

If you’ve ever seen dependency diagram in Eclipse you probably can’t understand the layout of IDEA’s diagrams – or anything else around them for that matter. In the aforementioned dependency diagrams you either see a cobweb of lines with pixel-sized boxes, or hardly more than couple of boxes you can actually read at the same time. I tried various layouts and I don’t like either really – and it’s not my visual taste, it’s how unhelpful their layout typically is.

There are some things to like, I guess. I like how you can navigate them with quick search (typing). But that’s about it. Why the visualization and layout engine is how it is and why the controls are so counter-intuitive is beyond me.

Of course, if you’re more regular user of these diagrams you’ll probably get familiar with the controls. Not sure about the layout though. I don’t know how much these flaws are related to the used commercial yFiles and how much is IDEA’s integration.

Conclusions? Don’t forget that Alt to get rid of that magnifier. 🙂 I personally believe the diagrams could have been much better and easier to navigate, perhaps even without a commercial engine. That would also enable the community around the free IntelliJ Platform to build something on top of them.


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.

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. 🙂

More positive take on Maven

Sometimes I start making notes on some topic and it takes me months (or even over a year!) to finish that particular post. But I should not wait with this one. Situation with my Maven expertise isn’t much better than when I wrote what I wrote the last time. I found some more around the same attitude (or even more, no problem) – but also something in defence – right from the people who should know Maven best. And yes, even they agreed with some of the issues (especially on release plugin).

Actually, talking about releasing artifact… right know I’m reading book about Continuous delivery (of software, of course), we’re still long way to get there all the way, but what strikes me is how often automation is mentioned and stressed. And here we are releasing Maven artifacts after reading dozens of points, installing external software (PGP), configuring tons of stuff and eventually failing in many cases (or just giving up). That’s definitely the biggest failure of Maven in my eyes.

But back to the title! Today it’s positive and – shame on me! – here I am spoiling it with all the reiteration of my previous concerns. So what is it that I suddenly like so much about Maven? It’s actually very simple. One thing that Maven really made right was imposing all its rules about project structure on us. Most of our current projects are not really Eclipse anymore, they are Maven projects – and Eclipse understands them, creates all is necessary files – but we don’t check in those.

While Eclipse project is not particular problem for my beloved IntelliJ IDEA (the same I cannot say about Eclipse… well talking about Idea’s project, not Eclipse’s own, of course :-)), using Maven projects in IDEA is just trivial too! And this kind of cooperation is just worth it. Because with Maven, you can go either direction. I just wish the building and all was just as pleasant as is project management.

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)