BDD in Java with easyb (John Ferguson Smart)

John started out by arguing that TDD is not about testing, it's about writing better code. That is, it's about making your code more maintainable, flexible, reliable and simple. TDD is forces the programmer to think about how to test the class before actually writing the class. BDD, on the other hand, helps to determine what to test and to write more focused code, by starting with the behavior. Instead of thinking that you're testing your class, you should think that you're validating your requirements!

easyb is a BDD testing framework for Java, written in Groovy (hence providing full access to all Java API's). It ensures that tests become clearer and easier to both write and read! It helps the developer to focus on the requirements only. A competitor to easyb is JBehave, which is an extension to JUnit. However, according to John, JBehave is more cumbersome than easyb.

easyb makes use of stories, much like the story cards in the Agile world. In a story, a narrative approach is used to describe a precise requirement. In easyb, a story could look like this:

 
scenario “Make initial deposit onto a new account”, {
	given “a new account”
	when “an initial deposit is made”
	then “the balance should be equal to the amount deposited”
}
 

This scenario is quite clear and readable, isn't it!? Furthermore, it's self-documenting - a very appreciated feature =) And the syntax is so trivial that even a non-technical stakeholder would have no problem understanding it. The developer can then reuse the given scenario (pseudo) code and implement the test case, like this:

 
import com.mycompany.bankonline.domain.Account
 
scenario “Make initial deposit onto a new account”, {
	given “a new account”, {
		account = new Account()
	}
	when “an initial deposit is made”, {
		initialAmount = 100
		account.makeDeposit(initialAmount)
	}
	then “the balance should be equal to the amount deposited”, {
		account.balance.shouldBe initialAmount
	}
}
 

The shouldBe call is an intuitive and readable way to verify that the requirement holds. Another way to verify the outcomes is to use the ensure syntax. Example:

 
ensure(account.balance > 0)
 

or

 
ensure(account) {
	has([balance:100])
}
 

easyb could be extended to use DBUnit (and further plugins for Grails and Excel are on the way). On the IDE support, the only good option is IntelliJ IDEA. It really comes down to the Groovy support, and Eclipse and NetBeans doesn't shine here. In those cases, you're better off running the tests in Maven or Ant, which both are well supported. In the upcoming version, easyb will have full support for Continuous Integration (CI), enabling automatic test execution in a CI-server such as Hudson.

Furthermore, easyb comes with a web application - Easiness (cmp. Fitnesse) - where stakeholders can create stories in plain text. The developers can then go ahead and implement the stories defined by the stakeholders. This is an important features, that further improves the cooperation between the customer and the provider. It really seems like a quite nice little framework! If you agree, have a look at it at http://easyb.org/.

From Concurrent to Parallel – Library-based parallelism in JDK 7 (Brian Goetz)

Brian is an expert in the concurrency area, but he's not a good presenter! He speaks faster than I can read, and his slides are so packed with info that he doesn't have time to say the half of it. That put aside, in this very interesting session Brian presented some really cool concurrency features to be included in JDK 7.

As you probably know, JDK 5 introduced a set of very useful classes for course-grained parallelism. JDK 7 will introduce a framework for fine-grained parallelism - the "fork-join" framework.

We have now reach a point in time when Moore's laws isn't valid anymore. The new reality is not faster CPUs but more CPUs. To adapt to these changes, programmers have to change the way they think about parallelism. The unit of work (UoW) that represents a task to be solved must be split into even smaller parts to be able to keep all hardware busy. Nowadays, it isn't enough to for ex. spawn a new thread for each service call in a server, the UoW must be split up even further.

Examples of finer-grained parallelism is searching, sorting and filtering a data set. Such a task is preferably solved by dividing it into sub-problems and combining the sub-results at the end. We could use the course-grained concurrency tools (for ex. Executor + Future) introduced in JDK 5 to solve this problem. However, with multiple CPUs available, these tools doesn't perform optimally. For ex., the shared work queue in the Executor becomes a bottle neck when the number of threads/CPUs increases. Furthermore, these tools provide no form of load balancing, i.e. if one thread finishes before the others, it is never reused.

