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;

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

BEWARE of MULTITHREADING
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 🙂

http://www.eclemma.org/jacoco/

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).  http://joda-time.sourceforge.net/

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

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:

list.add(5);

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

list.add(Integer.valueOf(5));

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

Advantages?

  • 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:

System.out.println("fubar");

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;
        System.out.println("fu5bar");

Sun Compiler

        System.out.println("fu5bar");

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;
        System.out.println(iString);

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.

Conclusion
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()) {
     logger.info("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 logger.info().

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)

With

Integer.valueOf(intValue)

http://java.sun.com/javase/6/docs/api/java/lang/Integer.html#valueOf%28int%29
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.

Conclusion:
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.

Update1:

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 amazon.de

German version on amazon.de

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

SimpleDateFormat in multithreaded environment

SimpleDateFormat is wide known in Java as the default tool to convert a String to a (java.util.)Date and vice versa.

Usually you would think you can make a SimpleDateFormat static, like:

private static final SimpleDateFormat DATE_FORMATTER = new SimpleDateFormat("ddMMyyyy");

Because we think, that the formatter just contains the formatting rules, which is not the case.

The methods on SimpleDateFormat are not thread safe , because intern it is based on a Calendar attribute, which will be created and modified.

What’s the solution for the problem?
Generally you must either synchronize or always make a new SimpleDateFormat for each conversion.

Other formaters I stumbled across are the multi threaded safe DateTimeFormat of JodaTime or FastDateFormat from apache-commons.

What about an object pool? Well there can be performance gains here (even if they are minimal), but even Joshua Bloch said in his book “Effective Java” not to make pools. Because most JVM implementations are fast enough at reclaiming simple Objects.

Conclusion

Ask yourself. Are you handling with Calendars and Dates often in your application? Then JodaTime surely benefit your overall application. Because it is a far better Time/Date implementation instead of the JVM internal. In Java 8 there will be a new Date/Time inspired by JodaTime.

Do you already have apache-common or do you see many additional benefits in the library for your overall application, than this library may be your choice.

In the end, if you want no additional library, than the only reasonable choice is just to always make a new SimpleDateFormat for every conversion. If you make it synchronize, it work too without a problem, but it may block your throughput and synchronize can always lead to deadlocks and a synchronized block doesn’t look well in the code 🙂 .

Update 5:
Added information to Java 8.

Posted in Formatting, Java, Multi threading | Tagged , , , , | 1 Comment

Hello world!

There has to be a Hello World 😀

public final class HelloWorld {
    private HelloWorld() {
    }

    public static void main (String args[]) {
        System.out.println ("Hello, World!");
    }
}
Posted in Uncategorized | Leave a comment