Skip navigation
ANNOUNCEMENT: is currently Read only due to planned upgrade until 28-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

Recently, I've been investigating the methods Java provides for developing desktop applications that efficiently utilize multicore processors. Java 7's Fork/Join Framework is the current focus of my investigation. But, Brian Goetz has just provided an update on the State of the Lambda: Libraries Edition, which tells us lots about the current status of what's coming up in Java 8, where Project Lambdawill introduce Lambda Expressions into Java.

It probably shouldn't be a big surprise, but implementing Lambda Expressions in Java 8 is going to have a very wide-ranging impact, on everything from the Collections framework to "laziness" to streams to parallelism to mutative operations... Brian takes the time to go into the details on these and other aspects of Lambda Expressions as the current work on Java 8 is progressing.

Brian states:

This document describes the design approach taken in the rough prototype that has been implemented in the Lambda Project repository. It is intended as a working straw-man proposal; the final version may look different, but there is a working design and implementation that may now serve as a jumping-off point for discussions.

If the implementation of Lambda Expressions in Java 8 is of considerable importance to you, this is a must read. The final implementation is no where near final at this point, and Brian is in essence asking people for suggestions. Take advantage of the offer to comment -- but, first, take the time to read Brian's State of the Lambda: Libraries Edition. Weblogs

Since my last blog post, several people have posted new blogs:


Our current poll asks Voting will be open until Friday, April 27.

Java News

Here are the stories we've recently featured in our Java news section:


Our latest Spotlight is Arun Gupta's Chennai Java Summit 2012 Trip Report:

I attended my first Chennai Java Summitlast weekend. The one-day conference had two parallel tracks. The conference was organized as part of AIOUG (All India Oracle User Group) and so there was a parallel track covering Oracle technologies as well...

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed. You can find historical archives of what has appeared the front page of in the home page archive.

-- Kevin Farnham
Twitter: @kevin_farnham

A few nights ago, I was browsing the chapters about concurrent programming in Herbert Schildt's excellent Java: The Complete Reference, 8th Edition, and I was struck by the evolution of concurrency in Java over the years, from threads, through the richness of Java 5's Concurrency Utilities, and on to Java 7's Fork/Join Framework. The Java language truly has grown, adapted to the changing world, to the innovations of the hardware platforms on which it runs. And, of course, Java 8 will include Lambda Expressions, or "closures" (JSR 335).

One thing I've wondered is: in what ways are Java threads inadequate? Yes, manual thread management is a pain, fraught with potential for trouble, strange difficult-to-reproduce problems, etc. As I wrote in my last blog post, I have personal experience working on an application where the app ran flawlessly on our own corporate development and test platforms, but keeled over onto itself and brought our customer's much faster, more powerful systems to a halt a few minutes after the program was started up. Concurrent programming is a strange universe, indeed.

The Concurrency Utilities made things easier by adding features like java.util.concurrent.atomic, java.util.concurrent.CyclicBarrier, and perhaps most notably java.util.concurrent.ThreadPoolExecutor. So, with all these convenient new java.util.concurrency features making programming using threads easier, why did we need something like the Fork/Join Framework? Why do we think we need Lambda Expressions?

On page 893 of his book, in the section titled "Parallel Programming via the Fork/Join Framework," Herb Schildt explains:

The Fork/Join Framework enhances multithreaded programming in two important ways. First, it simplifies the creation and use of multiple threads. Second, it automatically makes use of multiple processors.

But, from this description, we still don't have a clear idea of what was "wrong" with plain old Java threads, do we?

On the next page, Herb says:

it is important to point out the distinction between traditional multithreading and parallel programming. In the past, most computers had a single CPU and multithreading was primarily used to take advantage of idle time, such as when a program is waiting for user input. Using this approach, one thread can execute while another is waiting... Although this tyupe of multithreading will always remain quite useful, it was not optimized for situations in which two or more CPUs are available (multicore computers).

So, that's the answer to my question. Java threads are not optimized for parallel computing. The Fork/Join Framework is.

Indeed, in his paper "A Java Fork/Join Framework" Doug Lea reports that his Fork/Join implementation of a class that computes the Fibonacci Function "runs at least thirty times faster than an equivalent program in which each new task is run in a new java.lang.Thread." That's a remarkable difference!

I'll be experimenting with the Fork/Join Framework very soon. Among my first tests will be developing Fork/Join Framework implementations of some of the experiments I did earlier with Java threads (documented in my blog posts "Multicore Desktop Application Experimentation, Part 1: Java Threads" and "A Look at Java Thread Overhead"). I'm looking forward to this! Weblogs

Since my last blog post, several people have posted new blogs:


Our current poll asks Are you aware of Oracle Enterprise Pack for Eclipse (OEPE)?. Voting will be open until Friday, April 27.

