JetBrains IntelliJ IDEA Blog

With IntelliJ IDEA 10.5, you may press up to twice as less keys every day as you do now. Seriously! Here’s how.

The reason IDEs exist in the first place is that they make your life easier. In particular, they are able to generate code for you. An ideal IDE would do all the boring typing by itself, leaving you more time for thinking about the great software engineering problems you face. Unfortunately, such an ideal is not there yet. Currently, if you want an IDE to help you, you first have to help it help you. Usually this means giving it some cues on a word you have in mind, and it then tries to guess the whole word. So you can just type  NPE and smart IntelliJ IDEA will suggest that you must have meant NullPointerException. Or StBui for StringBuilder. I’m sure you get the idea. This handy “camel case” matching feature saves quite a lot of typing.

Here it gets complicated. In the first place, you had to so something (coding) and the IDE was there to help you. Now you have to do something easier, namely giving the cues to the IDE. But since this requires some action from you, why couldn’t IDE help you with this as well? This means helping you help the IDE help you :). But how can such a simple task as giving the cues be made even simpler?

As it’s easy to see from the examples, the “camel case” matching requires you to enter LOTS of capital letters. And this means pressing Shift quite often. Very often. In fact, almost always. But is this really needed? Following our colleagues from ReSharper team, we asked ourselves this question and, like they, have found no adequate reason. After that we just removed this requirement to press Shift in IntelliJ IDEA. Well, you can still do it, and the capital letters will match “camel hump” starts as they did before. But why bother if you can get the same result without Shift? OK, chances are that you’ll see a bit more variants in this case, but this still pays off in the productivity.

Shiftless matching is now everywhere in IntelliJ IDEA.

When searching for a class (Ctrl+N / Cmd+N):

When typing in the editor with the autopopup enabled:

In the File Structure popup (Ctrl+F12 / Cmd+F12):

So, grab an IntelliJ IDEA 10.5 EAP build, rest to your little fingers and enjoy!

IntelliJ IDEA is a great IDE for Java, Groovy, Flex, Python, Ruby and many other languages. The text editor with camel-hump completion, and version control support are so great that it may be hard to switch to another editor which may lack some useful features. So, when a need arises for me to code in a language that’s not listed on the features page, I just teach IDEA some basics about that language, and feel much more comfortable than I would if I was editing a plain text. Luckily, you don’t have to write a plugin for that, it is possible via the GUI.

Assume you want to edit Haskell code in IDEA. You go to IDE Settings | File Types and press the ‘Add‘ button next to the file types list:

This brings a dialog where you can provide some knowledge about Haskell: case sensitivity, brace matching settings, ways of defining comments and keywords. You can have up to four lists of keywords, which will be colored differently in the editor. And, of course, all of them will be auto-completed.

After you are done with this dialog, all that remains is to assign the *.hs extension to the newly created file type:

And enjoy hacking:

Groovy’s as keyword allows for some interesting features. In particular, it provides a convenient syntactic sugar for object creation:

Point point = [4, 2] as Point
KeyAdapter listener = [
        keyTyped: { e -> … },
        keyReleased: { e -> … }
] as KeyAdapter


Still in development, but already quite usable, there is Groovy++: a library which adds static typing, performance and much more to Groovy language. One thing you get addicted to quite soon is that you don’t have to write as in the cases above anymore. If the compiler can statically figure out the expected type, it will insert all the necessary casts for you. This works, for example, for variable declarations, method return types and even method calls. So, if you have

JComponent comp = …

you can then write

if (comp.contains([x:2, y:4])) { … }

Cool, isn’t it? But why am I writing about all this in IntelliJ IDEA blog? Well, just to boast. Unusual syntax is not a reason for not helping you in coding, right? So, now the converted list/map literals will be shown if you search for the constructor usages in IntelliJ IDEA:

And the syntax highlighting on the brackets will help you distinguish between plain list/map literals and the ones that serve for object creation:

Finally, you can easily navigate to the constructor called via a literal. Just place your caret before the opening bracket and go to the declaration (e.g. press Ctrl+B)!

