On the way to better software

Scala collections: Filtering each n-th element - Part 2

2011-02-24T22:26:00.004+01:00

If you read my previous post you know that I'm trying to find the best implementation for filtering each n-th element from a collection. Since then I found two more possible implementations:

Loop - Reverse
This implementation is faster than other loop-based implementations. It benefits from replacing append :+ with concatenation ::

def filterUsingLoopReversed[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] = {
  var out = List.empty[A]
  val it = in.iterator
  for (i <- 0 to in.size - 1) {
    if (i % step == offset) out = it.next :: out
    else it.next
  }
  out.reverse
}

Range - Map
This is simply the best implementation I have. It's not only concise but also very fast. The drawback is that it requires the input collection to be an instance of Seq
```
def filterUsingMap[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] = {
  val seq = in.toSeq
  Range(offset, in.size, step).map(seq(_))
}
```
Edit: Peter suggested that the perfomance of this solution depends on the implementation of the input collection. To mitigate this I've decided to convert input collection to IndexedSeq which is supposed to guarantee near constant-time element access. The performance is a bit worse because of the extra conversion time, though it's still the fastest solution I found
```
def filterUsingMap[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] = {
  val seq = in.toIndexedSeq
  Range(offset, in.size, step).map(seq(_))
}
```

Benchmark results:
Average execution time of 100 executions

Range-Map (light green) is comparable to Loop-Buffered (dark green) when filtering small-mid collection (<10000 elements). And there is no better choice than Range-Map to filter big collections (>10000 elements).

Scala collections: Filtering each n-th element

2011-02-19T00:13:00.016+01:00

Recently I had to process huge log files. I found it to be a great opportunity to check my Scala language skills. One of the problems I had to figure out was filtering every n-th element from iterable collection. This is supposed to be a trivial task, but well, after thinking for a while I had five competitive implementations ready. Which one should I pick? Perhaps the most concise one. To make the choice easier I've decided to measure how performant they are.
Filtering implementations:

Filter using groups This is my favorite one, the cleanest implementation.

def filterUsingGroups[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] =
  in.drop(offset).grouped(step).map(_.head).toIterable

How it works:

in = (1,2,3,4,5,6,7,8,9,10), step=3, offset=2
drop(2) => (3,4,5,6,7,8,9,10)
grouped(3) => ((3,4,5),(6,7,8),(9,10))
map(_.head) => (3,6,9)

Filter using index

def filterUsingIndex[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] =
  in.zipWithIndex.filter(_._2 % step == offset).unzip._1

How it works:

in = (1,2,3,4,5,6,7,8,9,10), step=3, offset=2
zipWithIndex => ((1,0),(2,1),....,(10,9))
filter(_._2 % 3 == 2) => ((3,2), (6,5), (9,8))
unzip._1 => (3,6,9)

Filter using recursion

def filterUsingRecursion[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] = {
  if (in.size >= step) {
    val (l, r) = in.splitAt(step)
    List(l.drop(offset).head) ++ filterUsingRecursion(r, step, offset)
  } else List.empty[A]
}

How it works:

in = (1,2,3,4,5,6,7,8,9,10), step=3, offset=2
splitAt(3) => l=(1,2,3); r=(4,5,6,7,8,9,10)
l.drop(2).head == 3 => List(3) ++ filterUsingRecursion((4,5,6,7,8,9,10), 3, 2)

Filter using loop (unbuffered)

def filterUsingLoop[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] = {
  var out = List.empty[A]
  val it = in.iterator
  for (i <- 0 to in.size - 1) {
    if (i % step == offset) out = out :+ it.next
    else it.next
  }
  out
}

Filter using loop (buffered)

def filterUsingLoopWithBuffer[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] = {
  val out = collection.mutable.ListBuffer.empty[A]
  val it = in.iterator
  for (i <- 0 to in.size - 1) {
    if (i % step == offset) out += it.next
    else it.next
  }
  out
}

Filter using tail recursion (added later)