Java News

Here are the stories we've recently featured in our Java news section:

In some earlier posts, I've talked about Java threads, Java Thread Overhead, and Amdahl's Law and Parallel Processing Speed-Up. My next investigation in this series is Java 7's new Fork/Join Framework. I plan to spend quite a lot of time in this particular investigation. For one, Java Threads have been around for a long time, and undoubtedly there are many resources available that discuss them; but the Fork/Join Framework is new, and hence, by spending more time investigating the characteristics of the framework, I'll be helping to provide a roadmap or points for thought/discussion for other developers.

This first post is a basic introduction to the framework, pointing out some of the available resources, outlining the basic concept of the framework, etc.

So, to start with, what do the terms "fork" and "join" mean in this context? If you're a Unix/Linux programmer, you very likely know that the fork command creates a process that is duplicate of itself, known as a "child" process. From there, the two processes can work on different segments of a problem. The results of the processing of the separate segments of the problem can then be "joined" to produce the final product. This approach is advantageous if multiple processes can execute simultaneously, for example on a multiprocessor system like the 8-processor Sun servers I worked with starting in 1993, or on a modern dual- or quad-core desktop PC.


A kind of sad side note: the term "fork" is also used when a group of people takes an open source code base and begins separate development on that code. The same term is used, but unfortunately, in open source development there is no accompanying "join" that rebuilds the accumulated work from the original effort and the "forked" effort into a unified final product. In the open source world, a "fork" is the proverbial "fork in the road" wherein the path taken never reunites with the path foregone...

Anyway, Java 7's Fork/Join Framework is Unix/Linux-like in the manner in which it divies up work, then joins all the subcomponent results into a single unified result. The Fork/Join Tutorial states that:

The fork/join framework is distinct because it uses awork-stealing algorithm. Worker threads that run out of things to do can steal tasks from other threads that are still busy.

This reminds me of Intel's Threading Building Blocks(TBB), a C++ library for achieving parallel processing. I know a lot about TBB, since I was the original editor / community manager for open source TBB back in 2007-2008 when TBB was first open sourced. The "work-stealing" method has a long, and in my view successful, history as a method for making achieving efficient parallel processing that's not terribly taxing on the developer.

Julien Ponge agrees with me on the "not terribly taxing" statement in his OTN article Fork and Join: Java Can Excel at Painless Parallel Programming Too! Julien's article shows that:

rich primitives can be used and assembled to write high-performance programs that take advantage of multicore processors, all without having to deal with low-level manipulation of threads and shared state synchronization.

And, that last phrase is the key: dealing with low-level manipulation of threads and synchronization... If you've ever developed multithread applications in any of the older languages... Put it this way: coping with thread management is bad at the development level. Move to the test/debug level, and it becomes a nightmare. A real-life illustration from my own personal experience:

Big Boss: Your app is producing random results and crashing for our most important client!

Developer: I tested that thoroughly, completely, perfectly, all results were correct in the 18,476 tests I ran on our systems, and there were no crashes!

Big Boss: You're saying our most important customer is lying? Get yourself to their data center ASAP!

... At the customer's data center, the developer realizes the customer's computers are much more high-end than the ones he developed and tested the app on. There is a bug in the thread management, memory overwrites, something that happens on the customer's high-end computers that never happens on the computers on which the multithreaded software was developed and tested... whoa!

Developer (thinking): Now what do I do? Ask the customer if I can develop the fix using their operational system as my test bed? Won't that seem weird to them? But, do I dare do the obvious -- ask Big Boss to buy as high-end computers as our huge-business customer has? But, if miraculously he approved, then I'd have to spend weeks developing a test that simulates Big Customer's data analysis situation. Mightn't they decide to go with IBM's very expensive but proven solution before I can accomplish that???

Those with experience know: managing threads on your own isn't a pretty situation. I've done it, both in creating a custom data center (the safe way, since you can indeed test on the actual computers the software will run on), and in the blockquoted situation, where I was working for a software vendor, and what worked on our computers failed miserably on our big customer's much fancier more high-end systems...

Yes, I've been very deep in the thread trenches (since 1993!). Or, fallen very deep into the trenches? I consider myself a very good programmer, but dealing with native thread management? Please, at this point in my career, can't I just sit back and watch it all happen for me instead? Yeah, manage the threads for me, Fork/Join Framework. I'll take that!

Just to whet your appetite, here are a few more links to articles developers have written about the Fork/Join Framework:

I very much look forward to my upcoming experiments with Java 7's Fork/Join Framework. Stay tuned if this topic interests you! Weblogs

Since my last blog post, several people have posted new blogs:


Our current poll asks How often do you attend Java conferences?. Voting will be open until Friday, April 20.