The divide-and-conquer algorithm could also be applied to solve the problem. This great advantage of this approach is that it's independent of the number of CPUs used! Using plain threads for this approach is too expensive though, since thread creation costs way too much. However, the fork-join-operation in JDK 7 solves problems like these using the divide-and-conquer algorithm in a much more effective way! Internally, it uses an slim thread pool to overcome the cost of thread creation. Furthermore, no data-copying penalty exist since the data set (for ex. an array) is not divided/copied during the solution. Instead, the indexes within the data structure is used to define each data subset. Another advantage is that the code doesn't know how many CPUs it executes on, hence it's portable!

While the Executor (JDK 5) should be used for tasks consisting of both IO and computing, the fork-join-operation (JDK 7) should be used for highly compute-intensive tasks. Examples of such tasks are matrix operations, numerical integrations and game playing. The JDK 7 class to be used for these kind of problems is ParallelArray. It's a utility class that greatly simplifies the work of solving a task in parallel. You can think of it as an in-memory database for data sets. Typical usage is:

 
ParallelLongArray pa = ParallelLongArray.createUsingHandoff(array, forkJoinPool);
long max = pa.max();
 

The ParallelArray class provides operations for:

• Filtering (nestable)
• Mapping
• Replacement
• Aggregation (max, count, sum, ...)
• Application (one action performed for each selected element)

To compare, the ParallelArray class acts much like the Map-Produce concept introduced by Google but it works in a different domain (local system instead of in a distributed system).

The only downside really is that JDK 7 isn't scheduled until mid 2010, meaning we'll have to wait quite some time before we can actually use these new concurrency features. But from the looks of it ... it may be worth the wait!

The SpringSource DM Server (Joris Kuipers)

The reasons why SpringSource decided to develop a new application server were many. Today, modularity is important and developers spend much time on achieving it in their applications (layering, separation of concerns, etc.). However, when the application is deployed, all modularity is lost - the deployable unit is one huge, monolithic WAR file. That means that sharing code (let alone services) between applications become hard if not impossible. In order to perform the smallest update on the application, whole WAR file have to be redeployed. Furthermore, the servers themselves lack modularity; they come prepackaged with a lot of modules but there's no way to configure that your application only make use of a couple of them. Hence, they are all left in there, consuming unnecessary CPU cycles and memory.

The DM (Dynamic Modules) server was developed to tackle these issues of non-modularity. In order to achieve true modularity, is has been built on top of OSGi (namely the Equinox container). Since OSGi can be quite hard sometimes, the DM server conceal the complexity of OSGi in the same way as the Spring framework does with for ex. Remoting or JMX.

In order to be able to use a third-party library from within the DM server (and from any other OSGi containers), the standard JAR library needs to be extended with OSGi-specific meta data - the OSGi manifest. SpringSource has therefore created the Enterprise Bundle Repository, where they have started to upload and publish OSGi-ified Java EE libraries. If you're using Maven or Ivy, the bundle repository can easily be configured as a remote (or local) repository.

The DM server also introduces a couple of new OSGi import constructs, enabling ease of development. One example is the "Import-library" that can be useful if you want to make use of a framework (for ex. Spring) but don't want to waste your time having to specify every single Import-package (for example Spring-Remoting) within the framework (as you normally would have had to do). This doesn't affect performance improvement since (thanks to OSGi) none of the pre-installed bundles are loaded before they are actually used! Furthermore, with the DM server it's now possible to remove the library bloat of monolithic Java EE WARs. Instead of building the external libraries into your WAR, you can instead declare them as dependencies in the OSGi manifest headers. The server will then convert these into plain "Import-package" constructs during deployment. That way, the size of the built/deployed WAR can be reduced significantly!

In the DM server, one can of course deploy plain OSGi bundles but also WARs, EARs etc. Typical scenarios for deploying a plain OSGi bundle are stand-alone libraries, global services and small stand-alone applications. However, being able to deploy a bundle is not enough in most cases ... A normal application normally consist of multiple bundles, which becomes hard to un/deploy since there is no single deployable unit. Furthermore, with multiple bundles you don't get a common log file or a notion of an application scope. To tackle this issue, the DM server adds the notion of an application by introducing the PAR (Platform Archive) format. It's basically a JAR with a number of 'Application-*' manifest headers. You can think of it as an EAR in Java EE. PARs are versioned and the versions apply to all of their bundles. This mean that one can deploy a PAR twice with different versions but with the same bundles, without conflicts.