All this will be available in the next IntelliJ IDEA X EAP.

When you look at a typical Groovy stack trace, you usually see something like this:

This is not terribly helpful, since there are only three lines from the actual source code. Everything else refers to Groovy’s internals. From now on, though, reading Groovy stack traces will be much easier:

Sometimes I find myself writing repetitive code constructs without being able to extract common code due to Java syntax hmm… let’s call them peculiarities. ‘Sounds like a job for a live template’, I think, and I simply create it. Here’s how. The documentation has it too, but a good example never hurts.

Let’s suppose you have read/write synchronization in your project, and from time to time you need to wrap a bunch of statements in, say, a read action. This involves putting them into a Runnable and giving the latter to some runReadAction method. Do you still do this manually? You don’t need to, IntelliJ IDEA will help you!

First, find an existing code which already invokes the read action and select it:

Go to Tools menu and choose Save as Live Template there:

You’ll see a typical Edit Live Template dialog with the text you’ve selected. Note that all the class references are qualified there and Shorten FQ names checkbox is on, so the mentioned classes will remain the same no matter where you choose to insert it.

What we want to keep is the external syntax: the method call and the runnable. So remove everything inside the run() method braces and replace it with a $SELECTION$ on a single line. It means that you may select something and it’ll be wrapped in this particular construct.

Enter some abbreviation to easily invoke it each time, and some description (optional, but useful). Finally, the formatting looks not quite pretty, so turn on the Reformat according to style checkbox.

That’s all! Click OK and start using it. Find a fragment you want to wrap into a read-action, select it and invoke Surround With… action (Ctrl+Alt+T). You’ll see the read action template in the list:

Select it and the read action is in there:

How are you learning stuff about IntelliJ IDEA? Reading this blog, using Productivity Guide from the Help menu, or even maybe reading the documentation, right? None of these contain all the information you need, though. This is why we decided to start listing details of different features — complete and uncensored, directly on Confluence. We begin with Java completion features. Hope reading this will help you improve your productivity. Enjoy!

Do you often find yourself calling a super method with a large number of parameters? Typing all those arguments one by one is soooooo boring, isn’t it?! Don’t be upset anymore — latest Maia EAP can rescue you. Just use Smart Completion (Ctrl+Shift+Space):

Say, you hit a breakpoint in Java code:

And you cleanly see that component is a label:

You now want to investigate label internals via Evaluate Expression (Alt+F8), e.g. invoke its getText() method, but component declared type is Component and it does not have this method! The only way out is to use Surround with run-time type (Ctrl+Alt+T) first to cast it to JLabel and only then completion becomes available:

Not anymore it isn’t. IntelliJ IDEA tries to help with casting wherever possible, so you can now get the same results using Basic code completion (Ctrl+Space) only:

…press Enter and the cast is done for you:

Needless to say, it works with Smart completion (Ctrl+Shift+Space), too. It works even for complex expressions with method calls. Note, that method evaluation can take a lot of time, not to mention the possible side effects, so evaluating expressions every time you hit completion is not so nice. This is why you need to press the same shortcut twice to get the run-time type variants. That’s what you’re going to see at the bottom of completion list:

And you can play with all this now!

The next Maia EAP brings you massive changes in Groovy, Grails, Griffon, Gant & Gradle support, mostly affecting framework configuration.

First, Grails/Griffon application options are available when you create a project or a module:

You may also choose to import an application from existing sources:

Earlier, you needed Gant & Gradle in module dependencies to run build scripts — quite awkward, because the way you are building your project should not affect its classpath. Now, we have per-project settings for Gant & Gradle:

Also, you can now write Groovy code and get full coding assistance with compilation as long as you have Groovy jars anywhere in a module classpath. Together with the new compiler Resource patterns path constraints feature (/ - path separator; /**/ - any number of directories) this made Groovy facet obsolete. So, there is no Groovy facet anymore.

You can still add any Gr8 libraries to a module via Add Framework Support context action:

Everything you’ve just read about will be available in the next EAP.