This is the second part of the "Howto write a FindBugs Bug Detector" (see the first part here). To understand why one would write the kind of detector mentioned here, you should read the first part if you do not already know it.

Last time I presented a detector that is able to detect static fields of the types java.util.Calendar and java.text.DateFormat. While declaring fields like this may be suspicious, there is not necessarily something wrong with the code. The real danger comes from calling methods on suchlike fields, especially if they are not synchronized to protect them against concurrent access. So in this article we will extend and improve the existing detector to cope with this problem.

Something to chew on

This a simple class that uses a static Calendar instance. It does not …

Ever since we switched out build process from Java 1.4 to Java 5 (1.5.0_09) we have seen FindBugs crash with an OutOfMemoryError when started from ant. The whole thing is running under RedHat Enterprise Linux 4. The output is always the same:

[findbugs] Running FindBugs...
[findbugs] Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested 134217736 bytes for Chunk::new. Out of swap space?

Our first attempts to increase the heap size with the -Xmx VM parameter did not help. We suspected the newer FindBugs release we had installed roughly at the same time, but this turned out to be wrong, because newer and older versions showed the same behaviour.

Armed with the fresh knowledge about the SAP Memory Analyzer just learned at jax.07 I …

Ever since we switched out build process from Java 1.4 to Java 5 (1.5.0_09) we have seen FindBugs crash with an OutOfMemoryError when started from ant. The whole thing is running under RedHat Enterprise Linux 4. The output is always the same:

[findbugs] Running FindBugs...
[findbugs] Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested 134217736 bytes for Chunk::new. Out of swap space?

Our first attempts to increase the heap size with the -Xmx VM parameter did not help. We suspected the newer FindBugs release we had installed roughly at the same time, but this turned out to be wrong, because newer and older versions showed the same behaviour.

Armed with the fresh knowledge about the SAP Memory Analyzer just learned at jax.07 I …

Saw this table definition in a system I was working on:

CREATE TABLE session_role (
Session_sessionId bigint(20) NOT NULL,
activeRoles_roleId varchar(255) NOT NULL,
PRIMARY KEY(Session_sessionId,activeRoles_roleId),
UNIQUE KEY activeAccounts_actorId (activeRoles_roleId),
KEY `FK38CC06CCF5B03D50` (Session_sessionId),
KEY `FK38CC06CC4085AE4` (activeRoles_roleId),
CONSTRAINT `FK38CC06CC4085AE4` FOREIGN KEY (activeRoles_roleId)
REFERENCES role(roleId),
CONSTRAINT `FK38CC06CCF5B03D50` FOREIGN KEY (Session_sessionId)
REFERENCES session (sessionId)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

This is four indexes for a two-column table! Of course nobody has actually written this, this is generated by JBoss/Hibernate, with a MySQL database used for storing data. Be very careful with code generators....

Some words in advance...

Recently I wrote about multi-threading problems with java.util.Calendar and java.text.DateFormat. The last sentence was So maybe it is time to search your code for all static usages of the Calendar and various ...Format classes, before you start getting strange errors.

Searching code is not very practical, especially if you do it manually. Everyone knows you can look at code for hours, without seeing an problem - and as soon as it has reached production systems it starts breaking up in various ways :-)

Fortunately smart and reknown people have devised ways of making the computer look for bugs automatically. Amongst others, …

Some words in advance...

Recently I wrote about multi-threading problems with java.util.Calendar and java.text.DateFormat. The last sentence was So maybe it is time to search your code for all static usages of the Calendar and various ...Format classes, before you start getting strange errors.

Searching code is not very practical, especially if you do it manually. Everyone knows you can look at code for hours, without seeing an problem - and as soon as it has reached production systems it starts breaking up in various ways :-)

Fortunately smart and reknown people have devised ways of making the computer look for bugs automatically. Amongst others, …

Another anecdote from the ongoing Java 1.4 to Java 5 transition... Last time it was an incarnation of "Favor composition over inheritance". This time I am writing about a multi-threading issue which can be equally subtle and difficult to pinpoint.

On the test systems we have set up we observed two strange types of exceptions at seemingly random times and in various different areas of the application. They looked similar to the following two patterns:

• java.lang.ArrayIndexOutOfBoundsException: 432
          at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2024)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1941)
          at java.util.Calendar.setTimeInMillis(Calendar.java:1066) …

Another anecdote from the ongoing Java 1.4 to Java 5 transition... Last time it was an incarnation of "Favor composition over inheritance". This time I am writing about a multi-threading issue which can be equally subtle and difficult to pinpoint.

On the test systems we have set up we observed two strange types of exceptions at seemingly random times and in various different areas of the application. They looked similar to the following two patterns:

• java.lang.ArrayIndexOutOfBoundsException: 432
          at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2024)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1941)
          at java.util.Calendar.setTimeInMillis(Calendar.java:1066) …

The NDB/Connectors have added support for Ruby, as well as Asynchronous Transaction support for Java, Python and Perl.

The Ruby support, of course, means that new you can interact with your MySQL Cluster installation using the NDBAPI from all your Ruby code.

The async stuff is especially cool, because it means you can send transactions to the Cluster and get responses by way of callbacks defined in the connector language. So you can do something like this:

class testaclass(object):

  def __init__(self, recAttr):
    self.recAttr=recAttr

  def __call__(self, ret, myTrans):
    print "value = ", self.recAttr.get_value()

#snip

myTrans = myNdb.startTransaction()

myOper = myTrans.getNdbOperation("mytablename")
myOper.readTuple(ndbapi.NdbOperation.LM_Read)

myOper.equal("ATTR1", 245755 )

myRecAttr= myOper.getValue("ATTR2")

a = testaclass(myRecAttr) …

When I heard the JavaPosse interview about Groovy I became really interested in it. The fact that it offers a scripting language based on the JVM and that it can be seamlessly integrated with Java fascinated me.

So I decided to buy the Groovy in Action book and try it out.

This is my first attempt at something that might become useful later:

def foundtypes = [:]
def sum = 0              
def stats = ""

bugs = new XmlSlurper().parse(new File("/home/ds/findbugs.xml"));

bugs.BugInstance.findAll { instance -> 
    instance.-AT-category =~ 'CORRECTNESS|BAD_PRACTICE|MT_CORRECTNESS'
}.each { instance ->
 type = instance.@type-DOT-toString()
 foundtypes[type] = foundtypes.get(type,0) + 1
}
foundtypes.each { sum += it.value }

println "Found ${foundtypes.size()} …