JetBrains IntelliJ IDEA Blog

If you’re an IntelliJ IDEA plugin developer, you’re surely going to enjoy IntelliJ IDEA PSI Viewer (Tools -> View PSI Structure), which displays internal structure of various files, as they’re interpreted by IntelliJ IDEA. If you’re implementing a new language support, or trying to add some cool new features to what’s already supported — this viewer is what you’re gonna need a lot.

As you see, PSI Viewer is made up of of tree parts:

• An editor with file content
• PSI structure view with parent-child tree of its elements
• Area that displays references of element selected in PSI structure view.

Note that references marked as red resolve to null.

Available since build 92.35

Working on more than one task at once, you may run in some problems with your changes. Say, you have changed some files in a changelist, then switched to another changelist and made a massive refactoring. Oops! Some files in the first changelist are touched too. Now, committing any of these changelists without the other may lead to troubles.

Maia introduces a way to avoid such scenarios. You can protect files in inactive changelists. When you’re trying to change them (by direct editing or by applying a refactoring) you will see a dialog indicating the files to be changed:

The dialog gives you a number of options to resolve the conflict. You can shelve the changes you made in an inactive changelist and unshelve them later. You can move the previously changed files into the active changelist so that they would be committed together. If all conflicting files belong to a single changelist, you can switch to it, and the new changes will be added there. Finally, you can just ignore the notification and manage the conflict manually.

This strict protection is not enabled by default. You should go to Project Settings -> Version Control -> Changelist Conflicts and select the Show conflict resolving dialog option.

By default, IntelliJ IDEA warns you if you changed files from an inactive changelist. They are highlighted in the Project View, and have a yellow stripe in the editor.

Most of applications initially are single threaded, and IntelliJ IDEA was no different; though luckily, now it isn’t — but we had to adapt our code to use multiple threads. In this post I’m going to tell you how.

In our example we see SAXBuilder, which is too expensive to be created every time we need it, so it is stored in a static final field.

Because SAXBuilder is not thread safe, multiple calls to loadDocument from different threads cause a lot of interesting exceptions. This is why we need either to make access to this field synchronized, or to make the field ThreadLocal. In our case, we’re choosing the latter. We encapsulate the field, change its type and initializer, then fix a generated getter. Quite a lot of work, right? Luckily in Maia you can do it all in just one click. Just place caret on a field and press Alt+Enter to smoothly migrate it to ThreadLocal.

In the upcoming Maia EAP you will find a slightly different Commit Changes dialog.

• Automatic use of JobView filter on search results.
• Support for Perforce native search query syntax (in an example below we’re looking for Job in any field)

IntelliJ IDEA 8.1 brings you many new and improved Flex support features:

• New intention actions
• Improved code editing and generation
• Better code completion with Flash 10 Generics
• And more.

We have also created a live demo that shows the advanced IntelliJ IDEA Flex support features in action: smart Flex code completion, Flex code analysis with quick-fixes, Flex refactoring, convenient project navigation and usage search. You can watch it now or download archive for offline viewing.

Raise your hats to Ted for his recent IntelliJ IDEA Tips series! Ted sheds light on the wallflower features of IntelliJ IDEA, as well as new ways of using well-known features and the most beneficial plug-ins.

• IntelliJ IDEA Tip: Change Background Color for Read-Only Files
• IntelliJ IDEA Plugin of the Week: Describe Key
• IntelliJ IDEA Tip: Goto Class Coolness
• IntelliJ IDEA Tip: Open All Files in a Changelist
• IntelliJ IDEA Tip: Quick Lists

Stay tuned for new enlightening blogposts from Ted!

Another valuable contribution comes from Cedric Champeau, who has shown how structural search in IntelliJ IDEA can help you find try/catch performance bottlenecks.

If you are looking for ways to speed up IntelliJ IDEA on your computer, some of these 10 Tips to Increase IntelliJ IDEA Performance should prove helpful.

And, last but not least – 9 more reasons to love your IDEA of choice – thanks to Messi.

Yesterday the Utah Java User Group held its regular monthly meeting, and to shake things up a bit, they decided to make it an IDE Shootout between some popular IDEs: Eclipse, IntelliJ IDEA, NetBeans, and BEA Workshop. During the meeting, the audience was polled to find out which IDE they were currently using, and about 75 people raised their hands for Eclipse, while only 10 for IDEA, and another 10 split between the other 2. At the end of the presentations, the audience was asked to vote on two awards for the IDEs. The first was called the “Second Look Award” and reflected the idea that after spending years and years getting used to one IDE, it can be challenging to move to a new tool. The UJUG site described it like this:

The UJUG ‘IDE Second Look Award’ signifies the impact of both the presentation and the abilities of the IDE presented. Switching to a new IDE is difficult. Typically, a Software Engineer has used the same IDE for many years, slowly becoming a master of it. To even consider looking at a different IDE is the willingness to take a step into the unknown. The Salt Lake City, Utah Java User’s Group shows its appreciation to the presenter for preparing and creating an influential presentation and to the developers of the IDE, convincing the largest number of people to take the first step of considering a new IDE.

Winner: IntelliJ - Etienne Studer

The second award was the:

UJUG IDE People’s Choice Award
The UJUG ‘IDE People’s Choice Award’ signifies the impact of both the presentation and the abilities of the IDE presented. The Salt Lake City, Utah Java User’s Group shows its appreciation to the presenter for preparing and creating an influential presentation and to the developers of the IDE which impressed the largest number of UJUG attendees.

Winner: IntelliJ - Etienne Studer

We would like to thank Etienne for his expertise and the great presentation that helped IntelliJ IDEA win these significant awards.

There are many development tools in the world. For now, picking the right one that suits for anyone’s requirements is a complicated task. It’s not about the number of supported frameworks, servers or languages. It’s not even about the number of different features implemented in this or that tool. Picking the right tool is about how good it’s made. How all the features are glued together and integrated one with another, and what’s even more important - that you have to feel this tool is made for you. That is, how good you and the tool are getting along and how it lets you be more productive and effective.

You can read the agile developer blog post that also discusses whether a tool is worth the money it costs. By the way, the example he gives at the end of his article is really, really impressive.

Furthermore, the No Fluff Just Stuff Antology author, Neal Ford speaks about how effective IntelliJ IDEA is in his non-stop talking about IntelliJ. He also mentions that people who use IntelliJ IDEA are way more passionate about using their product and are always happy to share their experience.

Sebastiano Pilla wrote a very interesting article about his experiences with the top four IDEs. After testing each one according to his criteria, his pick was IntelliJ IDEA:

“IDEA simply worked without getting in my way with arbitrary limitations. Where it shines is in the editor, the configurability and the speed at which everything operates: in a “shopping list” of features it might lose to the others, but it wins because the implementation and the design feel more consistent to me.”

The lesson is clear. Comparing IDEs by simple feature lists won’t necessarily find you the best IDE. You need to actually try it to be sure it will be right for you. Look for an IDE that boosts your productivity by doing what you expect it to do without getting in the way, i.e. it ‘just works’. A feature list might tell you a feature is there, but it won’t tell you how well it works.

Two interesting polls include IntelliJ IDEA and TeamCity among the tools surveyed for John Ferguson Smart’s upcoming book, Java Power Tools.

In the poll for code quality, IntelliJ IDEA currently has the highest rating, likely due to its powerful and easy-to-use static code analysis features, including over 600 code inspections, built-in code coverage analysis, and dependency analysis.

TeamCity was only recently added to the continuous integration poll, so it’s a bit low on votes at the moment. Originally, the poll had only open source tools, but Smart added some commercial offerings because of the rapidly changing landscape of the continuous integration server market, which I talked about in a recent idea.log post. TeamCity represents a new generation of CI servers due to its attention to the problems of broken-build syndrome, when a broken build causes the whole team’s productivity to drop. TeamCity tackles broken-build syndrome and much more. Are you already doing test-driven development and interested in increasing team productivity? You may want to check out TeamCity.