def filterUsingTailRecursion[A](in: Iterable[A], step: Int, offset: Int): Iterable[A] = {
  def filter(acc: ListBuffer[A], in: Iterable[A]): ListBuffer[A] = {
    in.splitAt(step) match {
      case (l, r) if (l.size >= offset) => filter(acc += l.drop(offset).head, r)
      case _ => acc
    }
  }
  filter(ListBuffer.empty[A], in)
}

In my benchmark I've called each method 10 times in a row and measured average execution time (using parameters step=3, offset=2). When benchmarking I call foreach on the result of each execution of the method under test. I do this to materialize returned collection if it would be backed by an iterator.

def benchmark[A](fn: => Iterable[A]): Double = {
  fn // warm-up
  val times = 10
  val start = System.currentTimeMillis
  for (i <- 1 to times) fn.foreach(_ => ())
  val stop = System.currentTimeMillis
  (stop - start).toDouble / times
}

The chart below shows the results I've collected. Conclusions:

Buffered loop is the fastest implementation
Index is also quite good
Recursion is working pretty well with small collections but fails to process huge collections (java.lang.StackOverflowError)
Unbuffered loop fails to process huge collections because of intesive data copying
Groups give worst performance
Tail recursion works very well with huge collections

Sadly the implementation using groups is not the most performant although it's clean and concise. Anyway it's good enough when processing less than 1000 elements. That makes it quite good candidate for initial implementation.

Tech Tip: How to use fast scala compiler (fsc) from IntelliJ IDEA

2010-07-15T22:10:00.005+02:00

Using fsc from IDEA is supposed to be trivial task. IDEA provides dedicated fsc "Run Configuration" out-of-the-box. Unfortunately in reality things are getting more complicated. Scala build in IDEA is hanging more or less often making it not usable.

It took me several hours to figure out what is going on there. I was trying with dozen of switches without success. Finally I've found this simple answer and here it is.

When compiler server is starting it opens random port to listen for commands from compiler clients. Obviously the clients must know that port number. To communicate that server is creating file named as the port number. The file is created under JVM temporary directory ${java.io.tmpdir}/scala-devel/ ... (/tmp/scala-devel/{username}/scalac-compile-server-port/ at my linux box). Problems begin if there are some old unused files left in that directory. So the solution is easy - delete ${java.io.tmpdir}/scala-devel/ before starting compiler server.

I've created simple bash script to do that. I simply use it instead of starting fsc from IDEA.

"Analysis Patterns 2 - Work in Progress"

2009-12-07T23:12:00.003+01:00

I was about to buy Analysis Patterns book by Martin Fowler but recently I found on his web page that he's working on version two of this book, thus I've decided to wait a bit. He's also kindly publishing his work so waiting won't hurt so much.

Why I won't use Qi4j (yet)

2009-12-07T21:36:00.006+01:00

Several months ago I've published short series about Qi4j basics. I was impressed not only by the long list of interesting features, but also by the overall concept of the application architecture that Qi4j offers. Unfortunately I've recognized it's very difficult for me to write an application using Qi4j quickly and here is why. 1. Mixins. When Mixins are very useful feature the way they are implemented in Qi4j doesn't work for me. I had to write a lot of nested classes and was loosing my focus because of this. I'm wondering what was theirs motivation to create this framework in Java not in Scala which has traits already built-in. 2. Lack of good relational DB support. Another obstacle is that it's strongly focused on the object oriented data stores. Well, that's not bad actually, probably in the future we'll use them mostly. But today when at work I've to deal with relational databases this is serious disadvantage. Hiding these relational databases behind anti-corruption layers would work but it also makes usage of Qi4j's UnitOfWork impossible. 3. Testability. Mocking interfaces with properties modeled with Property<T> needs endless effort. (Maybe I didn't find the right tool to do this) 4. Poor documentation. Why the Spring framework is so popular? Because it's very well documented and its codebase is fairly readable - that's for sure one of the reasons. Nothing more to add here. Anyway it's not as bad as it might look like. I appreciate Qi4j's developers for their innovating approach to software development and I'm tracking theirs mailing list carefully as there is a lot of interesting discussions I can learn from. Qi4j is definitely worth to give it a try also to feel the taste of BDD for a while. It's amazing in how many different ways it's possible to write an application in Java.

Google collections

2009-10-23T09:55:00.003+02:00

Google collections is very interesting, modern library which supplements standard library java.util.collections. It focuses on code simplicity and safety (immutability). And it brings some flavours of functional programming into Java land what I hope will help the developers evolve into more functional languages like Scala smoothly. Here is a nice 10 minutes long introduction.

Qi4j - First mixin

2009-09-30T15:06:00.011+02:00

This is my third post about Qi4j basics. In this post I'll show you how to implement behavior and wire it together with the code I already wrote for the previous post. As you probably remember Qi4j manages composites. Composite is defined as a composition of fragments. Fragment is a piece of code responsible for concrete functionality. Each fragment can be categorized either as a mixin or modifier. Mixin's role is to provide an implementation for composite's methods. At the moment Rational composite has only properties. So let's add some behavior methods. (Mixins are not limited only to provide behavior implementation, in fact properties are managed by predefined mixin too) Step 1. Extend Rational interface.

import org.qi4j.api.property.Property;
import org.qi4j.api.value.ValueComposite;

public interface Rational extends ValueComposite {

    Property<Integer> nominator();

    Property<Integer> denominator();

    Rational add(Rational toAdd);

    Rational mul(Rational toMultiply);
}

The highlighted lines show new behavior methods. If you try to run the application you will see the exception with the following message:

No implementation found for method public abstract com.blogspot.javasnippet.qi4j.Rational com.blogspot.javasnippet.qi4j.Rational.add(com.blogspot.javasnippet.qi4j.Rational) in com.blogspot.javasnippet.qi4j.Rational

That's because Qi4j doesn't see any implementation for these new methods. Step 2. Implement mixin.

public interface Rational extends ValueComposite {

    Property<Integer> nominator();

    Property<Integer> denominator();

    Rational add(Rational toAdd);

    Rational mul(Rational toMultiply);

    abstract class RationalMixin implements Rational {

        @Override
        public Rational add(Rational toAdd) {
            return null;
        }

        @Override
        public Rational mul(Rational toMultiply) {
            return null;
        }
    }
}

Things worth to be noted:

RationalMixin class is defined inside Rational interface - although it's not mandatory and is done here for simplicity there are cases (mainly for modifiers) where it makes sense to put implementation directly into declaring interface.
RationalMixin class is abstract - as I want to implement only behavior methods I have to make this class abstract. This way it's possible to even split single interface implementation into set of mixins. Qi4j proxies and reflection does the rest.

Qi4j still is not aware of this stub implementation and crashes by throwing this same exception as before. Step 3. Register mixin. To register mixin I have to annotate interface Rational with @Mixins annotation like below.

@Mixins(Rational.RationalMixin.class)
public interface Rational extends ValueComposite {
...
}

Now the application is running fine - Qi4j sees implementation for all declared methods. Step 4. Accessing composite state. UPDATE: It's no longer necessary to inject state to the mixin. See p.4.1 Rational extends ValueComposite which in turn extends Composite interface. If you look at source code of Composite interface then you will see it declares usage of PropertyMixin - that's the one which is responsible for properties state management. So our Rational is composed out of two fragments: PropertyMixin and RationalMixin. To implement methods inside the RationalMixin we need to access the state of this Rational composite instance. Qi4j solves this by dependency injection. See highlighted lines below.

    abstract class RationalMixin implements Rational {

        @This
        private Rational state;

        @Override
        public Rational add(Rational toAdd) {
            return null;
        }

        @Override
        public Rational mul(Rational toMultiply) {
            return null;
        }
    }

According to the JavaDoc, annotation @This "denotes the injection of a reference to the same Composite as the fragment is a part of". Then the method add() can be implemented as:

        public Rational add(Rational toAdd) {
            int n1 = state.nominator().get();
            int d1 = state.denominator().get();
            int n2 = toAdd.nominator().get();
            int d2 = toAdd.denominator().get();

            int d = d1 * d2;
            int n = n1 * d2 + n2 * d1;
            return null;
        }

Step 4.1. Accessing composite state without using @This. I wasn't aware of this feature when I was writing this post. Here is an update. Qi4j routes calls to the abstract methods (in other words - the methods which are not implemented by the mixin) to the composite. So the implementation of RationalMixin can be rewritten as follows:

    abstract class RationalMixin implements Rational {

        @Override
        public Rational add(Rational toAdd) {
            int n1 = this.nominator().get();
            int d1 = this.denominator().get();
            int n2 = toAdd.nominator().get();
            int d2 = toAdd.denominator().get();

            int d = d1 * d2;
            int n = n1 * d2 + n2 * d1;
            return null;
        }

        @Override
        public Rational mul(Rational toMultiply) {
            return null;
        }
    }

Step 5. Accessing module resources. Now it's time to create new Rational instance inside RationalMixin. To do this we need reference to the ValueBuilderFactory. This is solved by the dependency injection as well. Qi4j defines annotation @Structure which "denotes the injection of a resource specific for the module which the injected object/fragment is instantiated in".

    abstract class RationalMixin implements Rational {

        @Structure
        private ValueBuilderFactory builderFactory;

        @Override
        public Rational add(Rational toAdd) {
            int n1 = this.nominator().get();
            int d1 = this.denominator().get();
            int n2 = toAdd.nominator().get();
            int d2 = toAdd.denominator().get();

            int d = d1 * d2;
            int n = n1 * d2 + n2 * d1;

            ValueBuilder<Rational> builder = builderFactory.newValueBuilder(Rational.class);
            builder.prototype().nominator().set(n);
            builder.prototype().denominator().set(d);
            return builder.newInstance();
        }

        @Override
        public Rational mul(Rational toMultiply) {
            return null;
        }
    }

The implementation of method add() is now finished. We can check if it works. Here is new body of method main() which computes 2/3 + 3/4 and prints the result to the console.

    public static void main(final String[] args) throws Exception {
        SingletonAssembler assembler = new SingletonAssembler() {

            @Override
            public void assemble(ModuleAssembly module) throws AssemblyException {
                module.addValues(Rational.class);
            }
        };

        ApplicationSPI application = assembler.application();

        Module module = assembler.module();
        ValueBuilder<Rational> rb;
        rb = module.valueBuilderFactory().newValueBuilder(Rational.class);
        rb.prototype().nominator().set(2);
        rb.prototype().denominator().set(3);
        Rational r1 = rb.newInstance();

        rb = module.valueBuilderFactory().newValueBuilder(Rational.class);
        rb.prototype().nominator().set(3);
        rb.prototype().denominator().set(4);
        Rational r2 = rb.newInstance();

        Rational r3 = r1.add(r2);

        System.out.println(r3.nominator().get() + "/" + r3.denominator().get());
    }

You should see:

17/12

Summary This is last post of my short series about Qi4j basics. Here is short list of things worth to be remembered:

Qi4j is composite oriented and manages composites rather than objects.
Qi4j aims to help us in easier DDD adoption.
Qi4j uses dependency injection.

Qi4j offers much more features than I know about (I'm still learning). If you want to learn more go to its website. I encourage you to give it a try.

Qi4j - First application

2009-09-23T22:24:00.008+02:00

In the previous post I've shown how to set up Qi4j project with maven. In this post I'll show how to create application which will slowly evolve into basic rational number calculator in the future. I realize that using Qi4j in such simple application is an overkill but I think it's suitable for showing the basics. Qi4j derives many concepts from the famous Domain Driven Design. According to DDD principles an application should be comprised of layers. Each layer can have one or more modules. Qi4j uses assemblers to define application structure, layers, modules and dependencies between them. Assemblers are classes derived from interface org.qi4j.bootstrap.Assembler. In this simple application we'll use SingletonAssembler which instantiates one layer with one module inside. Step 1. Create application class. Create new class SimpleQi4jApplication in the package com.blogspot.javasnippet.qi4j which is located under directory src/main/java.

package com.blogspot.javasnippet.qi4j;

public class SimpleQi4jApplication {

    public static void main(final String[] args) {


    }

}

Step 2. Add SingletonAssembler.

public class SimpleQi4jApplication {

    public static void main(final String[] args) {
        SingletonAssembler assembler = new SingletonAssembler() {

            @Override
            public void assemble(ModuleAssembly module) throws AssemblyException {

            }
        };

    }
}

SingletonAssembler is an abstract class with abstract method assemble left to be implemented. I don't have anything to be assembled at the moment so I'm leaving it empty. Step 3. Activate application. Qi4j application has simple life-cycle. It can be activated and deactivated.

public class SimpleQi4jApplication {

    public static void main(final String[] args) throws Exception {
        SingletonAssembler assembler = new SingletonAssembler() {

            @Override
            public void assemble(ModuleAssembly module) throws AssemblyException {

            }
        };

        ApplicationSPI application = assembler.application();
    }
}

Now we can start this doing-nothing application. (I've added throws Exception to main() method for the sake of simplicity). We don't have to activate application explicitly because SingletonAssembler does this automatically. Step 3. Create composite. Let's model the rational number. Each rational number can be expressed as a ratio nominator/denominator, where both nominator and denominator are integers. Here is Rational interface created with Qi4j goodies.

import org.qi4j.api.property.Property;
import org.qi4j.api.value.ValueComposite;

public interface Rational extends ValueComposite {

    Property<Integer> nominator();

    Property<Integer> denominator();

}

Several new features come with this code snippet:

The properties are declared as methods with result type Property<Integer>. Qi4j deprecates classic POJO model and replaces it with this simple and powerful concept.
Interface Rational extends ValueComposite - this declaration makes Rational a Qi4j composite. In general Qi4j favours composites over objects (in Java meaning) and everything it manages is rather a composite than an object. There are several types of composites supported like value, entity, service and transient. In this example I choose to use value composite - an equivalent of DDD value object.
Interface Rational defines only properties - there is no behavior. One of the greatest features of Qi4j is its ability to manage composite state automatically (through generic mixins). That means we don't need to provide any implementation at the moment.

Now we can add Rational composite to the Qi4j runtime.

    public static void main(final String[] args) throws Exception {
        SingletonAssembler assembler = new SingletonAssembler() {

            @Override
            public void assemble(ModuleAssembly module) throws AssemblyException {
                module.addValues(Rational.class);
            }
        };

        ApplicationSPI application = assembler.application();
        application.activate();

        Module module = assembler.module();
        ValueBuilder<Rational> rb;
        rb = module.valueBuilderFactory().newValueBuilder(Rational.class);
        rb.prototype().nominator().set(2);
        rb.prototype().denominator().set(3);
        Rational r1 = rb.newInstance();

        System.out.println(r1.nominator().get() + "/" + r1.denominator().get());
    }

This program prints:

2/3

A lot of code for such easy task, hm? But remember that's just an example :-). There are several things worth to be noted:

No constructors - As we don't provide implementation for Rational we can't use constructor. With Qi4j we have to use builders to create new instances.
When rb.prototype is mutable the r1 is immutable - that's built-in property of value composites.

In the next post I'll finally implement behavior - operations add and multiply.

Qi4j - Project setup with Maven and Eclipse

2009-09-18T16:49:00.027+02:00

Qi4j is an implementation of composite oriented programming paradigm written in pure Java. As I'm just taking my first steps with Qi4j I've decided to write down some notes about that. In this post I'll show you how to setup your first Qi4j project with maven and eclipse. So, let's go. Step 1. Create project skeleton. With maven's archetype plugin we can get the skeleton really quickly.

mvn archetype:generate

Use the default project archetype (number 15) Maven asks for the groupId and artifactId.

Define value for groupId: : com.blogspot.javasnippet.qi4j Define value for artifactId: : qi4j-example

The skeleton has been created with the following pom.xml file

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.blogspot.javasnippet.qi4j</groupId>
    <artifactId>qi4j-example</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>qi4j-example</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Step 2. Add Qi4j maven repository. To download Qi4j artifacts we must configure appropriate repository in the pom.xml. To do that add the following section to your pom.xml file

<repositories>
    <repository>
       <id>ops4j-repository</id>
       <url>http://repository.ops4j.org/maven2</url>
    </repository>
</repositories>

Step 3. Add Qi4j dependecies. Qi4j is not a single heavyweight jar but rather a set of small libraries. Then we can take only these we really need.

<dependencies>
    <dependency>
        <groupId>org.qi4j.core</groupId>
        <artifactId>qi4j-core-api</artifactId>
        <version>${version.qi4j-core}</version>
    </dependency>
    <dependency>
        <groupId>org.qi4j.core</groupId>
        <artifactId>qi4j-core-spi</artifactId>
        <version>${version.qi4j-core}</version>
    </dependency>
    <dependency>
        <groupId>org.qi4j.core</groupId>
        <artifactId>qi4j-core-bootstrap</artifactId>
        <version>${version.qi4j-core}</version>
    </dependency>
    <dependency>
        <groupId>org.qi4j.core</groupId>
        <artifactId>qi4j-core-runtime</artifactId>
        <version>${version.qi4j-core}</version>
        <scope>runtime</scope>
    </dependency>
    ...

As you can see the Qi4j version number is set as a property so we must define it (when I'm writing this the latest version is 1.0-RC1).

<properties>
    <version.qi4j-core>1.0-RC1</version.qi4j-core>
</properties>

Busy people can find final pom.xml below.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.blogspot.javasnippet.qi4j</groupId>
    <artifactId>qi4j-example</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>qi4j-example</name>
    <url>http://maven.apache.org</url>

    <properties>
        <version.qi4j-core>1.0-RC1</version.qi4j-core>
    </properties>

    <repositories>
        <repository>
            <id>ops4j-repository</id>
            <url>http://repository.ops4j.org/maven2</url>
        </repository>
    </repositories>

    <dependencies>
        <dependency>
            <groupId>org.qi4j.core</groupId>
            <artifactId>qi4j-core-api</artifactId>
            <version>${version.qi4j-core}</version>
        </dependency>
        <dependency>
            <groupId>org.qi4j.core</groupId>
            <artifactId>qi4j-core-spi</artifactId>
            <version>${version.qi4j-core}</version>
        </dependency>
        <dependency>
            <groupId>org.qi4j.core</groupId>
            <artifactId>qi4j-core-bootstrap</artifactId>
            <version>${version.qi4j-core}</version>
        </dependency>
        <dependency>
            <groupId>org.qi4j.core</groupId>
            <artifactId>qi4j-core-runtime</artifactId>
            <version>${version.qi4j-core}</version>
            <scope>runtime</scope>
        </dependency>

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Step 4. Build the application. Now it's time to download Qi4j dependencies and build the application for the first time.

mvn install

Step 5. Import project to the eclipse workspace. As Eclipse is my favorite IDE I call maven to generate eclipse project files.

mvn eclipse:eclipse -DdownloadSources -DdownloadJavadocs

Start Eclipse and import your fresh project into your workspace. Now you can remove generated files App.java and AppTest.java That's it. In the next post I'll show you how to start up your first Qi4j application.

Collection Literals in Java 7

2009-09-08T22:44:00.004+02:00

Today I read the final list of the Project Coins - the accepted list of Java language enhancement proposals for Java 7. The goal of one of them is to introduce collection literals for List, Set and Map. Probably it will be more convenient to build simple collections with them, but why to bind Java language (through JLS) with java.util.List and its friends? One may say that java.util.* is part of the JDK anyway. For me it's not enough justification for that step which looks more like an attempt to patch Java deficiencies with more or less weak solution. Unfortunately, the backward compatibility requirement doesn't allow to take a better one. I would be happy if I never saw this in Java language.

Some useful eclipse plugins

2009-08-19T10:03:00.002+02:00

I found the following eclipse plugins being very useful. 1. AnyEdit - "AnyEdit plugin adds several new tools to the context menu of text- based Eclipse editors, to output consoles, to Eclipse main menu and editor toolbar. AnyEdit contributes also Import/Export working sets wizards." 2. Extended VS Presentation - "Extended VS Presentation plugin contributes powerful editing sessions management and highly customisable and very useful Eclipse skin ("look and feel")."

Dependency Injection bad practices

2009-06-30T19:46:00.011+02:00

"If all you have is a hammer, everything looks like a nail" - Abraham Maslow To make it clear - I don't claim that DI is evil. I think it's really useful tool. Just a tool like a hammer. Unfortunately very often I can see DI being misused. People tend to put DI in each piece of the application what is often either an overkill or at least unnecessary complication. One of the bad practices I've recognized is programming in XML. That happens for example when (hierarchies of) objects (including abstract objects) are defined in Spring configuration files and then used as injected prototypes in Java code which is coupled to their properties. Simple and clear solution is to introduce factory class to create objects directly in Java code. That's rather rare case but don't worry there are also other more spectacular like for example Anemic Domain Model. Which is very common and appreciated by some people. It decouples basically everything including the data and the logic. In my opinion DI encourages to use this approach because it enforces to drop the encapsulation and lets to do anyone anything - you have to set the properties somehow, right? Of course there are solutions like constructor injection and factory beans but they are used rarely. As far as I remember Spring 1.0 has been announced as a holy grail of JEE development. People dropped EJB2 and started learning Spring. I must admit EJB2 didn't have much in common with object oriented programming as well. The goal of Spring was to simplify JEE project and it has been achieved. Unfortunately Spring has inherited EJB2 functional approach - or Spring users did that. Did you ever seen a Java project written by someone who is dazzled by DI? It's easy to recognize such a project. If during the review you have to analyze call hierarchies defined mostly in DI configuration and distributed among several XML files - that's it. DI is not a golden hammer of software development and we also must remember about the design patterns. The art is to join them together and find the balance to not see everything as a nail anymore.

"From Concurrent to Parallel" by Brian Goetz

2009-06-24T13:03:00.005+02:00

Brian Goetz is talking about the fork-join framework and parallel array types coming in Java SE 7. For me it looks absolutely great. See the presentation

Spring JDBC - don't forget to call compile()

2009-06-19T09:11:00.007+02:00

If you're using Spring JDBC StoredProcedure and if your application produces errors like that below from time to time.


ERROR [...] CallableStatementCallback; uncategorized SQLException for SQL [{? = call foo.bar(??)})}?)}]; SQL state [99999]; error code [17041]; Missing IN or OUT parameter at at index:: 3; nested exception is java.sql.SQLException: Missing IN or OUT parameter at index:: 3

