Generate HTML from Colored Terminal for Sharing Diffs

The version control system git has the nice feature git diff --color-words which shows on a word by word basis the changes, coloring new words green and deleted ones red. The script ansi2html.sh converts a colored xterm output to html. This way you are able to share your diffs with others: hello world example. For $latex \LaTeX$ you may use latexdiff, which highlights the changes in the generated PDF/DVI-output.

Unit Test Your Persistence Layer

This post is an addition to the post Unit Test Your DB Schema and Named Queries. It shows how to use the TestNG Annotations in order to simulate a lightweight EJB container enabling you to test your persistence layer (DAO, entity classes and similar). If you are using JBoss 6 you may use the embedded EB container. EJB3Unit supports testing Enterprise Beans, too. But I couldn’t get the latter to run smoothly and I do not use the former, yet. So if you are still tied to the old Java EE 5 world you might benefit form this solution.
Read More

Script Your Remote Session Beans with Groovy

A JavaEE application with a multi-tier application generally has a presentation layer running in a servlet engine, a business logic layer running in a EJB container and a persistence layer facilitating JPA. During the development often there are occasions where a new functionality in the business logic (called backend from now on), which has no corresponding code in the presentation layer (let’s name it frontend), yet. So, what you need is a way to try out your code. This post shows you how to use the groovy shell to connect via JNDI to your remote session beans and call them in order to test your application fast. You may use it for a fast monitoring or maintenance API to your system, too. The groovy code of your efforts to test your code (monitor your application) may even be read from the history of the groovy shell and compiled into byte code. This code may be called from a test case or in a monitoring software (like nagios).
Read More

Organize Your Named JPQL Queries

Named queries have some nice properties. They are precompiled and therefore faster than their “normal” counterparts, encourage to use named parameters, make your code easier to read and avoid messing up your code with string concatenated queries. A nice addon is, that named queries are validated during the creation of the persistence unit. If you have a unit test (see unit test db schema and named queries), checking whether the entities represent a valid DB Schema, the named queries are validated, too. So, there will be syntactical as well as some static analysis (e.g. “exist all referenced entities?”) during the test phase, before your application is even packaged.
Read More

OR-Mapper and the ‘many queries’ problem

Applications using an OR-Mapper like Hibernate or OpenJPA are reckoned as to be slow. This observation is true, since there is an overhead compared to using hand-crafted and optimized SQL-Queries and Database structure. But the overhead has not to be as big as it is often observed in applications with entities. There is a lot of potential optimizing such a system. Unfortunately you won’t be able to circumvent quarelling with the underlying database, although a persistence layer is all about abstraction. Not bringing into mind what happens in your persistence layer will lead to really bad performance. Read More

Interface with self-referencing generic type

The Comparable interface has a generic type parameter, which is used for self-referencing in subclasses (I don’t know any other use for it) :

public interface Comparable<E> {
  public int compareTo(E other);
}

public class ComparableInteger implements Comparable<ComparableInteger> {
  private int val;
  public void compareTo(ComparableInteger other) {
    return val > other ? 1 : (val == other ? 0 : -1);
}

But what if you need to access methods of the interface on the generic type parameter? Then you can do a recursive declaration of the type parameter. Read More

Access javadoc programmatically

This tar ball (export-doclet-0.1.tar.gz) contains two maven project artifacts. It shows how to access the javadoc information of a project during the maven lifecycle phase ‘generate-sources’, traverse it, fill a Java object structure (export-doclet-api), marshal it to XML and include it into the jar of the artifact. Later on, you will be able to unmarshal the javadoc information. The export-doclet-api is oriented towards the doclet-api and the reflection-api and may therefore be familiar to you.
Read More