JetBrains IntelliJ IDEA Blog

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.

If you missed Vaclav Pech speech at JAX 2010, here’s your chance to hear it right now. In this presentation he’s discussing common coding pitfalls such as possible NPE, unreachable code, and explains how they can be easily avoided.

Upcoming IntelliJ IDEA version, Maia brings you an improved version of the Dataflow to this feature and the completely new Dataflow from this.

Here I am describing how these features work and how they can help you the Code Archeologists better understand your code.

I am using Apache Tomcat source code as an example.
Let’s have a look at the SingleSignOnMessage class and its obscure String authType field.

(more…)

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.

It is a well known rule that assert statements should cause no changes in state outside of them (aka side effects). Until now, you could only check if this rule was followed by visually inspecting the code. In IntelliJ IDEA 9 a new assert statement with side effects inspection will be available to help you keep assert statements free of side effects.



The inspection will warn about modification of variables and fields inside of the assert statement. The assert statement will also be reported if a method called by it modifies any fields.

I often forget to add newly created tests to the testng.xml, which is used in our TeamCity build, and by the time I realize that they don’t run something is surely went wrong. What a bummer! Not any more, fortunately — IntelliJ IDEA makes sure no tests are missing. All it takes is to enable the Undeclared test inspection under TestNG in the Errors section of the Settings dialog.

With IntelliJ IDEA you can quickly clean up your legacy code. If a problem occurs multiple times in a file, you do not need to manually apply a quick-fix every time — use the Fix all intention to repair them all at once.

IntelliJ IDEA 8.1.1 will support Show Class Hierarchy action that displays class hierarchy of a selected type. Just place the caret at any type in the code editor and press Ctrl+Alt+U.