Manage bitempotal data with BarbelHisto

The last 15 years I've worked on projects for insurance businesses, implementing a variety of policy management systems. The topic that has always been a major requirement was to store the policies and their changes in a way that is traceable for audits and customer claims. Implementing bullet-proof bitemporal data storage has always taken a reasonable amount of time (and nerves). Every time we've implemented a new policy management system we have been on the lookout for a reusable component for bitemporal data. The few options we found did not really satisfy our needs, or had too many technical constraints. For that reason I've decided to implement my own open source library that I'd like to share with you guys: BarbelHisto. With this lightweight library I want to address that bitemporal data storage requirement, without any bothersome constraints. Just managing bitemporal data, that's it. No technology backpack.

Modern State Pattern using Enums and Functional Interfaces

It’s offen the case that the behaviour of an object should change depending on the objects state. Consider a ShoppingBasket object. You can add articles to your basket as long the order isn’t submitted. But once it’s submitted you typically don’t want to be able to change that order anymore. So, there are two states in such a shopping basket object: READONLY and UPDATEABLE .

Passing multiple arguments into stream filter predicates

When I am working with java streams I am intensively using filters to find objects. I offen have the situation where I'd like to pass two arguments to the fiter function. Unfortunately the standard API does only accept a Predicate but not BiPredicate.

To solve this limitation I define all my predicates as methods in a class, say Predicates. That predicate class takes a constant parameter.

Java 7: NIO.2 I/O operations on asynchronous channels are not atomic

This part of my NIO.2 series wasn't on schedule when I started writing about NIO.2 aasynchronous file channels. It deals with an important detail: read and write operations are not atomic. What that means is that AsynchronousFileChannel -> write() does not garantee to write all bytes passed as parameter to the destination file. Instead it returns the number of bytes written as return parameters of the corresponding I/O operations and the client needs to deal with situations where the bytes written isn't equal to the remaining bytes in the passed ByteBuffer.

Java 7: Closing NIO.2 file channels without loosing data

Closing an asynchronous file channel can be very difficult. If you submitted I/O tasks to the asynchronous channel you want to be sure that the tasks are executed properly. This can actually be a tricky requirement on asynchronous channels for several reasons. The default channel group uses deamon threads as worker threads, which isn't a good choice, cause these threads just abandon if the JVM exits. If you use a custom thread pool executor with non-deamon threads (see last part of this series) you need to manage the lifecycle of your thread pool yourself. If you don't the threads just stay alive when the main thread exits. Hence, the JVM actually does not exit at all, what you can do is kill the JVM.

Threading stories: ThreadLocal in web applications

This week I spend reasonable time to eliminate all our ThreadLocal variables in our web applications. The reason was that they created classloader leaks and we coudn't undeploy our applications properly anymore. Classloader leaks happen when a GC root keeps referencing an application object after the application was undeployed. If an application object is still referenced after undeploy, then the whole class loader can't be garbage collected cause the considered object references your applications class file which in turn references the classloader. This will cause an OutOfMemoryError after you've undeployed and redeployed a couple of times.

Java 7: NIO.2 File Channels on the test bench - Part 2 - Applying custom thread pools

Asynchronous file processing isn't a green card for high performance. In my last post I have demonstrated that conventional I/O can be faster then asynchronous channels. There are some additional important facts to know when applying NIO.2 file channels. The Iocp class that performs all the asynchronous I/O tasks in NIO.2 file channels is, by default, backed by a so called "cached" thread pool. That's a thread pool that creates new threads as needed, but will reuse previously constructed threads *when* they are available. Look at the code of the ThreadPool class held by the Iocp.

Java 7: NIO.2 File Channels on the test bench - Part 1 - Introduction

Another blog post about new JDK 7 features. This time I am writing about the new AnsynchronousFileChannel class. I am analyzing the new JDK 7 features in depth for a couple of weeks now and I have decided to number my posts consecutively. Just to make sure I don't get confused :-) Here is my 7th post about Java 7 (I admit that - by coincidence - this was also a little confusing). Using NIO.2 asynchronous file channels effectively is a wide topic. There are some things to consider here. I have decided to devide the stuff into four posts. In this first part I will introduce the involved concepts when you use asynchonous file channels. Since these file channels work asynchronously, it is interesting to look at their performance compared to conventional I/O. The second part deals with issues like memory and CPU consumption and explains how to use the new NIO.2 channels safely in a high performance scenario. You also need to understand how to close asynchronous channels without loosing data, that's part three. Finally, in part four, we'll take a look into concurrency.

