Java 7 is here…’s about time

Finally after a long time Java 7 is finally here. It has many features.

The most interesting features in my opinion are:

  • NIO 2, which is a real revolting to Java IO
  • Syntax extensions: Automatic resource cleanup(instead of close in finally), String in switch, binary literals, literals separator and shorter generic write
  • new Garbage Collector as default

You can download it from oracles download site for developer:

The default user download site still points to Java 6.

Posted in News | Tagged , , | 1 Comment

Simple LRU or FIFO Cache

There is a very simple way to make a FIFO or LRU cache with the existing LinkedHashMap implementation of the default Java VM made by Joshua Bloch.

The LinkedHashMap already has a method you can override, which defines when to remove the “oldest” entry. With the default constructor this is already a FIFO cache, because it is internal sorted after the insertion order.

To Change to LRU cache you have to change the order of the LinkedHashMap to use the access order. You do this with the other constructor new LinkedHashMap(MAX, 0.75, true). ‘0.75’ is the default value taken from the LinkedHashMap code itself.

The serialVersionUID is only a proposal of FindBugs, because it is a anonymous inner class now with a changed behavior.

    private static final int MAX = 50;

    private final Map cache = Collections.synchronizedMap(
            new LinkedHashMap(MAX) {

                /** Serial UID. */
                private static final long serialVersionUID = 2546245625L;

                protected boolean removeEldestEntry(Map.Entry eldest) {
                    return size() > MAX;

LinkedHashMap is not multithreaded itself. If you use it as a FIFO cache you only need to synchronize all threads for writing. BUT if you are using it as a LRU read (get(), iterating) access is also NOT THREAD SAFE! Even with Collections.synchronizedMap iterating is not handled and therefore not thread safe.

Otherwise a ConcurrentModificationException occurs or in the worst case the cache is in an inconsistent state.

Posted in Uncategorized | Tagged , , , , | Leave a comment

JaCoCo – the new and revolting Java Code Coverage tool

I’ve stumpled across JaCoCo while searching for a possibility to have the code coverage of a multi modul project merged.

JaCoCo is made from the same developer, which made the eclipse plugin EclEmma.

The big advantage (and disadvantage maybe) is that JaCoCo uses a JavaAgent to instrument the classes on the fly. That means no extra instrumentation step is needed beforehand. The disadvantage is, you need to specify the JavaAgant as a JVM parameter.

But imho it’s a far better solution of the instrumentation problem as the old instrument the classes you want coverage for step.

JaCoCo is available for Sonar 2.2. Sadly there doesn’t exist a stable maven2 plugin yet (there is one for sonar and on mojo/sandbox). But it should only be a matter of time 🙂

Posted in Java, Tooling | Tagged , , , , , | Leave a comment

Java 8 contains similar JodaTime API

Java 8 will finally have a new time/date API (It’s about time).

The new API is similar to the Jodatime API (one of the best APIs available).

Posted in News | Tagged , , , | Leave a comment

calendar.equals is evil (especially over RMI)

And again I stumbled across a problem of the date/time API of the JVM.

This time it is the java.util.Calendar object. The Calendar object violates against the

x.compareTo(y)==0       ==         x.equals(y)           recommendation.

It’s not a rule, but as it says in the contract “It is strongly recommended, but not strictly required”.

So what does calendar.equals against calendar.compareTo?

Continue reading

Posted in Java, Problems | Tagged , , , | Leave a comment

The size does matter! (partly)

Have you ever asked yourself, what memory size does an object or a primitive data type really uses?

In general it uses a multiple of WORD.

That means a multiple of 4 byte (32bit) or 8 byte (64bit), if we speak about usually used derived x86-systems.

In detail let’s take a look at the Sun Hotspot VM architecture. Continue reading

Posted in Java, Performance | Tagged , , , | Leave a comment

Autoboxing: Traps and Advantages

What is ‘autoboxing’ some people might ask?

Autoboxing is a feature, which was added in Java 5. Autoboxing is the automatic conversion of primitive data types like int, double, long, boolean to its wrapper Object Integer, Double… and vice versa. So they can be as Object e.g. in Collections.

For example:


In Java 1.4 you had to write for the same result:


(The primitive types must be converted first, because a list can only contain objects.)


  • Less code to write.
    • The code looks cleaner.
  • The best method for conversion is automatically chosen, e.g. Integer.valueOf(int) is used instead of new Integer(int)

Disadvantages Continue reading

Posted in common practice, Java, Performance, Uncategorized | Tagged , , , , | Leave a comment

The costs of String concatenation (+) or what String appending really does

String concatenation (e.g. “fu” + “bar”) are for most developers a mystery what it really does.

The simple case
Something like

System.out.println("fu" + "bar");

will usually be appended at compile time.

So if you decompile this you see:


The final case
What happens if an primitive final variable comes into place?

        final int i = 5;
        System.out.println("fu" + i+ "bar"); 

Results into (eclipse Compiler):

        int i = 5;

Sun Compiler


In the remaining cases

        int i = 5;
        System.out.println("fu" + i+ "bar"); 

Results into (eclipse compiler)

        int i = 5;
        System.out.println((new StringBuilder("fu")).append(i).append("bar").toString());

or into (sun jdk compiler)

        byte byte0 = 5;
        System.out.println((new StringBuilder()).append("fu").append(byte0).append("bar").toString());

We see, that if the result of the appending (I hate that other word) is only a bit unknown at compile time, it uses a new StringBuilder to create a new String.

No goes for String appending
Conversion of something into a String.

        int i = 5;
        String iString = "" + i;

Will create a StringBuilder for converting a int into a String. You have to use the String.valueOf() or the toString method.

Using appending in a loop

String s = "";
for (int i=0; i < 10; i++) {
   s += i; 

This will create a StringBuilder and a String in each loop cycle. You can locate such usage easily with FindBugs. You should manually create a StringBuilder.

For nearly each creation of a String with the common append (+) method a StringBuilder is created.
Creating an Object(here StringBuilder) is expensive, but not so expensive to change the style.
It is important not to use String appending in a loop. Thats a real performance issue.

That’s why something like this, will create 2 StringBuilder. Therefore it is important to append all necessary data in one Statement, otherwise a manual created StringBuilder may be needed.

        System.out.println("fu" + i+ "bar");
        System.out.println(i + "blub");

For logging exists following idiom, which has to be used for most Loggers.

if (logger.isInfoEnabled()) {"fu" + i + "bar");

Because only if info is enabled, a new StringBuilder and String has to be created. On the other hand, if info is enabled the check that info is enabled have to be done twice. One time in our if and the other time in

But there exists other approaches. For example the Logger framework SL4J and the various implementations like logback. They use parametrized logging.

logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

(All decompiled code was previously compiled with eclipse compiler 3.5 and sun JDK compiler Java6u18).

Posted in common practice, Formatting, Java, Performance | Tagged , , , , | Leave a comment

Java Performance Tuning with maximizing Integer.valueOf(int)


or auto boxing(uses internal a valueOf too) the cached Integer values will be used if they are between -127 and +128.

Now I found coincidentally(by looking at the source) on a Java feature or more exactly on a property. With that property you can tune the maximum of the internal Integer cache.

The Properties is called ‘java.lang.Integer.IntegerCache.high’. For each number in the range a Integer value will be created at the beginning of using Integer (it’s initialized in a static).

The feature is only available since some JDK Update versions (I don’t know exactly which).

So you have to ask yourself, can you benefit from a higher cache or are the numbers normally not used?

You save the following memory, if the number is in you cache:

  • the numeric value and its architecture padding (e.g. int needs 8 bytes on 64bit architecture, if there are no other primitive numbers to combine it with)
  • the header of an object, which is 2xWORD. On 32bit 2×4 bytes, on 64bit, 2×8 bytes.

Always use Integer.valueOf. “new Integer” is obsolete.
Do you need numbers higher than 128 often in the application? Is it worth creating the overhead for each Integer between -127 and your max number?
If a value is mandatory you should use a primitive int value, because the value is saved directly with no reference and object overhead.


More details on the memory usage.

Posted in common practice, Performance | Tagged , , , | 1 Comment

The book “Clean Code” from Robert C. Martin

Some weeks ago I read “Clean Code” from Robert C. Martin.

General speaking, I think its guidelines are too extreme, but the approach of the problems are good. For example, he made an 10 line method to a 3 line method, by extracting some lines in other methods.

Most of the time this is the right way, if the difference in abstraction or logic is too big. But if you have so many methods, that you always jump from method to method, you will lose the overview.

You can buy the book at amazon

English version on

German version on

Posted in Books, common practice | Tagged , | 3 Comments