Java 5 Thread framework

To develop solutions related to work load management or batch processing or job parallelism, developers invented their own design using standard classes from java thread package or utilities provided by J2EE container based mechanisms like commonj framework. Implementing homegrown solutions using Thread or Runnable interfaces had serious limitations that it cannot communicate back the status of the job executed, or cannot be reused across many job requests. Besides, the low level concurrency primitives such as synchronized, notify, wait, etc., are either difficult to use correctly or difficult to debug and detect in case of errors.

Recently, I encountered one such implementation developed during Java 2.0 days. It was homegrown framework designed to handle critical batch jobs of high volume. It seem to have worked well for business which surprised me and after a little bit of probing, it was evident the application support would intervene and restart the job processes if there were failures, and besides batches were not bound by any SLA. To speed up execution cycle developers were spawning threads in a loop controlled by sleep intervals. Not a design one would want if it executes critical business processes.
With Java 5.0+, a lot has changed in the threading space with the inclusion of concurrent libraries (earlier these were standalone third party binaries without concurrent collections and scheduling framework). Concurrency utilities provide many advantages to developer community like,

# Reduced programming effort. It is far easier to use a standard class than to develop it yourself.
# Increased performance. The implementations in the Concurrency Utilities were developed and peer-reviewed by concurrency and performance experts; these implementations are likely to be faster and more scalable than a typical implementation, even by a skilled developer.
# Increased reliability. By using standardized, extensively tested concurrency building blocks, many potential sources of threading hazards such as deadlock, starvation, race conditions, or excessive context switching are eliminated.
# Improved maintainability. Programs which use standard library classes are easier to understand and maintain than those which rely on complicated, homegrown classes.
# Increased productivity. Now that it is part of Java API, developers are more likely to be familiar than any third party libraries and behavior.