JetBrains IntelliJ IDEA Blog

Yes! The sunny Spring has finally come to St.Petersburg too. However, it’s not that “Spring” we want to talk now…

We realize that many of you use the Spring framework in your every day work. So, many should be interested in the new Spring-related features that can be found in the upcoming IntelliJ IDEA 10.5 release.

1. Better navigation between xml configs and annotated stereotype components

2. Advanced usage search for @Autowired beans

3. More inspections for your configs, for instance, deprecated classes and members highlighting.

4. More powerful placeholder support. All spring model inspections get and analyze placeholder values before highlighting.

5. More clear Bean Dependencies Graph view. For instance, it obtains beans and dependencies from custom namespaces. Check out this spring integration schemas example.

There are also smaller changes here and there…

Download IntelliJ IDEA 10.5 RC to try it and enjoy the improved Spring framework support.

Java 7 provides a way to remove a compiler warning about generics vararg invocation. With Java 7 you can annotate your vararg method with SafeVararg annotation and your clients won’t get these nasty warnings any more. IntelliJ IDEA 10.5 will help you to perform this migration. It will find for you all the places where @SafeVarargs annotation is applicable and suggest you to add this annotation. Of course, it will also check if existing @SafeVarargs annotations are applicable.

Suppose you have annotated your method with @SafeVararg but already have suppressions for unchecked warning in client’s code:

Since its version 6 IntelliJ IDEA contains an inspection to find redundant suppressions (available in batch mode only). Now you can use it to remove all suppressions which are garbage in your code. It will carefully check that these unchecked warnings were caused by generics vararg invocation and suggest you to remove all such suppressions. Simply run the ‘Redundant Suppression’ inspection (Ctrl-Alt-Shift-I).

All you need to do is to install Java 7 and setup language level to 7.

Download IntelliJ IDEA 10.5 EAP, try the new described features and let us know what you think.

For quite a while IntelliJ IDEA can detect probable NPE’s in your code. But you have to annotate it with JetBrains’ @Nullable/@NotNull. In order to leave your code free from JetBrains’ annotations you could use external annotations, but they were not so convenient to use as they were not visible in the code. With libraries and SDK code, however, there is no other way except using the external annotations.

So, to make things better, 10.5 IntelliJ IDEA will be able to recognize the most common annotations, such as javax @Nullable/@Nonnull, FindBugs @Nullable/@NonNull, as well as your own annotations with the same semantics.

You just need to configure which annotations are allowed in you code and which should be used by quick fixes to annotate the code.

Try it in IntelliJ IDEA 10.5 EAP and let us know what you think.

For a long time already IntelliJ IDEA can detect probable NPE’s in your code. You need to annotate your methods/fields/variables with @Nullable/@NotNull annotations and IntelliJ IDEA will highlight possible contract violations. Good. But the annotations only begin to work when there is enough of them in the code. You do need to annotate your code to get the benefits.

IntelliJ IDEA 10 can do it for you.

Just run Analyze | Infer Nullity… and choose a scope where you want annotations to be inferred. IntelliJ IDEA uses many rules to analyze nullity and make a decision. Here are just 2 examples:

1) The IDE detects parameters that are used without checking for null:

and presumes that they are @NotNull:

2) Variables that are checked for null are assumed as @Nullable, etc.

As a result you can benefit from static code analysis without paying an entrance fee.

To run a single inspection in previous versions of IntelliJ IDEA you had to create a dedicated inspection profile for that or use “Run inspection on…” from inspection’s quick fix list. In IntelliJ IDEA X you can find and run inspection by its name on any scope without creating an inspection profile. Use Run Inspection by Name (Ctrl+Alt+Shift+I) action anywhere to choose a desired inspection from hundreds of available,

then select a scope to run inspection on,

and get results.

This action is available since version 98.402 in Main Menu-> Analyze->Run Inspection by Name.

If you use Client Bundle interface in a GWT application, you will enjoy an advanced navigation and coding assistance that IntelliJ IDEA 10 provides.

ClientBundle methods will be marked with icons allowing you to quickly navigate to a corresponding resource:

For interfaces implementing CssResource IntelliJ IDEA will also check that Java interfaces methods are consistent with CSS classes 

and will suggest to automatically add missing methods:

Download IntelliJ IDEA X EAP builds to try this new feature.

Google Web Toolkit 1.6 replaces EventListener class with EventHandler, so the existing code base needs an upgrade. In most cases IntelliJ IDEA can do this automatically — all you need to do is to press Alt+Enter on a highlighted listener and select Replace quick-fix.


IntelliJ IDEA will then upgrade your code:


This feature is available in Maia builds that you can download from EAP.

Thanks to improvements in the internal indexes behind the Intellij IDEA code insight engine, Maia will be able to instantly highlight some java classes, methods and fields which are unused across the entire project.

To use the feature, enable the Unused declarations inspection.

Of course, all sorts of JEE @Inject annotations, test code entry points
and other implicit dependencies configured in the Unused declarations inspection
are deeply respected.

IntelliJ IDEA code analyzer will be extended with WebBeans-specific inspections in the upcoming Maia release:



Here’s the example of how they work:

Though assert statements are very useful when it comes to checking runtime assumptions, using them to verify conditions that are constant is not so wise. Assert conditions that always evaluate to true are particularly unnecessary because they will never throw an error and can only serve to use up the CPU resources.
Here is an example from com.sun.java.swing.plaf.gtk.GTKDefaultEngine:



IntelliJ IDEA 9 will bring you the assert statement condition is constant inspection, which will detect such assert statements, except for boolean literal false, because it is often used in code which is known or supposed to be unreachable.