JetBrains IntelliJ IDEA Blog

If you’ve read our latest posts, you might get excited about the cool stuff that’s coming in Maia, but wait a minute; there are already lots of great features in IntelliJ IDEA 8.1 that you can touch right now, while looking forward to get the first Maia EAP.
I’m talking, for example, about the full Team Foundation Server integration, that is already available. All you need from version control is included.

• You can perform all common VCS functions like commit, update, revert, show differences and history, automatic check out of modified files, etc.
• You can create and merge branches, lock and unlock files and view the history of committed and incoming changes, link the existing work items to your changelist.
• IntelliJ IDEA also lets you create and manage TFS workspaces.

But that’s not all. The most remarkable thing is that IntelliJ IDEA’s TFS integration doesn’t require Microsoft’s TFS client installed; furthermore, it works under any OS, not only Windows.

Good news for those who use the issue tracking integration features of Perforce.
As you know, Perforce allows to associate issues with changelists in a simple way: each new issue is associated with a Perforce job, and then you list it in the corresponding changelist when you submit a fix.
IntelliJ IDEA Perforce integration now lets you list your Perforce jobs, view their details and link them to arbitrary changelists. You have no need to leave your beloved IDE to link the job - all can be done right from the Commit Changes dialog.
To feel the new feature advantages, you need to enable it first. This is a question of a single check box. Open Settings dialog (Ctrl+Alt+S), select Version Control | VCSs | Perforce, and locate the Enable Perforce Jobs support check box. That’s all!

Now, when you decide you’ve done enough to commit a fix, open the Local tab of the Changes tool window, find the needed changelist, right-click it and select Commit Changes, as you always do. Note that the familiar dialog is now extended with the Jobs area, where you can easily link the required job to the changelist. You don’t even need to remember job’s name – IntelliJ IDEA provides handy search option for jobs. Simple as it can be.



Naturally, you can link a job to changelist earlier, when the work is in progress and commit is still a long way off. Just right-click the changelist in the Local tab, and select Edit Associated Jobs.

This feature is available since IntelliJ IDEA 8.1.

IntelliJ IDEA 8 can help you maintain and improve the source code in a wide variety of ways. For example, to make it clearer, simpler and less knotty, you can use its rich set of refactorings. In this article we’re going to explain the Remove Middleman refactoring, which is helpful when you have classes doing too much simple delegation. Remove Middleman refactoring replaces all calls to delegating methods with the equivalent direct calls.





Here, bar field in the Foo class is nothing more than a simple delegation, so we can safely remove it. Right-click this field and select Refactor | Remove Middleman. IntelliJ IDEA suggests to inline methods which simply forward the calls to this field and remove their declarations. That’s OK for this case, so we click Refactor and enjoy the result!





If you need the delegating method declarations for backward compatibility, or any other reason, you keep them – IntelliJ IDEA gives you this option.

We’re continuing the series dedicated to new IntelliJ IDEA 8 refactorings. Today’s hero is Wrap Return Value, which is handy when you need to append some data to what a method already returns.
For instance, have a look at the following code.



At the moment we can only retrieve the full person name. Imagine how inconvenient is trying to fish out the separate first or last name in this case. It would be much more convenient if we had an option to retrieve only the part of the name that we need.
Right-click the return value and select Refactor | Wrap Return Value. Specify whether the wrapper should be a new class, an existing one, or an inner class, and click Refactor.
Now the method returns this object instance:



which contains getter for the full name:



Let’s rename the value field to name to make the code more limpid. For that, we’re using Shift+F6 – Rename refactoring. Note that IntelliJ IDEA renames not only the field itself, but the matching getter method as well.
After that, all we need is to just add getters for the first name and last name to the wrapper.



Watch this and the other refactorings in a new live demo!

As you might already have noticed from the Features list, IntelliJ IDEA 8 brings you 7 new refactorings to ease the daily coding routine. One of these refactorings is Introduce Parameter Object. Its name speaks for itself: when you have a large group of parameters which go a long way through a chain of delegating method calls, it lets you create a wrapper class that you can then use instead. Another case is when you have a group of method parameters semantically tied one to another – a wrapper class comes handy as well.

Let’s have a look at an example. Say, we have this code:


Look at how many parameters are passed to drawEdge method – six! Imagine how lengthy the calls to this method are and how it all swamps the code. No worries – IntelliJ IDEA can help us. As we can see, the X and Y coordinates and the edgeWidth naturally go together, so we can move them to their own object.

Right-click the method name and select Refactor | Introduce Parameter Object from the context menu.In the Introduce Parameter Object dialog, we can select whether we want to create a new class, inner class, or use an existing one to wrap the parameters. For this case, we opt to the first choice. Then, select the parameters to be extracted. As we decided, these are edgeWidth, x1, x2, y1, and y2. Click OK, and voila – the things are a lot easier now!

Most of you are aware of IntelliJ IDEA smart type completion feature that is invoked with Ctrl+Shift+Space shortcut. If you are not familiar with this feature, I totally recommend you to read the post about it, because this thing is a real developer’s gem. Besides, in the latest IntelliJ IDEA 8 Milestone 1 release, this gem became even shinier.

Long story short, let’s cut to the chase and inquire into the matter through the examples.

• Consider we have the following code:
  
  If we press Ctrl+Shift+Space and get no results, because a collection type is expected, we can press Ctrl+Shift+Space again to make IntelliJ IDEA search for arrays with the same component type and suggest to convert them with Arrays.asList() call.
  
