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:

@Inherited
@Documented
@InterceptorBinding
@Retention(RUNTIME)
@Target({ METHOD, TYPE, FIELD })
public @interface Logged {

	@Nonbinding
	String value() default "debug";

	@Nonbinding
	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 // annotation with default log level
private String defaultAnnotationDetailLogLevel() {
	class Local {};
	final Method meth = Local.class.getEnclosingMethod(); // this method
	final Logged annotation = meth.getAnnotation(Logged.class);
	return annotation.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: , ,

A properly sized JTable

February 16, 2013 2 comments

Task: Create a table with two columns. The columns should fit the size of the content. If the table’s width is smaller than the panel, make the last column fill the panel, if the table is wider than the panel, show horizontal scrollbars. Sounds so easy? How many of you have wasted a good amount of time making a table behave like this? The good thing is: it is easy. And here is how it works. Read more…

Categories: Swing Tags: , , , ,

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