Java News

Here are the stories we've recently featured in our Java news section:


Our latest Spotlight is Heather Van Cura's Recent JSR Updates-JSR 356, 357, 355, 349, 236 :

JSR 357, Social Media API, was not approved by the SE/EE EC to continue development in the JCP program. JSR 356, Java API for WebSocket, was approved by the SE/EE EC to continue development in the JCP program...

Previously, we featured Deepak Vohra's JSF 2.0 for the Cloud, Part One:

JavaServer Faces 2.0 provides features ideally suited for the virtualized computing resources of the cloud. Here, in Part One of a two-part article, we look at @ManagedBean annotation, implicit navigation, and resource handling...

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed. You can find historical archives of what has appeared the front page of in the home page archive.

-- Kevin Farnham
Twitter: @kevin_farnham

With the advent of multicore processors on everything from desktop computers to tablets, pads, and even mobile phones, parallel processing is gaining increasing attention. This is at least in part what's behind the release of the Fork/Join Framework in Java 7, and the inclusion of Lambda Expressions(aka "closures," JSR 335) in the upcoming Java 8.

While the "do-it-yourself" approach to developing an application, or a component of an application, that performs processing in parallel, is fraught with complexity (thread management, etc.) and potential for error (memory overwrites, threads that die, threads that never return...), if you parallelize your code using the Fork/Join Framework or Java 8 Lambda Expressions, much of the overhead associated with thread management will be taken care of for you.

Still, parallelizing your application isn't always as beneficial as you might think. For starters, there's Amdahl's Law, which defines the theoretical limit for speeding up your application, or component, based on the amount of processing that can be parallelized and the amount of parallelization that can be applied. Here's one form of the Amdahl's Law equation:

MaximumSpeedUp = 1 / [(1 - P) + P/N]
where P is the fraction of the total processing that can be parallelized, and N is the parallelization factor. In practice, you can think of N as being the number of processor cores you'll be utilizing for running the parallelized portion of your application.


So, let's look at what this implies...

The plot (from Wikipedia) shows the theoretical maximum realizable speed-up for four different applications (where 50%, 75%, 90%, and 95% of the processing can be parallelized) if the portion of the code that can run in parallel utilizes from 1 to 65536 processor cores.

What you realize pretty quickly is that in all cases there's a limit after which throwing more processors at the problem gains almost nothing that would be noticed by a user of an application. The limit in possible speed-up is readily calculable: set N to infinity, and Amdahl's Equation reduces to:

MaximumSpeedUp = 1 / [1 - P] = 1/S

Here we're defining S as the fraction of the processing that must be run in serial mode (i.e., the part that cannot be parallelized, or 1 - P). From this, you see that the maximum speedup limit is entirely determined by the the portion of the application that must be run in serial mode, using a single processor.

But, Amdahl's Law actually is a simplification of reality. Parallelizing an application component involves processing overhead that does not exist in serial processing. It takes time and processing to divide the task into multiple chunks that can be divied out to the available processors, time and processing to manage the threads/processes as they are running, and time and processing to collate the subresults produced by each of the parallel processes into the data unit that is the final product of the processing.

In A Look at Java Thread Overhead I showed that, using standard Java threads, there is indeed a limit with respect to size of task after which thread overhead comes to occupy more time than the task itself. My point was to show that, indeed, creating threads and joining them back does occupy processing time.

Bringing the additional overhead into Amdahl's Equation, we get something like this:

ActualSpeedUp = 1 / [S + P/N + Ttm + Tdiv + Tjoin]


  • S is the fraction of the processing that runs serially;
  • P is the fraction of the processing that can be parallelized;
  • N is the number of parallel processes/threads utilized;
  • Ttm is the time spent on thread management;
  • Tdiv is the time spent on dividing the task into N chunks; and
  • Tjoin is the time spent on joining the subresults into the final product unit.

From this you can see that there are many possibilities whereby an application component that has been parallelized might actually take longer to execute than a serial version of the same component.

I'll be writing much more about the topic of parallel processing in the future. This is just a start! Weblogs

Since my last blog post, Community Manager Sonya Barry posted a new blogs:


Our current poll asks How often do you attend Java conferences?. Voting will be open until Friday, April 20.

Java News

Here are the stories we've recently featured in our Java news section:


Our latest Spotlight is Patrick Curran's Merging the Executive Committees:

As I explained in this blog last year, we use the Process to change the Process. The first of three planned JSRs to modify the way the JCP operates (JSR 348: Towards a new version of the Java Community Process) completed in October 2011. That JSR focused on changes to make our process more transparent and to enable broader participation...

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed. You can find historical archives of what has appeared the front page of in the home page archive.

-- Kevin Farnham
Twitter: @kevin_farnham

