My 5 favorite NetBeans IDE features (vs. Eclipse)

In my current project, Eclipse Kepler has been selected by the customer as the preferred IDE for all main tasks. Of course, I’m also using NetBeans 8.0 for some activities like, for example, legacy code test coding.

I have already used Eclipse some years ago and, at that time (2009), Eclipse Galileo were quite superior to NetBeans 6.x: faster, rich of code hints and warnings, full of useful plugins. So, I was not really happy when the project moved to NetBeans (because of its Swing support).

Now let me compare them again, Eclipse Kepler 4.3 vs NetBeans 8.0, on same project (a big ant based web project) and on the same PC (Win7 64bit 4G RAM).

Speed

My first big surprise. Five years ago, when I moved from Galileo to NetBeans I really missed Eclipse speed: coding, windowing, compilation, everything were significantly faster in Eclipse.

Now this speed advantage is gone. I don’t have benchmarks to demonstrate my feeling but now my coding is visibly faster with NetBeans 8.0 than with Eclipse Kepler. If you install Findbugs and PMD plugins, Eclipse becomes really slow.

Native testing support

Second surprise. Why, in 2014, an IDE for Java EE developers does not include full testing support ?

I cannot imagine any real EE developers which does not need any kind of test support from the IDE.

In NetBeans there is complete native jUnit and TestNG support (templates, test runs, jump to test option in the editor, both *Test and *IT files support) which I found very useful and efficient.

Eclipse native support is poor but of course it can be extended via plugin. I’m using MoreUnit plugin which is quite nice and add many missing features to Eclipse. See here for a small tutorial.

But even if you install a test support plugin like MoreUnit, still an important Eclipse limitation remains : the possibility to have a dir for test files separated from the main src dir, which is an essential feature to let us handling deployments. If you don’t believe me, have a look at this 2008 bug still open: https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708 and its related bugs.
Simply unbelievable.

Java Hints and FindBugs integration

While coding, it is important to have feedbacks from the IDE about the quality of the code and possible errors. NetBeans Java hints is a very reach set of the code checks which helps me to avoid stupid errors and keep high the quality of my work. In addition, NetBeans includes first class support for FindBugs which, again, helps me during coding sessions.

I’ve found NetBeans code quality checks support better than the one available in Eclipse Kepler + FindBugs plugin. More checks and better control on how, for example, disable a FindBugs warning on a line (because it is ok) using an annotation: just a click with NetBeans and by hand with Eclipse.

Coding support: templating, completion,interfaces…

I like NetBeans coding support: code templates (some letters + tab to get most used keywords and structures (see here for some examples), auto-completion, now also using sub words, I can easily jump from an interface to its implementation, the new indent guide lines.

Similar features are available in Eclipse using, for example, the Code Recommenders plugin but I’ve found it quite slow on my machine so I had to disinstall it.

User Interface

NetBeans user interfaces has improved a lot while keeping its strong point: it is easy to use. Windows and menus are easy to find and the full screen mode is very useful on small screens. I really like the color coding setup (Norway Today) which makes code reading a pleasure and the dark skins for working late in the evening.

On the contrary, Eclipse interfaces remains somehow confusing and, my personal opinio, perspectives and workspaces are simply a waste of time.

Improving NetBeans FindBugs integration

In NetBeans 7.4, the FindBugs integration inside the IDE has been improved giving us the possibility to specify additional rules to be checked.

FindBugs has a plugin architecture that let user to add custom rules sets. I usually add FindBugs rules from FBContrib, a FindBugs auxiliary rules set.

There are hundred of rules included in FBContrib. Complete list can be found here.

What is amazing in NetBeans is that not only you can tell the IDE to use the additional rules sets but that the new rules are seamless integrated in the NetBeans interface. For example, FBContrib rules are grouped together with standard FindBugs checks.

First step is to specify the path to the FBContrib jar file (downloaded from the FBContrib website) in the FindBugs configuration (Options –> Editor –> Hints –> FindBugs )

2013-10-22b-fig1

Press “Custom FindBugs Plugins” button.

2013-10-22b-fig2

The “Add” button let us specify one or more additional jar files.

As I already mentioned, the rules included in the FBContrib jar file are integrated with the other native FindBugs rules.

See for example, the rules related to the “Secure” description before

2013-10-22b-fig3

and after FBContrib has been specified:

2013-10-22b-fig4

Both native and FBContrib rules can be enabled and disabled one by one.

With NetBeans Hints, FindBugs and, may be, PMD (see this post on PMD plugin ) all enabled there is a good chance that one problematic line can have more than one warning. In this case I suggest to keep native NetBeans hints enabled and disable the check in the other tools, mainly because NetBeans native checks are faster.

PMD and Maven

After explaining how to use PMD with NetBeans in this post, let me describe how we can directly run PMD using Maven, without the help of an IDE plugin.

We can have two different approaches:

  • invoking the PMD plugin for Maven.
  • using Maven site feature.

First approach. Add the following lines to the project pom (in the build/plugins section):

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-pmd-plugin</artifactId>
  <version>3.0.1</version>
</plugin>

(Of course, maven-pmd-plugin version can vary. See here for last updates).

PMD can be invoked from the command line with the following:

mvn pmd:pmd

which will create a file named target/pmd.xml. XML is the default output format but it can be changed with the format configuration option.

The file contains all violations detected by PMD in all source files found in the project. Test files are not checked in the standard configuration.

By default, only rules from the following rulesets are checked by PMD: java-basic, java-imports and java-unusedcode. We will see later how to control which rules and rulesets should be checked.

In the second approach, PMD is invoked during the Maven site command which is a reporting command. In this case the PMD plugin definition should be placed inside the reporting/plugins section of the project pom.

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jxr-plugin</artifactId>
      <version>2.3</version>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-pmd-plugin</artifactId>
      <version>3.0.1</version>
      <configuration>
        <targetJdk>1.6</targetJdk>
        <rulesets>
          <ruleset>pmd_rules.xml</ruleset>
        </rulesets>
      </configuration>
    </plugin>
  </plugins>
</reporting>

Note: the jxr plugin is useful for source code analysis. The reporting section usually has more plugins that the two shown in the examples.

Here the PMD plugin has been configured with a couple of important parameters: the Java version (targetJdk) and the set of rules and ruleset to be used (rulesets/ruleset).

My usual approach (described in the PMD in NetBeans post) is to define a custom list of rules and rulesets to be checked by PMD. With the Maven plugin we can use the same XML file used to generate the jar file for EasyPMD plugin.

We will have the same check results from NetBeans + EasyPMD and from Maven. Very good.

I usually save the custom rules file in the root of the project with a name like “pmd_rules.xml”. Not so smart name but easy to understand. Of course, it is versioned together with the project files.

Being versioned and saved in the repository let us share exactly the same PMD setup among all development team members. In the pom we have specified a relative path so we will not have problem to access it from different project installation paths.

If the project is multi-module with a parent pom as top dir and the modules in subdirs, I change the configuration as following:

<rulesets>
  <ruleset><strong>..\</strong>pmd_rules.xml</ruleset>
</rulesets>

so running mvn site (or mvn pmd:pmd) on a module will work. Only mvn site on parent pom will not work (but this is less important).

The two approaches I described are not exclusive and they can both be used in the same project. Just remember to have the same configuration in the two pom locations (build/plugins and reporting/plugins).