Refactoring to remove code duplication using the strategy pattern

The strategy pattern‘s main benefit is often stated as being that it provides the ability to essentially swap out parts of an algorithm’s behaviour at runtime. There is another use however that may be deemed overkill and that is simply to get rid of duplicate code.

Consider the following two methods, each with DO A STUFF and DO B STUFF as identical lines of code.

public void foo() {
  // do A stuff
  // do B stuff
public void bar() {
  // do A stuff
  // do B stuff

How can we refactor the offending abomination to get rid of the duplication? There are a number of techniques, one way is simply to use simple control flow statements (switch, if) as suggested in the following excellent overview of the strategy pattern. So we would have the following for example.

enum Action {FOO, BAR}
public void fooBar(Action action) {
  // do A stuff
  switch(action) {
    case FOO:
    case BAR:
      throw new IllegalArgumentException();
   // do B stuff

As you can see from the above, depending on the number of lines of code in DO A STUFF and DO B STUFF we might not actually have reduced our total lines of code (TLOC) but we would almost certainly have made maintenance easier and less error-prone since our two cited sections of potentially intentionally identical code are no longer duplicated.

If we where to use the strategy pattern to get rid of the duplication in Java 7 we would end up defining a one method interface and an anonymous inner class as has been neatly illustrated here. In the simplest possible case our interface will effectively just be a function pointer, as is shown below.

interface Action {
  void execute();
private template(Action action) {
  // do A stuff
  // do B stuff
public void foo() {
  template(new Action() {
    public void execute() {
public void bar() {
  template(new Action() {
    public void execute() {

Arguably the solution shown directly above is more convoluted, however consider that the main reason for this is because of Java 7’s poor support for function pointers in the foo() and bar() methods.   This may no longer be an issue with Java 8 with the introduction of method references.


Berkeley DB Java Edition – Gotcha Log

This post is simply a log of Berkeley DB burns or gotchas written as rules to be remembered. The post will be updated as time goes by.

1. Don’t just change your enum constants willy-nilly and deploy

If you are in development mode, running your app on your local lightweight container, then this one is easy to forget. Its good to get into the habit of having a staging environment with Berkeley DB in write-to-disk mode, even on your local, so that you can occasionally get burnt by Exceptions such as this one and so remember it.

java.lang.IllegalArgumentException: Deletion and renaming of enum values is not supported: STANDARD

at com.sleepycat.persist.impl.EnumFormat.initValues(

The Benefits of Dependency Injection

In this post we firstly describe what dependency injection is, as background, and then articulate what the benefits of dependency injection are. We provide answers to these three questions below and also consider whether dependency injection containers should be used in every project.

  1. What is dependency injection?
  2. What Java frameworks or containers provide dependency injection support?
  3. What are the benefits of dependency injection?

What Is Dependency Injection?

When a particular class has a member variable (also called a field) that is an instance of another class then this is a dependency. How the initialization of instance members  happens and who performs this initialization is the crux of dependency injection or the dependency injection pattern.

Normally, without dependency injection, the particular class would have code to initialize an instance variable in a constructor with the two alternatives to this approach being initializer blocks or final methods.

With dependency injection, an instance of the dependency is provided to our particular class by an external party using either the contructor of the particular class or a setter of the particular class. So the external party is the who, and in term of the how this external party performs either contructor injection or setter injection.

Dependency injection frameworks alleviate the need for factories and the use of new in your Java code. Configuration instructions, via annotations or XML, replace new in your Java code. You may still write factories from time to time, but your code will not depend directly on them.

What Java frameworks provide dependency injection support?

The two major frameworks are the Spring Framework and Google Guice. PicoContainer is another alternative.

What Are The Benefits Of Dependency Injection?

In short your code will be easier to change, easier to unit test and easier to reuse in other contexts. We provides explanations for these benefits below, but before we do so, its worth quoting Anand Rajana [1] in terms of his summary:

It facilitates the design and implementation of loosely coupled, reusable, and testable objects in your software design and implementation by removing dependencies that often inhibit reuse. Dependency injection can help you design your applications so that the architecture [container] links the components rather than the components linking themselves.

Your code will be easier to maintain and easier reuse in other contexts.

This is because your object is handed what it needs to work and since it it freed from the burden of resolving its dependencies. When an object is handed what it need to work in terms of its dependencies by a container such as Spring, this is called inversion of control (IoC). One may wonder, why does this, that is IoC, make maintenance and reuse easier? Its because the components (plain old Java objects) that make up your application are loosely coupled as a result of your objects being handed what they need to work – its far easier to swap out a component as a matter of configuration than it otherwise would have been in a tightly coupled architecture.

It is also because dependency injection promotes programming to interfaces which conceals the implementation details of each dependency and naturally this makes it easier to swap out implementations of a given interface. The combination of your objects being handed what they need to work by an IoC container and programming to interfaces significantly enhances loose coupling.

Finally, it is because the centralized control over the object lifecycle brings with it a host of benefits that enhances the maintainability and re-usability of ones code. For example, Spring’s BeanFactoryPostProcessors are able to modify the definition of any bean in the ApplicationContext‘s BeanFactory before any objects are created. A good example of such a BeanFactoryPostProcessor is a PropertyPlaceholderConfigurer which substitutes ${variables} in an definitions with values from .properties files. In addition, a BeanPostProcessor may wrap your beans in a dynamic proxy and add behaviour to your application logic transparently. A good example of behaviour that can be transparently added is transaction management behavior that has been declaratively specified using annotations.

Your code will have significantly enhanced testability

This is because dependencies can easily be replaced with stubs or mocks in unit tests.

Should Dependency Injection Containers Be Used in Every Project?

This is a matter of opinion and so this will be the authors opinion. In short, the answer is no.

One may wonder why the answer is no. It is because one still needs to motivate why one needs all the benefits that come with using say Spring or Guice in one’s architecture. In short-lived prototyping projects maintainability and unit testing may not be the top priority, it could be that the bulk of the effort is say in producing a GUI prototype or experimenting with new technologies. It could also be that reusability is of no concern. Every project is different and thought and motivation needs to be applied to every technology decision.

To give an example of where the benefits of IoC may not be the top priority. The author was handed a micro project (single developer at a time)  that was in trouble in terms of delivery to the client, the top priority was to show the client results in weekly sprints, and the first decision made was to speed up local development and make the existing code generally comprehensible. This involved introducing Maven, the Maven Jetty plugin, JRebel, significant refactoring and much more. Results where delivered, albeit in a tightly coupled manner with hand rolled singletons (factories) and little unit or integration testing. The project later reached a stage where introducing an IoC container made sense in terms of priorities in order to realise all of the cited benefits, above all to introduce testing automation to stub out cloud services.

Although the short answer is no, its worth noting that the long answer is no but in general yes. More often than not prototyping projects go live, and it is in general unlikely that an application will require no maintenance after it went into production. So one should not set up fellow maintainers or one-self up for failure and 9 times out of 10 (if not 9.9 times out of 10) use IoC containers / dependency injection in order to realise the core benefits and that is code that is easier to change, easier to unit test and easier to reuse in other contexts.


  1. Dependency Injection, Slideshare, Anand Rajana
  2. Core Spring. Student Lecture Manual. Version 3.2.
  3. google-guice (its worth listening to the presentation, they provide good examples in their slides)
  4. Inversion of Control Containers and the Dependency Injection Pattern, Martin Fowler, 23 January 2004 (somewhat longwinded)

Java B-Tree Implementation Index

Tree of lifeIts been a solid 13 years since I completed Computer Science 2 with the bedrock Algorithms & Data Structures  course. Its time to brush up on the fundamentals, starting with the B-Tree.

Here is a list of existing implementations that I managed to find, there was one more but it disappeared from Google Code:

  1. JDM3’s BTree implementationvery well documented and comes with delete/remove functionality which is often missing.
  2. Princeton CS (HTML file) – no delete/remove functionality.
  3. Apache DS B-Tree Base (Mavenized).

I initially used 2. when creating an inverted index but got burned as I ended up needing 1.’s remove method for index maintenance. I only found the JDBM3 implementation after more digging.

JPA Lazy Collection Loading

If all you are looking for is how to load a lazy collection with JPA, you’ll be swamped with endless posts and articles going on about the pros and cons of using lazy or eager loading. Its all noise if your question is simply how do I load my lazy collection using the JPA API?

The quick and dirty answer is just do this: singleFoo.getBars().size();

There it is. End of story. It is worth noting that I’m an advocate of using a Service Facade and DTOs, in other words clean APIs and I use Spring’s transactional annotations on the service layer. Also, you will come across posts mentioning Hibernate and initialization methods, this doesn’t help since we are only interested in pure JPA here.

Sure there is alot more to it and there are pitfalls to consider, that is old news, any layer of abstraction comes at it price and in some way dumbs you down (mmm, getting philisophical, its so easy to do).

This is one of the posts I was referring to, and it was a distraction: Avoid Lazy JPA Collections. A better read would be this one: JPA Implementation Patterns: Lazy Loading

WS-Security Basic Policy Definition And Client Testing In Java With JAX-WS

If you’ve defined a wsdl and need to introduce the most basic security policy, generate the client side code and then run some integration tests then this post may help you.

The focus here is on getting it all working, not the most efficient solution, and neither the most secure. We choose a UsernameToken with plain text password and work that into the wsdl, then generate code with the Maven cxf-codegen-plugin, then find a way to add the missing security headers and finally write an integration test.

In terms of context, the steps below where followed in a project where a web service was implemented, and already thoroughly tested using the help of jetty and the maven-soapui-plugin with the latter executing tests during the integration-test phase.

Step 1: Modify The WSDL

The pretinent parts of the this wsdl are shown below. Note the wsp:PolicyReference below the wsdl:service element.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:types xmlns:wsdl="">
<wsdl:service name="VoucherServiceService" xmlns:wsdl="">
  <wsp:PolicyReference xmlns:wsp="" URI="#VouchUsernameToken"/>
  <wsdl:port binding="tns:VoucherServiceSoap11" name="VoucherServiceSoap11" xmlns:wsdl="">
    <soap:address location="" xmlns:soap=""/>

<wsp:Policy wsu:Id="VouchUsernameToken">

Step2: Code Generation In Our Maven Pom Using cxf-codegen-plugin


Step 3: Add A HeaderHandler and HeaderHandlerResolver

This post shows how to add the security headers. It works, try it. You’ll need some solution since the code generated by cxf will not provide any means of adding the headers, which is naturally suboptimal.

Step 4: Test It All Using An Integration Test

public class VoucherServiceIT {

public void test() {
  URL url = null;
  try {
    url = new URL("http://localhost:8080/vouchserv/vouchserv.wsdl");
  } catch (MalformedURLException e) {
   throw new RuntimeException(e);

  VoucherServiceService voucherServiceService = new VoucherServiceService(url);
  HeaderHandlerResolver handlerResolver = new HeaderHandlerResolver();
  VoucherService voucherService = voucherServiceService.getVoucherServiceSoap11();
  RegisterRequest registerRequest = new RegisterRequest();
  RegisterResponse registerResponse = voucherService.register(registerRequest);


Dynamic string concatenation by example, 3900 times more expensive than StringBuilder

The significant cost associated with using the String concatenation operator, and need to use a StringBuilder instead of a String to store the interim object under construction, is well known. In this post, we start by firstly presenting eye opening results from some performance tests to quantify why one needs to consider the cost of String concatenation, we then take a look under the hood to see why dynamic String concatenation is so inefficient.

Performance Tests: Does Concatenating n Strings Really Take Time Quadratic in n?

Joshua Bloch, in Effective Java, advises that using the concatenation operator repeatedly to concatenate n strings requires time quadratic in n due to strings being immutable and the need to copy the contents of both strings when performing a concatenation operation.

In terms of Big O notation, the above means O(n²) or O-n-squared, which is disastrous time wise. To see just how disastrous, here are the results of 4 runs of a simple test, the 5th run was stopped since I was not willing to wait approximately 40 seconds squared.

Number concatenations

+/ms StringBuider.append/ms
100 0 0
1000 22 0
10 000 306 1
100 000 39 259 10

The results show an exponential increase in time when looking at the concatenation time column and since big O time estimates are not exact, one can say yes, concatenating n strings really does take time quadratic in n.

If you’d like to run the tests on your machine, please find the simple program used below.

public class StringConcatenationPerformance {

	public static void main(String[] args) {

        final String base = getBaseString();
        int CONCATENATIONS = 1000;

        long startTime = System.currentTimeMillis();

        String result = base;

        for(int i = 0; i < CONCATENATIONS ; i++) {
            result = result + "b";

        long estimatedTime = System.currentTimeMillis() - startTime;


        startTime = System.currentTimeMillis();
        StringBuilder builder = new StringBuilder(base);
        for(int i = 0; i < CONCATENATIONS ; i++) {
        estimatedTime = System.currentTimeMillis() - startTime;


    private static String getBaseString() {
        StringBuilder builder = new StringBuilder();
        for (int i = 0; i < 1000; i++) {
        return builder.toString();


String Concatenation: Under The Hood

Eyal Lupu has kindly done the hard work of opening the hood, meaning that he used the javap utility (java class file disassembler) to look at the generated byte code of a concatenation loop.

His results show that the following:

String result = "";
for (int t=0; t<10000; ++t ) {
 result = result + getSomeString();

Results, in effect, in the following:

String result = "";
for (int t=0; t<10000; ++t ) {
 result = new StringBuilder(String.valueOf(result)).append(getSomeString()).toString();

The above created 10 000 Strings on the heap, 10 000 StringBuilder objects, then there is the additional cost of, within StringBuilder.append, allocating an array large enough to fit our characters and copying characters from the old smaller array to the larger array.


  1. Under the Hood of Java Strings Concatenating Performance, Eyal Lupu
  2. java String concatenation, Tom Hawtin
  3. Effective Java, Second Edition, Joshua Bloch, Item 51: Beware the performance of string concatenation
  4. Java String Concatenation, Joseph Kulandai
  5. Stivlo