Recent Posts

One of the more commonly used approaches for software API design is Bertrand Meyer’s Design by Contract. While it can be a very powerful technique, DbC can also be cumbersome (and overly strict) since to do it "correctly" a method’s contract must define its: preconditions, postconditions, invariants, and side effects.

My preference is to utilize a lightweight form of DbC in which a method contract only stipulates the required preconditions and the expected outcome (side effects) of the method’s successful execution. The contract can be expressed with the method’s description and parameter documentation via javadoc. How do you enforce the contract’s precondition constraints to allow for early failure during method invocation?

Guava has you covered with its Preconditions utility. Let’s take a look at why a pure Java precondition verification implementation is truly dreadful.

If you haven’t had the pleasure of using Google’s Guava library with your favorite JVM-based language, I hope that I can convince you to give it a spin. In my opinion, Guava is one of those must-have libraries that should be on your classpath for practically any project. This post will be the first of several that will spotlight some of my favorite utilities provided by Guava. Enough with the flattery, let’s take a look at what makes Ordering so useful.

The Ordering wiki states that the class should be thought of as a "fluent" Comparator. What does this mean? Well, first off Ordering is an implementation of Java’s Comparator interface. Therefore, any place that you can use a Comparator, you can use an Ordering instance. What makes Ordering fluent? Take a glance at the API. The method names and how they’re chained together is what provides the powerful fluency; performing operations just makes sense due to its readability. Let’s look at some examples to see things in action.

Have you ever had to endure the agony of debugging a piece of code that mutates the state of an object several times throughout an application? Not only is that type of code ugly and unpredictable, it’s downright dangerous when dealing with multiple threads.

An immutable object ensures that its internal state cannot be changed after instantiation. Why does this matter? This provides an immediate benefit when working with multi-threaded code in that no synchronization needs to be performed since the object does not offer any shared, mutable state between threads. Therefore, the state of the object remains the same throughout its lifetime which makes the object automatically thread-safe.

Are you looking for a way to associate your continuous integration server’s build information with your web application? I’ve already discussed how to easily inject the properties from a Jenkins build job into your Maven artifacts. Let’s see how a similar approach can be used for a packaged Grails WAR file.

I’ll assume that you have access to the following Jenkins job’s environment variables:

How many times have you tried to debug a problem with one of your components in production without knowing which revision of the codebase has been deployed? Many times the Maven artifact version number isn’t sufficient. Sure, you know the release version of a certain JAR file (1.0.1000 for example), but how do you know if this contains a specific source code commit? Not to mention debugging during development when your artifact versions are typically *-SNAPSHOT; that’s not very useful at all.

We’re going to configure a poor man’s configuration management scheme to incorporate more information with your build artifacts. Let’s assume that you have a continuous integration server setup to build your project’s artifacts. Here are some pieces of information that would be useful to bundle with a JAR, WAR, etc.: