Posts Tagged ‘Java’

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 Leave a comment

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 Leave a comment

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…

Listing a directory on the class path when it’s in a Jar archive

January 27, 2013 Leave a comment

Today I was revisiting an old memory game that I wrote almost seven years ago and I must admit that I was partly horrified by the code I have written back in the days. So I started to change small parts of it. For example I was loading a set of images from a directory on the class path, by generating the name of the image, like “card1.jpg”, “card2.jpg” and getting these via getClass().getResource(name). Now, as I was changing some images, and files happened to be “.jpg” and others “.png”, my old name-generator code failed. Not a good solution, I thought, and planned to load all files from a directory that would just contain card images – didn’t work as expected though, but I found a solution on the net, which I had to change a bit to make it work for me. Here’s the result that I’d like to share. Read more…

Categories: File handling Tags: , , ,

Java actor framework “Kilim”: A solution without a problem?

November 26, 2010 3 comments

Some time ago I read a posting from a workmate, that was linking to an IBM developerworks article about the actor-framework “Kilim” and he seemed to be quite fond of it. Since I know this guy’s a very skilled technician and since actors are one of the bigger hypes in software technology nowadays, with languages like Scala openly supporting that concurrency model, and since the IBM developerworks articles are usually quite good, I instantly dived into it, only to be left perplexed. Read more…