It seems not that long ago that the JavaOne 2012 Call for Papers began. Yet, here we are, in the CfP's final weekend! All proposals for JavaOne 2012 sessions must be submitted by 11:59 PM Pacific Daylight Time (US) on Monday. Now, I'm not going to try to compute the equivalent local time for everyone around the world. In my experience, you don't try to submit something like this at the very last minute. What if your internet connection goes down, or a glitch occurs somewhere else? Getting your submission in well before early morning GMT on Tuesday is my advice.

Now, if only I can follow my own advice!

I'm proposing my first ever JavaOne session. We'll see what happens. My proposed session is related to the emergence of multicore desktop computers, tablets/pads, and mobile phones. I plan to go over the history of increases in processing speed, which reached a kind of limit some years ago. Once rapid increases in processing speed in a single processor core were no longer attainable, chip manufacturers started making multicore chips. So, the total processing power per chip continued to increase. But now, instead of the power increasing due to increased processing speed in a single core, the increased power came from multiple cores residing on a single chip.

This, of course, has major implications for applications. If your app is not multithreaded, it will use only one of the processor's cores. So, if someone has a quad-core device, your app will be using only one of those cores if it's not multithreaded. That's fine in some cases, for example for apps that have lots of interaction with the user. It's not fine if your app is computationally intensive. If your competitor develops an app that uses all available processors, their app will have blazing speed compared to yours. Not cool...

So, my proposed session will talk about this history, then get into the problems of multithreaded programming, from a generic, language-neutral viewpoint (remember, I was developing multithreaded apps in C and Fortran on SunOS systems in 1993). Problems like memory overwrites, deadlocks, threads that never complete... the world goes crazy once you get into parallel programming. So, what is "threadsafe" code anyway?

Next, my plan is to talk about the history of parallel processing in the JVM through today. Java has had threads for a very long time. It doesn't seem to me that many developers have actually used them. What was the need? For high-end data center processing, Java EE met the need. In the old single core processor world, what's the difference between a multiprocessor computer (like the 8-processor Sun machines I worked on in the mid 1990s) and a server farm?

But here's the problem: today, many people can pick up and hold in their hand what in the past was a mini data center, a mini server farm -- because, in their hand they can hold 2 or 4 or even 8 processor cores. Now, we're not going to use Java EE to make that fancy, powerful phone or tablet fully utilize all of its processing cores, are we? Well.. my friend Adam Bien might argue "why not?" since Java EE 6 provides such lightweight components.

He's right, Java EE could do the trick. But, the software that we want to utilize all the cores wasn't originally developed using Java EE. A great many of us are not inventing new apps; rather, we're trying to port existing apps into this new multicore world. Surely, we can't take the time to rewrite all that code such that it will efficiently run in a hand-held data center, can we? Does any company have a budget for that? Hence, the need for a path to convert desktop apps designed for operation on single-core processors into apps that can efficiently utilize the multicore processors that reside inside modern desktop computers, tablets, and mobile phones.

So, what about Java threads? I recently did some basic experimentation and found that, in a purely mathematical computational scenario, basic Java threads do a pretty good job of fully utilizing my CentOS Linux quad-core processor. But, basic Java threads don't work well in all scenarios. Hence, the decision to introduce the Fork/Join Framework in Java 7.

Converting existing apps developed for the single-core world is still an enormous amount of work, whether you convert the apps to use Java threads, the Fork/Join Framework, or even Java EE 6. This is what's behind the incredibly ambitious Project Lambda, which will introduce closures in Java 8. The parallelization will be implemented in the underlying Java libraries themselves, removing the need for desktop developers to deal with the damnable headaches associated with parallel programming (those memory overwrites, deadlocks, infinitely wandering threads, etc., that I mentioned above). The desktop app developer will simply have to invoke the underlying parallelism where doing so will increase performance. The complexities of thread management, etc., will all take place "under the hood."

If you can't wait for Java 8, and you're developing a new desktop app (whether your "desktop" is a PC, tablet, or fancy phone), there are multiple non-Java parallel programming options for the JVM that are available right now, in languages like Clojure and Scala.

I'll talk about all of this at JavaOne 2012, if my proposed session is accepted.

So, what do you think? Is this a session you might want to attend if you were at JavaOne 2012? Any suggestions on additional items I should include in my proposal? I have until Monday night to finalize it... Weblogs

Since my last blog post, Rex Young posted two new blogs:


Our current poll asks How often do you attend Java conferences?. Voting will be open until Friday, April 20.

Java News

Here are the stories we've recently featured in our Java news section:


Our latest Spotlight is Jonathan Giles's Interview with Jim Weaver and Stephen Chin:

Hi all. I

Filter Blog

By date: