On lazy initalization

I’ve been adding this code Stackoverflow a short while ago, but I do like to make my answer an own blog post.
Read more…


Speed-Testing DirectByteBuffers and the Unsafe class against plain old arrays

April 9, 2017 Leave a comment

I’ve long been a fan of Martin Thompson’s talks on youtube, and blogs on the “Mechanical Sympathy” blog. The more you dig into the world of people who care about high performance in Java, you will inevitably come across the technique to optimize memory access using direct ByteBuffers and the sun.misc.Unsafe class. But how so they stack up? Is it true that using them will give you more performance in general?
Read more…

Categories: Tuning Tags: ,

Towards a scalable Bloom filter

August 7, 2016 2 comments

Recently I have given the tool „jdeps” a test ride. It’s a tool that is included with Java 8 and extracts packet dependencies of usual java code from jar files, classes, etc. It turned out that the Trove library that we ship with our application was used in very few places and considering the number of usages and its size after signing, did not seem worth the download for the customer.
So I replaced it where possible and came across our ID-manager class, that would hold a couple of long values in a TlongHashSet, and replacing gnu.trove.TLongHashSet with java.util.HashSet meant wrapping all those longs in Objects. That would waste quite some space. Being cautious I tested this change with the outrageous number of about 5 million IDs, just to see how memory consumption compares in the extreme. The result was interesting: TlongHashSet used about 116 megabytes and java.util.HashSet used about 339 megabytes of RAM to store these 5 million IDs. This number of IDs is not something we’d expect to happen in the real world and more realistic numbers suggest that while java.util.HashSet may be a viable solution, it’s still considerably more wasteful than TlongHashSet and memory should be used for better things. Unfortunately the ID manager is also restricted to long values; relaxing that constraint didn’t look like bad idea in the long run. The ID-manager’s job is to generate new IDs and it should pick the shortest one it can find, so the numbers don’t grow too large to keep file sizes low. It just needs to know if an ID is definitely not in use, but it is okay to mistakenly assume an ID is in use, while it’s not. It would be nice if IDs could be alphanumeric. This is a classic case for a Bloom filter. I thought about it for a while and decided that, due to the rather small amount of IDs that we use in our system, it wasn’t worth adding the code to our project and got on with more important things. But sometimes work haunts me. Back at home I could not get this Bloom filter idea out of my head, so I set out to explore this data structure. Read more…

Returning the result of a JPA native query as a simple Map or POJO

July 14, 2016 3 comments

I’ve spent quite some time on StackOverflow to answer one simple question: Can I make a JPA NativeQuery return the results as a Map or as a simple POJO? The common consensus looks like it’s not possible. This is unfortunate, but sometimes when people say something cannot be done, I get fired up. And I’ve found a solution, even though it involves a little Hibernate-Vendor-lock-in and a detour.
Read more…

Categories: JPA Tags: , , , , ,

Hack of the day: Get a method-annotation’s default value

June 27, 2016 Leave a comment

So you have an annotation like this:

@Target({ METHOD, TYPE, FIELD })
public @interface Logged {

	String value() default "debug";

	String detailValue() default "trace";


But the source code is not under your control, so you can’t refactor it to use a public constant. How will you get any annotation method’s default value?
You could do it like this:

private String badWay() {
	final Method meth = Logged.class.getMethod("detailValue");
	final Logged annotation = meth.getAnnotation(Logged.class);
	return Level.valueOf(annotation.value());

But then, if someone from the outside refactored it and renamed the method, your compiler won’t notice and it will break at runtime, which is bad.
Here’s a way to perform the task with some introspection, given the annotation can be used on methods:

Logged defaultLogged; //lazily initialized, as reflection is slow

@Logged // annotation with default log level
private String defaultAnnotationDetailLogLevel() {
        if(defaultLogged == null}{
            class Local {};
            final Method meth = Local.class.getEnclosingMethod(); // this method
            defaultLogged = meth.getAnnotation(Logged.class);
        return defaultLogged.detailValue();

In case the annotation will be changed to use any other method name, your compiler will notice immediately and you can fix the broken code before it slips through testing and hits production. Nifty!

Functional Java – partial function application, the LOD and structure agnostic access

March 21, 2016 Leave a comment

It’s been a while since I last wrote something about programming on my private blog and since a lot has been said about Java 8 lambdas, I did not feel to add a lot more. But I recently saw a colleague’s blog on Intel’s Inside Blue about Lambdas and why a functional programming style matters. That motivated me to write something again, and tackle this topic, putting an emphasis on a specific problem and how Lambdas helped me solve it.

Read more…

Multiple floating toolbars with Swing

March 18, 2013 1 comment

These are my holidays, I should be sitting at the beach, not coding. Unfortunately I can’t; and since when I am bored I do things I like, coding is still one good way to kill some time. So I was restarting an old pet project of mine, some kind of editor and I pretty early ran into a problem: The Java gods have brought us floating toolbars that can be docked to the sides of a BorderLayout. Unfortunately the BorderLayout is the only layout they work with und unfortunately a BorderLayout can just hold one component in each of its border regions, so you can’t have more than one JToolbar on each side, which unfortunately renders the floating functionality pretty useless by default. They might have thought “YAGNI”, when the idea of multiple toolbars next to each other crossed their minds, I don’t know. Unfortunately “I am gonna need it”, but fortunately there is remedy. Read more…

Categories: Swing Tags: , ,