Java Reference
In-Depth Information
Java was designed to support multiple threads from its start. However, it failed to provide a simple
approach to making asynchronous calls. The
Future<T>
interface, which was introduced in Java 5,
was Java's i rst attempt at implementing asynchronous programming, but it was cumbersome
and tricky to use. Subsequent versions of Java introduced the
@Asynchronous
annotation. The
asynchronous servlet provided a much better set of tools to aid in asynchronous programming.
WHAT IS ASYNCHRONOUS PROGRAMMING?
The asynchronous programming pattern is a special and well‐integrated case of multiple threads.
Due to the nature of threads, multithreading models tend to need notii cation systems and depend
on boilerplate code to initiate threads.
Asynchronous calls are used even in single‐threaded environments like Node.JS. Almost all user
interface (UI) frameworks use asynchronous execution to keep UI active and responsive. The i rst
“A” of AJAX,
1
which powered the Web 2.0 movement, stands for asynchronous.
However, asynchronous programming can be useful in places other than user interfaces, typically
on the sever side. Neither J2SE nor J2EE offered a built‐in easy implementation for asynchronous
programming. With Java 5, the Concurrency Framework, based on JSR166, was released. JSR166
included many utilities that made asynchronous programming possible, easier, and better controlled.
The
Future<V>
interface also provided a way to help developers to implement asynchronous
method execution.
Meanwhile, Spring offered asynchronous method calls, which are enabled with annotations.
Java EE did not include such a convenient solution until version 6.0. The
@Asynchronous
annotation was introduced with Java EE 6 and offered an easy way to implement asynchronous
method execution.
Asynchronous Pattern
Asynchronous programming is not listed as a design pattern in either the GoF
2
book or in the
Head
First Design Patterns
3
book. If it was, its description might be “Provides a way to invoke a method
without blocking the invoker.”
The nature of method execution is to block the caller until the called method i nishes its execution.
This behavior is straightforward and expected but may not be desired in all cases. Almost all UI
frameworks and web platforms rely on nonblocking requests.
WAR STORY
I was given the task of developing the customer services web portal for
a telecommunications company. We had implemented a detailed logging
infrastructure while developing the portal. We did not log to a database to ensure
