JetBrains IntelliJ IDEA Blog

Suppose you have accidentally deleted a file from your project, and want to have it back. Sure, you can restore it using the file system, but IntelliJ IDEA suggests a better way to do it, without leaving the IDE.
This is where IntelliJ IDEA’s local history on the project or folder level comes to help, preserving all modifications that affect the nested files, including the changes to the contents and to the file tree in general. Each change is marked with its time stamp, revision, and action description. Unlike version control that keeps track of the committed revisions only, the local history preserves all local changes you make as you edit, compile or test, during few days (it is up to you to define how long you want this history to be). This “personal version control” will help us restore the deleted file.
In the example below, a file Lost.txt has been deleted from the FontChooser project. Let’s try to restore it. Go to the Project tool window and right-click the project node or just a folder, where the file used to exist:

On the context menu, choose Local History, and click Show History on the submenu:

The local history view for a project or folder shows you everything that you have done during the last few days. In the Action column of the lower part of the dialog box, select the action you want to roll back. In our case, this is the “Deleting” action. So doing, the upper part of the dialog box shows the tree view of changed files.
If you want to restore the deleted file only, regardless of the other changes that have been done since then, you can select the file Lost.txt in the tree view and click the Revert button on the upper toolbar. The file will be restored silently.

A different situation occurs, if you want to restore the deleted file and the whole project or folder state as of a certain revision. In this case, place the cursor on the revision prior to the “Deleting” action, or on the action itself, and click the Revert button on the lower toolbar. If the other files have been changed since the “Deleting” action, you will be prompted that the other changes will be reverted too. Look again at the Project view – our file is here:

DSM stands for Dependency Structure Matrix - a method for exploring dependencies between program parts (modules, classes, etc.), and provides a compact matrix representation of a project. It helps you visualize the dependencies between the parts of a project and highlights the information flow within a project.

When working on complex software projects it’s especially important to track dependencies between project parts. You might encounter too complicated relationships, or cyclic dependencies, that may seriously affect application performance and behavior, or even impede further project development. IntelliJ IDEA has adopted the DSM technology to provide easy reviewing and resolving of potential problems in project structure.

Let’s take a closer look at the DSM. To view the dependency matrix of your project, select Analyze | Analyze Dependency Matrix from the main menu and specify the desired analysis scope. If your project class files are out-of-date, IntelliJ IDEA will ask you whether you want to compile a project before continuing the DSM analysis. It is recommended to compile the project to avoid the analysis resulting in incomplete or incorrect data.

When ready, the DSM View is opened in a new window, enabling to examine dependencies. Let’s discover what we can learn from the DSM view.



In our example there is a typical DSM view with one of the rows selected. The row headers represent program structure. Everything is collapsed now and only modules are shown. When expanded, the header is tree-like, allowing you to dig into program packages. The column headers are the same as the corresponding row headers. Thus they are not shown in order to save space. Instead, different visual aids are used on the row headers.

Here we can learn the following:

1. The selected row and corresponding column are highlighted to visualize row dependencies.
2. The ellipsis in the cell means that the maven-core module has many (more than 99) dependencies on maven-project module.
3. The column shows the dependencies of the selected row.
4. The row shows the dependencies on the selected row.
5. This means that the maven-project module has 16 dependencies on maven-settings module.
6. Various shades correspond to the number of dependencies. The more dependencies there are the bluer the corresponding cell is.

And what about dashes and color annotations? This is quite obvious also.

1. Color annotations help to visualize row dependencies at a glance.
2. This green annotation means that maven-core depends on maven-project.
3. This yellow annotation means that maven-project depends on maven-profile.
4. The dashes on the diagonal correspond to self dependencies which are not shown.

Thus, when we select a row, green annotations show dependent modules, while the yellow ones show modules on which the selected module depends.
Dependency matrix becomes more convenient, if you remember one simple mnemonic rule – all dependencies always “flow” from Green to Yellow.
At this moment we’ve only selected one of the rows. Let’s select some cell to explore the dependencies indicated in it.



For example, cell #1 is one of interest. We’ve selected it, and again, we can see some color annotations. They mean that maven-project has 16 dependencies on maven-settings. The symmetrical cell (cell #2) shows dependencies in the other direction - in this case zero.

You might notice that instead of alphabetically sorting rows, DSM view sorts dependencies in a special way: classes, which are used most, are moved to the bottom. In a project with good structure this creates a triangular shape in the lower left half of the matrix.

Let’s drill down a little bit and expand some cell. For example, we want to take a closer look at dependencies between maven-core and maven-error-diagnostics. Corresponding cell is shown below.



We double click it to view the expanded dependencies.



If the project contains mutual dependencies, called cycles, we’ll simply detect them while exploring the DSM view.



Cyclic dependencies are shown in red. In our example, this means that the lifecycle and * are both dependent on each other, as well as plugin and usability.
Such dependencies require much more attention, and you may need to investigate them narrowly. Integrated advanced code navigation will help you to jump directly to the code which requires your attention. Just right-click the dependency and choose Find Usages for Dependencies on the context menu.



All usages will be shown in the corresponding tool window.

While exploring dependencies you may find that some part of your project deserves more attention and should be discovered in detail while the rest of the project is not of interest at the moment. In such case, you can limit the scope of your DSM to the selected rows, or dependencies.

Now, structure of any complex project, with thousands of Java classes, spreads out before your eyes.

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.

Once again we’re happy to let you know that our productivity-focused IDE for Java Developers, IntelliJ IDEA has been listed as a 18th Annual Jolt Product Excellence Award finalist, in two categories: Web Development Tools and Development Environments.

We hope our efforts on creating the most productive and intelligent Java IDE will be appreciated, and IntelliJ IDEA will be one of the winners honored at a gala ceremony on March 5, 2008 in Santa Clara, California.