The download from AppDynamics Lite’s website was done immediately. Setup was also easy, just a line to add to the app-server startup script and launching a java-app. All good described on the doc-website.

Behind the trenches a Jetty-server is started which serves the info to the webclient interface and collects the data from the applications.

Using the webclient to analyze data is rather intuitive, if you are used to performance analyzing tools.

My task was to discover why a request was taking longer than the same request in a previous release. Well after some configuration of the call-graph exclusion/inclusion list I found that some 90% of the processing time was spent writing the data to the socket-stream. This puts a “infrastructural change” (java-version, app-server,…) on the table as the main suspect. As application development team, there is not much one can do about that… case closed. In this task I did not need to check on memory consumption, which is not served by this particular analyzer. Normally the amount of time spent in low-level libraries like java.* is not reported seperately, but this can be configured. In my case I had to include “java.net.*” and “java.io.*” because the exclusion of “java.*” cannot be overridden. An inconvenience that can be solved in 2 minutes… If you do not make some errors in the configuration. I screwed up that part of the config and as I had not done an export before (backup, me???) I had to reinstall the performance analyzer. 15 minutes and I was up and running again.

Tu put in a nutshell:
A usefull addition to my toolbox.

Thanks to the people at AppDynamics for putting the price tag of the lite version so exceptionally low: for free.

/**
 * Assert not null.
 * @param object the object
 * @param  element type
 * @return the not null object
 */
public static  T assertNotNull(T object) {
	if (object == null) {
		assertNotNull(object, "");
		throw thisLineShouldNeverBeReached();
	}
	return object;
}
/**
 * Assert not null.
 * @param object the object
 * @param msg the msg
 */
public static void assertNotNull(Object object, String msg) {
	if (object == null) {
		throwRuntimeException("assertion: object is null but was expected not to be null. \n"
				+ msg);
	}
}

well at least it is a generic method

The commenting is also from the production code… Hell of a expert developer.

A few searches revealed that the SAX-Api has a nasty behaviour: it does not garantee rules for buffer-handling. This is to be done by the client-application.

Instead of relying on complete data delivered to the characters method my colleague had to buffer the data hiomself. Using a bit of sample code it was an easy fix… but you first have to get the notion of this kind of reason for an otherwise seemingly unrelated problem…

This page shows the sample code that we recycled:

package some.pkg;
public void characters(char buf[], int offset, int len)
throws SAXException
{
  String s = new String(buf, offset, len);
  if (textBuffer == null) {
    textBuffer = new StringBuffer(s);
  } else {
    textBuffer.append(s);
  }
}

The textBuffer can be reset in the startElement method.

I have joined the JSFUnit team to help out with the static analysis package. One of the special features of JSFUnit has been orphaned for some time.

A quick look into the compareTo code showed, what research into the Javadoc confirmed, even though not at the expected place.
The Javadoc for BigDecimal.compareTo(java.math.BigDecimal) did not reveal any pitfalls or precoonditions. Neither did the Javadoc for Comparable.compareTo(T). Nothing about preconditions…
Only in the class-javadoc for Comparable an innocent sentence revealed the source of the problem. Whereas in other places null is just a special case of an Object, Comparable follows this credo:

Note that null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false.

So another lesson learned. A pity that this precondition is not documented somewhere. NullPointerException obviously is a RuntimeExcpetion and as such does not need to be documented. But when a method should repsond with such a runtime expcetion to a precondition, this behaviour should be documented as a precondition to the method.

Check these two methods, and try to predict the outcome:

  private void sample1() {
    BigDecimal one1 = new BigDecimal("1");
    BigDecimal one2 = new BigDecimal("1.000");

    System.out.println("Comparing new BigDecimal(\"1\") and BigDecimal(\"1.000\"):");
    if (one1.equals(one2)) {
      System.out.println("  equals() indicates equality...");
    } else {
      System.out.println("  equals() indicates different values...");
      if (one1.compareTo(one2) == 0) {
        System.out.println("    but comparesTo() thinks the two BigDecimals are equal.");
      } else {
        System.out.println("    and comparesTo() thinks the same.");
      }
    }
  }

  private void sample2() {
    BigDecimal one1 = new BigDecimal(1);
    BigDecimal one2 = one1.setScale(3);

    System.out.println("Comparing new BigDecimal(1) and BigDecimal(1).setScale(3):");
    if (one1.equals(one2)) {
      System.out.println("  equals() indicates equality...");
    } else {
      System.out.println("  equals() indicates different values...");
      if (one1.compareTo(one2) == 0) {
        System.out.println("    but comparesTo() thinks the two BigDecimals are equal.");
      } else {
        System.out.println("    and comparesTo() thinks the same.");
      }
    }
  }

Looking into the Javadoc (Java 5) of BigDecimals gave a first hints:

Note: care should be exercised if BigDecimal objects are used as keys in a SortedMap or elements in a SortedSet since BigDecimal’s natural ordering is inconsistent with equals. See Comparable, SortedMap or SortedSet for more information.

and

Compares this BigDecimal with the specified Object for equality. Unlike compareTo, this method considers two BigDecimal objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method).

That definitely was a bit unexpected, but at least documented.

The first installation attempt did fail, because the license key sent by mail was distorted by some element in the mail-chain. A call or an email will supply you with a test-file with a working license key.
Once the eclipse plugin is installed and the license activated, you will find a new eclipse perspective and a sample project with the usual test-sample (a call to a famous search engine). Another nice touch is the creation of a new test-class. The plugin immediately offers to enter “record mode”…

to be continued

package some.pkg;
public class CopyParameters {
}

The package this class was found in has already been declared production ready by the developer. Looking for checkstyle violations (missing type javadoc) let us stumble on that class.

package some.pkg;
import java.io.Serializable;
public class Void4MyProject implements Serializable{
  public static final Void4MyProject NULL = null;
  private Void4MyProject() {
  }
}

I never had the need to have a serializable null-instance. Simply beautifull and creative.

Just for playing… how is it used…

  final protected IAccessor subTable() {
    return new IAccessor() {
      public String getId() {
        return SUB_TABLE;
      }
      public Class getStaticType() {
        return Void4MyProject.class;
      }
      public Void4MyProject getValue(T parent) {
        return null;
      }
      public void setValue(T parent, Void4MyProject value) {
        // nothing to do
      }
    };
  };

Here I consider it a big NoNo that the defined instance of Void4MyProject is not even used.