Windows Vista SP1 Released Today

Get it from http://www.microsoft.com/downloads/details.aspx?FamilyID=b0c7136d-5ebb-413b-89c9-cb3d06d12674&DisplayLang=en.

I had the RC1 installed and so when i tried installing the SP1 release then it gave me an error that SP1 is already installed.

So, you must remove all previous version of SP1 before upgrading to the next.

Control Panel > Programs and Features > Installed Updates (upper left corner
under Tasks) > Highlight "Service Pack KB936330" > Uninstall

It will take awhile, there will be 2-3 reboots. Then you can install the
new version.

Follow the above steps and then go to the given link above (for MS download center for Vista SP1) and download and install the SP1 here. To know the features of SP1 please refer to this article.

Using SAP Memory Analyzer for Java memory leak detection

[Click to watch video of using SAP Memory Analyzer]

I recently had opportunity to use the SAP Memory Analyzer tool for analyzing an HPROF heap dump generated on OutOfMemory error in code. I found that its an excellent and user friendly tool for job of memory leak analysis with good documentation. Though i generally preferred to use JHAT for heap walking but i realized that this SAP tool is much more intuitive and memory leak detection in code was a breeze. The above video tutorial talks about using the version 1.1.1 (which happens to be the latest at this time). Highly recommended.

Emma vs Cobertura

The 2 open source Java code coverage tools that are the best among the lot are cobertura and emma. Both have their own pros and cons.

Cobertura - http://cobertura.sourceforge.net/
vs
Emma - http://emma.sourceforge.net/

Points borrowed from: http://raibledesigns.com/rd/entry/emma_vs_cobertura_for_code
Video : http://video.google.com/videoplay?docid=820584080702226910

Emma:
1. Stats on both class and method coverage
2. Partial/fractional line coverages is unique trait - shown in yellow when there are multiple conditions in a conditional block like if (x < 0 and x > 10) and say x > 10 never gets executed this is shown in yellow. This is important feature which lets us determine if the tests cover all conditions of such more than one conditions conditional blocks.
3. Not being actively developed.
4. Stricter code coverage.
5. Integration with Eclipse available - http://www.eclemma.org/
6. Better documentation than cobertura.
7. Instrumentation process is faster than cobertura.
8. Standalone library and does not have any external dependencies.
9. Common public license 1.0 friendlier that GPL.

Cobertura: (since 2002)
1. GPL'd version of JCoverage (which is commercial). Project older than Emma.
2. Prettier reports.
3. Actively developed.
4. Branch/block and line coverages only - no class or method level coverage.
5. How many times a line has been executed - unique about cobertura.
6. <cobertura-check> where one can specify percentage of coverage that's a MUST or else build fails.
7. Data merge feature - good for QA labs... for merging coverage data to prepare historical trend graphs. Emma also supports it now but it seems its better with cobertura. Project long coverage collection possible.
8. Depends on other third party libraries.

Common factors in both of these code coverage tools:
1. bytecode instrumentation.
2. reports are filterable so you can tell what needs to be evaluated for code coverage.
3. offline instrumentation (most recommended approach) - separate instrument/execute/report tasks – this is what we adopted. The other approach is on-the-fly instrumentation.
4. ant integration.
5. testng integration.

The above information can be used in deciding about the right tool for your project. We went for Emma as it seemed to have good enough reports and was fast. I did not get a chance to experiment with Cobertura but will surely try it out soon.

Using TestNG with Emma for automating test code coverage report generation

TestNG and Emma can be used together to automate the generation of code coverage report after every test run in the ANT builld script.
Following ant build script snippet shows how both tools are used together for this important metrics collection.

To run it:
$ ant emma test

This will generate the code coverage report for the TestNG tests in ./coverage directory (where, basedir = ".").

<!-- output directory used for EMMA coverage reports: -->

<property name="coverage.dir" value="${basedir}/coverage" />

<!-- directory that contains emma.jar and emma_ant.jar: -->
<property name="emma.dir" value="${lib}/emma" />

<!-- path element used by EMMA taskdef below: -->
<path id="emma.lib">
<pathelement location="${emma.dir}/emma.jar" />
<pathelement location="${emma.dir}/emma_ant.jar" />
</path>

<!-- this loads <emma> and <emmajava> custom tasks: -->
<taskdef resource="emma_ant.properties" classpathref="emma.lib" />


<property environment="env" />
<path id="classpath">
<fileset dir="${lib}">
<include name="**/*.jar" />
</fileset>
</path>
<!-- 6. CODE COVERAGE initialization. -->
<target name="emma" description="turns on EMMA's instrumentation/reporting">
<property name="emma.enabled" value="true" />

<!-- this property, if overriden via -Demma.filter=<list of filter specs>
on ANT's command line, will set the coverage filter; by default,
all classes found in 'run.classpath' pathref will be instrumented:
-->
<property name="emma.filter" value="" />
</target>

<!-- 7. TEST the application. -->
<taskdef name="testng" classpathref="classpath" classname="org.testng.TestNGAntTask" />


<!-- EMMA ANT tasks are implemented as pseudo-nested tasks: <emma>
container task can contain an arbitrary sequence of <instr>,
<report>, and <merge>. Both the container tag and each of the nested
elements support an optional boolean 'enabled' attribute: setting it
to 'false' will no-op the element. This is convenient for
sandwhiching normal build tasks between EMMA tasks such that coverage
instrumentation and reporting could be enabled on demand. -->

<target name="test" description="execute testng tests" depends="dist">

<emma enabled="${emma.enabled}" verbosity="verbose">
<instr instrpath="${build}" mode="overwrite" metadatafile="${coverage.dir}/metadata.emma">

<!-- note that coverage filters can be set through nested <filter>
elements as well: many of EMMA setting are 'mergeable' in the
sense that they can be specified multiple times and the result
is a union of all such values. Here we are not merging several
filters together but merely demonstrating that it is possible:
-->
<filter value="${emma.filter}" />
</instr>
</emma>

<javac srcdir="${test.src.dir}" destdir="${build}" classpathref="classpath" deprecation="${compile.deprecation}" />

<testng classpathref="test.classpath" outputDir="${testng.report.dir}" sourcedir="${test.src.dir}" haltOnfailure="true">
<xmlfileset dir="${test.src.dir}" includes="testng.xml" />
<jvmarg value="-Demma.coverage.out.file=${coverage.dir}/coverage.emma" />
<jvmarg value="-Demma.coverage.out.merge=false" />
</testng>

<!-- if enabled, generate coverage report(s): -->
<emma enabled="${emma.enabled}">
<report sourcepath="${src}" sort="+block,+name,+method,+class" metrics="method:70,block:80,line:80,class:100">
<!-- collect all EMMA data dumps (metadata and runtime)
[this can be done via nested <fileset> fileset elements
or <file> elements pointing to a single file]:
-->
<fileset dir="${coverage.dir}">
<include name="*.emma" />
</fileset>

<!-- for every type of report desired, configure a nested
element; various report parameters
can be inherited from the parent <report>
and individually overridden for each report type:
-->
<txt outfile="${coverage.dir}/coverage.txt" depth="package" columns="class,method,block,line,name" />
<xml outfile="${coverage.dir}/coverage.xml" depth="package" />
<html outfile="${coverage.dir}/coverage.html" depth="method" columns="name,class,method,block,line" />
</report>
</emma>

</target>