Pro NetBeans

The band Smashmouth played a private concert at the JavaOne 2008 “After Dark” party held Thursday night in Yerba Buena Gardens outside the Moscone Center.

The evening was filled was some great music and food. Check out these pics and videos…

(more…)

NetBeans 5.5 contained a useful tool called the ‘Javadoc Auto Comment’ feature. With the heavy rewrite of the NetBeans internals in version 6.0, the auto comment tool as we knew it was stripped out. This was down with some howling and protests, but at least there was a good reason (and not simply for the heck of it).

Quoted from NetBeans Wiki:

‘We have intended to replace the AC tool for a long time due to its archaic UI and a weak linkage to the editor, where users usually want to edit source code. Changes in the Java model in NetBeans 6.0 forced us to drop the tool immediately and start to implement particular features that will replace the tool as resources permit. So NetBeans 6.0 contains basic editor hints to create or fix javadoc, and the long-awaited ability to generate javadoc skeleton on /** + <Enter> in the open editor as the first step. Of course, the Javadoc Search and the Show Javadoc were adapted to the new model as well.’

NetBeans 6 did contain Javadoc hints and warning so on a class by class basis you could see what was missing or incomplete. NetBeans 6.1 introduced Javadoc code completion. So far so good, but it wasn’t quite as useful as the old Auto Comment tool.

I recently checked the NetBeans 6.1 update center and discovered a plugin listed called Javadoc Analyzer. I had been following several related bug posts at the NetBeans site and knew they had been working on it, but had not had time to try it out.

Download it from the update center and you’re ready to use it with no configuration.

(more…)

The JavaOne Pavilion (basically a trade show and vendor demo space) is always an interesting experience. It’s a mix of IT geeks running around seeking out swag, vendors hawking the next great widget or framework, and interesting “attractions” littered throughout the space.

The obvious things you notice heading up the main aisle are the big sponsor vendors such as Intel, Oracle, etc.

Ever present and ready to discuss a technology…

Then there are always cool technologies on display that utilize Java in some way such as the Perrone Robotics autonomous vehicle.

Seen here are some of the electronics it runs in the trunk :

And of course, always something weird. This live action machine shot marbles through a series of pipes to test and try out real time Java technology.

And finally, and perhaps most bizarre, Intel’s oxygen bar. They touted the slogan as something similar to ‘ since oxygen is essential to life, so is Intel’ [reletive to computing life]. The picture below shows bubbling bottles of 90% oxygen with aromatherapy flavors mixed in. You were given a personal nose tube, slightly uncomfortable, but not too bad given the unique experience. If you haven’t tried it you should definitely try to stop by before the end of ther week.

After a few hours of walking the floor, gathering brochures, and scoping out specific vendors, I enjoyed I few beers and some food as part of the Pavilion Welcome Reception. I’m still amazed at how long the lines get at these things, but hey, it’s free beer at an IT conference!

Bug fixes in JDK 1.6.0.6.

The NetBeans Unit Tests Code Coverage Plugin has been around for several versions of NetBeans. It measures code coverage statistics and displays annotated & highlighted lines in the Source Editor in each class that were executed by unit tests. In a recent release of the plugin, it also provides a report that shows overall, package, and class-level statistics. This article provides a quick overview of code coverage, why it is important, and what the NetBeans Unit Tests Code Coverage Plugin provides. I’ll also cover some pros/cons of the plugin.

Overview of Code Coverage

To quote myself from Chapter 16, Using Code Coverage Tools, of my book, Pro NetBeans IDE 5.5 Enterprise Edition (Apress, March 2007) :

You know that it is important to write accurate and effective tests for your code. But how do you measure the effectiveness of your tests? In a perfect world, you would write a test for every class, every method, and every line of code. Depending on the complexity of your code base, this may be easy or extremely difficult.

How do you know when you’ve written enough tests? If you have 200 tests for your code, and they all pass, then you’re finished, right? Not necessarily. You’re finished writing tests only when you know for a fact how effective your tests are. Since testing often involves visual analysis by programmers and code-based test cases, it’s difficult to know if 100 percent of your code has been tested. This is where code coverage tools come into play.

The first and obvious benefit of using a code coverage tool is being able to measure the coverage of your test cases (and, by association, the test case effectiveness). Untested code can lead to bugs, and bugs lead to many other problems.

Code coverage tools also help you identify areas in your code that are dead or unreachable. Suppose you have written test cases for all the public methods in your code. If your code coverage tool identifies one or more methods with private-level access that have never been executed, then you may be able to remove those methods from your source code. You can then use the NetBeans Safely Delete refactoring to check the method and make sure it is not called by any other code.

A good code coverage tool not only tracks if each line in each method was executed, but also how many times each line was executed. Using this data and the knowledge of what lines were and were not executed, you can understand the flow of program functionality and rearrange code blocks accordingly.

The NetBeans Unit Tests Code Coverage Plugin does not provide access to some of the information mentioned above (such as number of times each line was executed). However, it provides enough of the basic features you will need to be quite useful. Internally, the plugin depends on the Emma code coverage library.

Code Coverage tools like Emma and Cobertura (one of my personal favorites) typically work by instrumenting classes (inserting extra byte codes).  The instrumented classes are then executed instead of the original un-instrumented classes. The inserted byte codes in the instrumented classes then collect different bits of data and deposit them in a file for later analysis.

Getting Started

As of the official release of NetBeans 6.1 Beta, the update centers contained a slightly older version of the code coverage plugin. I would suggest going to the official NetBeans code coverage plugin site and download it using the prominently displayed button labeled “Download Code Coverage Plugin”.

Use the Plugins Manager to install the NBM file. Go to the Downloaded tab and click the Add Plugins button. Accept the license, click Next a few times, and you should be all set.

Once installed, you need to activate code coverage on a per-project basis. For this article, I have a standard J2SE Java Library project. In the Projects window, right-click the project name, and you should see a Coverage submenu. It contains the following options :

    Activate Coverage Collection: When clicked activates code coverage collection for the selected project. This will also generate the file nbproject/coverage.properties and coverage/emmascript.xml, which are covered below.

    Deactivate Coverage Collection: When clicked deactivates code coverage collection.

    Show Project Coverage Statistics: When clicked displays a tab in the Source Editor showing the accumulated statistics collected by the plugin for the selected project.

 Files Generated By Activating Coverage Collection

As previously mentioned, several files are generated by activating coverage collection.

The nbproject.properties file contains several parameters used by the plugin such as :

    coverage.activity=ON
    project.type=java
    coverage.templateFile=coverage/template.emma
    coverage.coverageFile=coverage/coverage.emma

The first parameter obviously indicates whether the coverage collection is active or inactive. The second parameter identifies the type of NetBeans project, and the last 2 parameters identify the paths to specific files used by the plugin.

The coverage/emmascript.xml file contains Ant targets for executing the instrumentation of the project class files.

<?xml version=”1.0″ encoding=”UTF-8″?>
<project basedir=”.” default=”echoit” name=”Coverage Tasks”>

    <target name=”echoit” description=”test target”>
        <echo message=”Test succeeded.”/>
    </target>     
    
    <target name=”instr” description=”Instrumenting jars”>
        <echo message=”Instrumenting started.”/>
       
        <java classname=”emma” fork=”true”>           
            <classpath >
                <pathelement location=”${emma}”/>
            </classpath>
            <arg line=”instr -verbose -m overwrite -cp ‘${jarfiles}’ -outdir ‘${output.dir}’ -outfile ‘${output.dir}/template.emma’”/>
        </java>
        <echo message=”Instrumenting done.”/>
    </target>
    
</project>

 The instr target runs the main emma class passing it several arguments to overwrite the application JAR file with a JAR file of the project’s instrumented classes.

Creating Sample Code

First, create a simple Java Class like this :

public class StringUtils {

    public static String tryIntToString(int numLoops) {

        StringBuffer sb = new StringBuffer();

        for (int i = 0; i < numLoops; i++) {
                sb.append(String.valueOf(i));
        }
        return sb.toString();
    }
}

 It is basically a ‘hello world’ class that takes in a counter variable, numLoops, instantiates a StringBuffer, and loops appending an int converted to a String into the StringBuffer. The method then returns the value of the StringBuffer.

To test this method, create a JUnit test. Right-click the class listing in the Projects window and select Tools >> Create JUnit Tests (or press Control+Shift+U). Select your preferred JUnit version (4.x in this case) and the various other JUnit settings you are prompted for. Once created, I implement a basic test case for the StringUtils class passing in a value and setting the expected return.

public class StringUtilsTest {

    public StringUtilsTest() {
    }

    @BeforeClass
    public static void setUpClass() throws Exception {
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
    }

    @Before
    public void setUp() {
    }

    @After
    public void tearDown() {
    }

    @Test
    public void testTryIntToString() {
        System.out.println(”tryIntToString03″);
       
        int numLoops = 10000;

        String result = StringUtils.tryIntToString(numLoops);

        int expectedResult = 38890;
       
        assertEquals(expectedResult, result.length());
    }
}

(more…)