The DM server comes in several versions. Of course there's the community version, using a GPL and SpringSource license. Then there's the commercial license where full support from SpringSource is included. On the extension side, better Maven support will soon be released so that the dependencies can be specified in a single place (not like now when you have to duplicate them in the pom and in the manifest). There's a Eclipse-plugin available that enables re/deployments from within the IDE.

These are some of the features in the DM server. There are plenty or more cool ones, read all about them here. There, you'll also find a lot of sample applications that can get you going! With the DM server, SpringSource feel that they are filling the (up until now) empty space of server side OSGi and states that "The DM server is the healthy new way to run your apps!". I must say it looks very promising! Why don't you go ahead and try it out!? I know I will!

If you appreciated these posts, you will definitely enjoy next years conference! Pick up your calendar and reserve December 2009 for a great week at Devoxx!

Low level constructs

In the new API, there are representations of the classical concurrency constructs of
locks, semaphores, latches and barriers. The Lock interface, for example, behave very
much like the intrinsic lock (used in synchronized blocks). However, the biggest
advantage of Lock objects is their ability to back out if the lock isn’t available, either
immediately or within a specified timeout, allowing the implementer to take an al-
ternate action. Furthermore, the new Lock interface also allows locks to be acquired
and released in different code blocks. The drawback of the new Lock class is that
it’s more complex, above all it requires the programmer to remember to release the
lock. In a similar manner, there are useful implementations of semaphores, latches
and barriers.
The concept of atomicity is central in concurrency. An atomic operation is one
that cannot be interrupted by a concurrently running process. The Java increment
operator, i++, is not an atomic operation (internally it’s three operations) but a sim-
ple assign (i = 5;) is. The java.util.concurrent.atomic package defines classes that
support atomic operations on single variables. For example, in order to protect a
variable incrementation (i++) from thread interference without resorting to syn-
chronization, the variable can be kept in an AtomicInteger and the increment can be
performed using the incrementAndGet() method, thus ensuring atomicity.

New Collection types

The java.util.concurrent package includes a number of additions to the Java Collec-
tions Framework. The new concurrent collections are improvements over synchro-
nized collections in terms of throughput and efficiency. Synchronized collections
achieve their thread safety by protecting the collection’s state by a collection-wide
lock. When accessed by multiple threads, throughput suffers. Concurrent collec-
tions, on the other hand, are designed for concurrent access from multiple threads
and instead lock on the individual elements.
Two important new Collection types are BlockingQueue and ConcurrentMap.
BlockingQueue implements the (non-concurrent) Queue interface, which holds
elements prior to processing. The thread-safe BlockingQueue is primarily designed
for producer-consumer queues and allows clients to wait for an element to appear
(possibly within a specified timeout). Waiting occurs if you either try to insert an
element into a full queue or if you try to retrieve from an empty queue. Concur-
rentMap defines a couple of very useful atomic map operations:

• A key/value pair is removed/replaced only if the key is present in the map.
• A key/value pair is added only if the key is absent.

Hence, there’s no need to synchronize when accessing the ConcurrentMap.

High level constructs

The new Callable interface is responsible for encapsulating a task. It’s similar to the
Runnable interface; both are designed for classes whose instances are potentially
executed by another thread. However, Callable returns a result and may throw an
exception. The utility class Executors has methods for converting from other com-
mon task forms (such as Runnable) to a Callable. Furthermore, a Callable can be
executed by the ExecutorService class in the submit() method.
The Future interface is an important entity in the new Executor framework and
represents the result of an asynchronous computation. The result can be retrieved
using one of the get() methods when the computation has completed, blocking if
necessary until it’s ready. The interface provides a possibility to cancel the computa-
tion and it’s also possible to determine if the task completed normally or if it was
canceled. A Future is normally used in the following manner:

Future futureResult = executor.submit(
   new Callable() {
      public String call() {
         // perform heavy op and return result
      }
   }
);
doOtherThings();
try {
   useResult(futureResult.get());
} catch (ExecutionException ee) { cleanup(); }