• Press Ctrl+Shift+Space twice, and IntelliJ IDEA will search for chained expressions of the expected type.
  
• When an array type is expected, but no suggestions can be made in the current context, press Ctrl+Shift+Space one more time. IntelliJ IDEA will search for collections with the same component type and suggest to convert them with toArray() call.
  
  

If you care about performance of your project and development productivity, there is no any way to overestimate automated refactorings. They are in fact a powerful tool that allows improving your code without spending plenty of time.

In addition to IntelliJ IDEA rich set of refactorings, one of the latest EAPs offers a new one, called Type Migration. Let’s take a look on it.

Consider we have some code like the following one:

Here, myID is declared as String. You might encounter such situation while working on some legacy projects, for example. As our application apparently uses a database, we need to make myID int instead of String. Formerly, this could be a real headache, if we work on a quite large and complex project. Although, we can simply search and replace the type, we’ll definitely end up with a project full of red-underlined code such way. We need more intelligent and easy way to change the type, and now we’ve got it - type migration refactoring.

Just place the caret at the type to be refactored and press Ctrl+Shift+F6. Alternatively, select Refactor | Type Migration on the main menu.
In the Type Migration dialog specify the new type and the scope to be refactored, then click Preview to investigate the usages to be affected and conflicts, if found. In the preview you can also exclude some nodes from the refactoring, for instance, if they affect your API.

In our example, there is a conflict, since getID() will return int, and equals() is not applicable to primitives. We can easily fix this part manually in the editor. Then, the only thing we need to do is rerun the refactoring from the preview, and voila, myID is now int.

If you’ve happened to use IntelliJ IDEA’s Analyze Stacktrace feature to investigate someone else’s stack traces, you’ll like the way it is extended in the latest IntelliJ IDEA EAP.

You can now paste an entire thread dump to the Analyze | Analyze Stacktrace… dialog. IntelliJ IDEA will present all threads in a readable way and sort them so that those, most probably responsible for the deadlock or “hang”-problem in question, will be listed first.

While developing any application, you most probably debug it, and I bet my bottom dollar, making this process a little bit easier and faster would not be out of place.
In this post, I’d like to tell you about one of the IntelliJ IDEA features — type renderers. They provide you the ability to customize how objects are displayed in the debugger, offering “logic-oriented” presentation of data vs. structure-oriented as it is by default, and thus improving the readability of the Debug tool window. Let’s see how it works.

To define your own type renderers, open Settings (Ctrl+Alt+S) dialog, click Debugger and select Type Renderers tab. This tab lists all the renderers you’ve defined and allows you to turn them on and off at any time using the check box next to their name. The order of the list is important. It determines which renderer is used, if more than one renderer is applicable to an object instance.

Now let’s add a new renderer. To do so click the plus button, then specify renderer name, the object class to which it applies, and which expressions to use while rendering.



In our example, we’ve created an expression that displays the user’s full name by accessing the first and last name properties of the object.

Also we’ve defined the appearance of the expanded node. Normally, expanding a node in the debugger lists the object’s member variables. Nevertheless, you can override that behavior. Here we’ve selected to reflect only three of the object’s properties and have used descriptive names rather than the member variable’s name.

Note: There is also a possibility to use a single expression to calculate information to be presented for the node. When expanding the node, the specified expression is evaluated and applicable renderer is picked for the resulting value. The chosen renderer is then applied to get the nodes that will be attached as children to the node that was originally rendered. We can also specify a Boolean expression to test if the node can be expanded. If it is true the renderer displays the expandable nodes for the defined objects. Otherwise, no nodes are displayed.

These expressions are helpful when you want to limit the amount of information displayed or to be more precise in how the information is presented, for example.



When defining expressions, feel free to use IntelliJ IDEA’s code-completion features to help you. All method calls and member variable access is relative to the object you’re rendering. Use this to refer to the instance, to which the renderer is applied.

Note: Using “heavy” expressions in renderers may slow down data rendering in views. Much as method calls should be used with caution because of possible side-effects.

One more trick: you can easily switch between applicable renderers for particular object in already built data tree with the View As option in the context menu of the Variables or Watches tab of the Debugger, even if your custom type renderer is disabled.

P.S. Type renderers are available since IntelliJ IDEA version 5.0.

Each new IntelliJ IDEA version brings lots of different enhancements. Maven integration is not exception to the rule, and I’d like to draw your attention to some Maven integration improvements in IntelliJ IDEA version 7.0.3, that I personally consider worth mentioning.

• Automatic synchronization with Maven structure on startup. Now, when importing Maven projects to IntelliJ IDEA, you can specify, whether you want IntelliJ IDEA to sync with the projects on startup or not (unlike it was done in IntelliJ IDEA 7.0.2 that used temporary modules for this purpose).
  
  
• Automatic detection of facets. While importing your Maven project to IntelliJ IDEA 7.0.3, the following facets are detected automatically: Java EE, EJB, GWT, and Web. All dependencies and deployment settings are recognized and stored. If you change some facet’s build setting, or add own deployment descriptors, IntelliJ IDEA will preserve them, so they won’t be lost when synchronizing with Maven projects.
• Selecting build profiles. If you import a Maven project to IntelliJ IDEA 7.0.3, you can specify profiles to be taken into account, thus selecting module structure and dependencies.
• Detecting errors. If you try to import Maven project from a pom.xml file, that is somehow corrupted, IntelliJ IDEA will warn you about erroneous descriptor file.
  
  

See the release notes for other improvements and fixes, and download the free 30-day trial version.