Java 7: A complete invokedynamic example

Another blog entry in my current Java 7 series. This time it's dealing with invokedynamic, a new bytecode instruction on the JVM for method invocation. The invokedynamic instruction allows dynamic linkage between a call site and the receiver of the call. That means you can link the class that is performing a method call to the class (and method) that is receiving the call at run-time. All the other JVM bytecode instructions for method invocation, like invokevirtual, hard-wire the target type information into your compilation, i.e. into your class file. Let's look at an example.

Java 7: How to write really fast Java code

When I first wrote this blog my intention was to introduce you to a class ThreadLocalRandom which is new in Java 7 to generate random numbers. I have analyzed the performance of ThreadLocalRandom in a series of micro-benchmarks to find out how it performs in a single threaded environment. The results were relatively surprising: although the code is very similar, ThreadLocalRandom is twice as fast as Math.random()! The results drew my interest and I decided to investigate this a little further. I have documented my anlysis process. It is an examplary introduction into analysis steps, technologies and some of the JVM diagnostic tools required to understand differences in the performance of small code segments. Some experience with the described toolset and technologies will enable you to write faster Java code for your specific Hotspot target environment.

Java 7: Understanding the Phaser

Java 7 introduces a flexible thread synchronization mechanism called Phaser. If you need to wait for threads to arrive before you can continue or start another set of tasks, then Phaser is a good choice. Here is the listing, everything is explained step-by-step.

Java 7: Fork and join decomposable input pattern

In my recent blog I have introduced the fork and join framework of Java 7. This blog presents a little framework on top of raw fork and join. The framework implements the decomposable input pattern (dip) - which originated from my own laziness when I was using the framework a couple of times. I have realized that I was writing the same code every time when I was implementing a slightly different use case. And you know, let's write a little peace of software that I can reuse. The decomposable input pattern framwork was born.

Java 7: Fork and join and the jam jar

Another Java 7 blog, this time it's about the new concurrency utilities. It's about plain fork and join in particular. Everything is explained with a straight code example. Compared to Project Coin concurrency is an inherently complex topic. The code example is a little more complex. Let's get started.

Java 7: Project Coin in code examples

This blog introduces - by code examples - some new Java 7 features summarized under the term Project Coin. The goal of Project Coin is to add a set of small language changes to JDK 7. These changes do simplify the Java language syntax. Less typing, cleaner code, happy developer ;-) Let's look into that.

Threading stories: volatile and synchronized

In my last blog about the volatile modifier I have introduced a little program that illustrates the behaviour of volatile in a Java 6 (26) Hotspot VM. Since that day I had some interesting discussions that I wanted to share in this blog. It adds another valuable insights on the volatile modifier.

Threading stories: Why volatile matters

Many years ago when I learned Java (in 2000) I was not so concerned about multithreading. In particular I wasn't concerned about the volatile modifier. I don't know why, but I never had problems without volatile, so maybe I thought it could not be so relevant. I've suddenly changed my mind when I first analyzed a wierd behaviour of an application that only existed when the application was deployed to a server JVM. Todays JVMs make a lot magic stuff to optimize runtime performance on server applications. In this blog I show you an example to get fimiliar with problems that arrize in multithreaded applications, when you don't recognize the importance of understanding how Java treats shared data in multithreaded programs.

Benchmark series on simple caching solutions in Java

Caching is a very common solution when you don't want to repeat CPU intense tasks. The last days I was benchmarking options to do caching with ConcurrentHashMap. In this blog I publish the first results. I have used Heinz Kabutz' Performance Checker to do this. I also added some features based on my readings of this article series.

Your web applications work - by sheer coincidence!

This blog describes a solution to a typical concurrency problem in a web application environment, and it illustrates that you - in all likelihood - cannot be sure that your application is thread-safe. It just works - by sheer coincidence.