just wrote the first batch of code for lego4j

Would you like to be able to write code like this ?

public class Foo {
  @RetryOnException( E.class, 1 )
  public String bar( int arg1 ) throws E {
    return doSomeThingThatMightThrowE( arg1 );
  }
}

instead of having to write something like this:

public class Foo {
  public String bar( int arg1 ) throws E {
    int retries = 0;
    while (true) {
      try {
        return doSomeThingThatMightThrowE( arg1 );
      }
      catch (E e) {
        if (retries < 5) {
          continue;
        }
        throw e;
      }
    }    
  }
}

This is what lego4j is about, creating a library of lightweight aspects to encapsulate local concerns programmers encounter while writing a generic Java application.

TDD and a code coverage tools

Arguments about how important is the use of code coverage tools are not scarce. I don't want to participate in any of those. I merely want to show that using a coverage tool while doing TDD will increase the probability of not leaving stones unturned.

The generally recommended way to do TDD looks like something along these lines:

1 - write a failing test case
2 - write the simplest code modifications that will make the test pass
3 - we are done if can't think of more test cases to write
4 - go back to (1)

If we absolutely stick to the recommended way, chances are that our test cases cover the totality of the code we write to make them pass. Unfortunately I would adventure to say that somehow in step 2 we tend to write more code that we should, and as a result we end up with code that is not tested.

Ending up with code that is not tested is precisely one of the things TDD tries to make sure we avoid.

Good thing is that with the help of a code coverage tool it is very easy to make sure we don't have code that is not tested. All we have to do is modify step 3 to look like:

3 - we are done if can't think of more test cases to write, and the code coverage of the class we are actually writing is 100% when all the test for that class are run.

---
EclEmma, a Java Code Coverage Plugin For Eclipse

XMLUnit

About a month ago a fellow computer programmer asked me if I knew of a library to compare xml/html fragments. In a nutshell he needed to be able to know if two xml/html fragments were the same, even if the attributes and/or inner elements were not in the same order. Today while reading the dzone.com feed I found there is a library that meets hi needs. It's a not a surprise at all this library is name XMLUnit.

how to implement a persistent queue on top of a sql db

JPMQ An Advanced Persistent Message Queuing Service (1998)

software transaction memory (STM)

links to STM related papers and implementations for Java and .Net

storing unicode characters with mysql/jdbc

article describing how to store unicode characters in mysql, and how to ensure they display in html pages.

http://www.javaworld.com/javaworld/jw-09-2004/jw-0906-unicode.html?page=1

timed invocation aspect

In the interview Joshua Bloch on Closures, Resource Management, Google, Joshua Bloch mentions, and praises, a facility a google employee created to timeout method invocations. A couple of years ago I had the need for such utility and ended up creating it. That code is nowhere to be seen now, as my employer has changed a couple of times since then.

Most certainly this is a very handy facility in everyday programming. It will be very nice if the "method timeout invocation" concern could be easly integrated into the code using aspects!

@timeout(millis=1000)
public void foo() {
...
}

Where:

/**
 * Times out a method invocation. If any of the methods matched by the pointcut invocationToTimeOut() has not  
 * returned after the specified timeout, the unchecked exception InvocationTimeout will be thrown.
 */
aspect TimeoutInvocation {
...
}