Then check if you call method compile() after defining your IN and OUT parameters otherwise you might expect such an error being thrown during deployment to live system. If compile() is not called explicitly then Spring builds SQL string lazily at first call. If this stored procedure is called in more than one thread in parallel (which is very common scenario) then a race starts. SQL string variable is shared between the threads and as there is no synchronization mechanism involved all threads are appending to it.

Subversion 1.6 for Ubuntu Jaunty

2009-06-16T08:51:00.003+02:00

Subversion 1.6 is now available in the launchpad repository.


deb http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu jaunty main
deb-src http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu jaunty main

MAT - Eclipse Memory Analyzer

2009-06-15T08:34:00.005+02:00

Eclipse Galileo is just around the corner and brings MAT - heap memory analyzing tool on board. Let's give it a try. Here is very nice introduction.

The "species" of Software Architects

2009-02-26T19:52:00.012+01:00

During a discussion with one of my colleagues I was asked to write down the definition of Software Architect I use. I recognized this as a good opportunity to refine the meaning of this term for me as well. First I read what wikipedia says about the Software Architect. Although the article is very detailed I was happy to find my state of knowledge being very similar to it. I'd like to emphasize two following aspects:

One of the agile practices says, the architects must write code. I think, especially Application architects ought to follow this principle. In my opinion such a person should be a skilled and experienced developer with stellar knowledge about the patterns, frameworks, methodologies and tools. And must be an active member of the development team.
Enterprise architects design and coordinate the way the applications communicate with each other. He is interested in the contracts, SLAs. He cooperates with the Application architects and gathers feedback from them.