Notice how the result is retrieved - get() might be blocking (depending on if the
computation is ready or not by the time of the invocation).
Executor is a simple interface for launching new tasks. It provides a way of decou-
pling task submission from the mechanics of how each task will be run, including
details of thread use, scheduling, etc. The single method in the interface, execute(),
has been designed to replace the way we normally use threads. That is, instead of
explicitly creating a new thread for each task to execute, all tasks are executed by a
single Executor. How the Executor actually executes the tasks internally is imple-
mentation-dependent.

The ExecutorService interface extends the Executor interface and adds fea-
tures for managing the life cycle of both individual tasks and the executor itself. It’s
submit() methods accept both Runnable and Callable objects and returns a
Future. An unused ExecutorService should be shutdown() to reclaim its resources.
The ExecutorService interface also provide methods for submitting large collections
of Callable objects.
It’s time for an example. An implementation of a simple web server might look
something like this:

public class WebServer {
   /**
    * Creates a server socket, accepts connections,
    * and handles each incoming request in a new thread.
    */
   public void run() throws IOException {
      ServerSocket socket = new ServerSocket(8080);
      while (true) {
         final Socket connection = socket.accept();
         Runnable task = new Runnable() {
            public void run() {
               handleRequest(connection);
            }
         };
         new Thread(task).start();
      }
   } 

   public static void main(String[] args)
         throws IOException {
      WebServer webServer = new WebServer();
      webServer.run();
   } 

   private void handleRequest(Socket connection) {
      // Impl. details not important here!
   }
}

In order to achieve high responsiveness, each new request is handled in a new
thread. Under light to moderate load with sufficient CPU resources available, this
implementation offers relatively good throughput too. However, it would be nice to
have a more flexible solution supporting a wide variety of task execution policies, i.e.
for ex. to be able to specify in what thread and in what order tasks will be executed,
and how many tasks may execute concurrently. Let’s introduce an Executor:

public class ThreadPerTaskExecutor implements Executor {
   public void execute(Runnable r) {
      new Thread(r).start();
   };
}

, which leaves us with the following run() method:

public void run() throws IOException {
   Executor exec = new ThreadPerTaskExecutor();
   ServerSocket socket = new ServerSocket(8080);
   while (true) {
      final Socket connection = socket.accept();
      Runnable task = new Runnable() {
         public void run() {
            handleRequest(connection);
         }
      };
      exec.execute(task);
   }
} 

The great advantage of this approach is of course that the execution policy could
very easily be substituted (even configured at deployment-time) without altering
the rest of the code base. However, one big problem still exists with this solution!
Under heavy load a lot of threads will be created, and thread creation and teardown
takes time and active threads consume a lot of memory. Furthermore, each platform
has an upper limit on how many threads that can be created, and when this limit is
hit an OutOfMemoryError is probably thrown. Hence, up to a certain point, more
threads can improve throughput but beyond that point, creating more threads just
slows down the application and may even lead to a crash. The way to stay out of
danger is to place some bound on how many active threads your application utilizes
concurrently.
Most of the executor implementations internally make use of thread pools,
which consists of worker threads. Worker threads are often used to execute mul-
tiple tasks and minimize the overhead caused by thread creation. One common
thread pool type is the fixed thread pool, which always has a specified number of
threads running. The Executors class contains factory methods for retrieving Execu-
torServices that in turn use different kind of thread pools internally. For example,
newCachedThreadPool() creates a thread pool that creates new threads as needed
but will try to reuse previously created threads when available.
To be on the safe side with regards to both throughput and responsiveness in the
web server example, an executor that uses a thread pool internally should be used:

public void run() throws IOException {
   Executor exec = Executors.newFixedThreadPool(100);
   ServerSocket socket = new ServerSocket(8080);
   while (true) {
      ... // same as above
   }
}

Conclusion

As you can imagine, Java 5 has given us a lot of great high level features in the
new concurrency package. However, they extend (not replace) the traditional low
level concurrency constructs, such as the synchronized keyword and the wait/notify
mechanism, who still have a vital role to play. Your concurrency toolbox has just
become bigger and more flexible.

References

1 The JavaDoc
2 Java 5 Collection Framework changes
3 “Java Concurrency in Practice” (Brian Goetz et. al.), ISBN 9780321349606
4 Concurrency Tutorial