Improve development with milestones

2009-02-21T19:33:00.014+01:00

The team which I'm member of works in a month long iterations. We often have to develop quite large user stories. To improve our development process we introduced the idea of milestones.
How to define the milestones:

Define about 3-4 milestones (for a month long iteration).
Each milestone must deliver a testable set of functionality.
One milestone can comprise tasks from more than one story.

It gives the following benefits:

Early testing - as the milestone is delivered the QA team can start doing its work.
Better feeling about the progress of the project (besides the burn-down chart).
Smaller goals are easier to achieve.

Of course the idea of milestones is not new. See more at wikipedia

Null Object - the third player

2009-02-02T20:17:00.026+01:00

In my previous post I wrote about my considerations about the exceptions and null values. I suggested one more possibility - an "error-indicating object", which basically means to return a special, recognizable instance of the returned interface. This approach has been already described as the Null Object Pattern. Returned object is supposed to do nothing. This approach is mostly suitable for mocking up business entities. Here I'd like to extend this pattern to the service level. Let's assume we're working on a word processor which is able to read/write documents in many formats. Of course our word processor is very flexible and uses format plug-ins and we are able to add/remove the formats very easily. What happens when I try to open a document file? For sure the word processor has to choose appropriate format handler. It's very common case when the logic is context dependent and is chosen at runtime. Yes, you're right, that's a well known Strategy Pattern. All right, so let's assume there are the following interfaces defined:

public interface DocumentHandlerSelector {
 DocumentHandler selectDocumentHandlerFor(URI documentURI);
}

public interface DocumentHandler {
  Document read(URI documentURI);
  void write(Document documentToWrite);
}

public interface Document {
  boolean isLoaded();
}

Everything is fine as long as the concrete handler can be explicitly chosen by the DocumentHandlerSelector. But what to do if for some reason the application can't pick the correct one? For sure it should show a gentle information about the problems with opening the document in the message box. It can be achieved in two equivalent ways. The first way - throw the exceptions:

public Document open(final URI documentURI) {
 Document document = null;
 try {
     DocumentHandler handler = documentHandlerSelector
         .selectDocumentHandlerFor(documentURI);
     document = handler.read(documentURI);
 }
 catch (UnknownDocumentFormatException e) {
     showMessageBox("The document cannot be opened");
 }
 return document;
}

The second way - use the null objects (for both DocumentHandler and Document):

public Document open(final URI documentURI) {
 DocumentHandler handler = documentHandlerSelector
     .selectDocumentHandlerFor(documentURI);
 Document document = handler.read(documentURI);
 if (!document.isLoaded()) {
      showMessageBox("The document cannot be opened");
 }
 return document;
}

And here are the implementations to make the second example easier to understand:

public class UnsupportedDocumentHandler 
    implements DocumentHandler {

 private static final Document UNSUPPORTED_DOCUMENT 
     = new UnsupportedDocument();

 Document read(final URI documentURI) {
     return UnsupportedDocumentHandler.UNSUPPORTED_DOCUMENT;
 }
}

class UnsupportedDocument implements Document {
 boolean isLoaded() {
     return false;
 }
}

I like the NullObject approach for not returning plain null from the open() method. And what do you prefer?

Throwing an exception vs returning null

2009-01-27T18:02:00.001+01:00

Recently I came across the following problem: How should the callee report a rejection/failure to the caller? I'm writing about the Java components such as business logic services, repositories, etc. Our applications are full of them, thus it should be clear to everybody how to deal with this problem. I can suggest the following possibilities:

Throw checked exception,
Throw unchecked exception,
Return null,
Return some extra error-indicating object.

So, which one should I use? In my opinion only the answers 2 and 4 are correct. However, surprisingly in the last few days I heard from two other Java guys, that I should return a null. In this concrete case the service is a stateless converter which transforms back and forth between the XML message and domain objects. Although the message is well formed and valid the converter may not be able to transform the message, because the transformation is content dependant. Should it then return null or throw an exception? They say it should return null because throwing an exception forces the caller to control the flow with the exceptions. I disagree with that, because from the converter point of view the data it gets is unknown and has to be rejected. The rejection should be reported as an unchecked exception with the exact reason inside. Then the caller can catch the exception and take further steps, or more probably let it bubble up to the MDB and be resolved there.