RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Forking and Joining Java to Maximize Multicore Power : Page 5

With JSR-166y, Java 7 will get a new way of structuring concurrent programming known as the fork/join framework. Find out how (and when) to use it.


Following Up: More to Learn

A cursory glance at the JSR-166y Javadocs page will reveal that it contains a lot more APIs and classes, but you have gotten the main highlights of the library. Don't be too intimidated by the large number of Ops.* classes; most of those go away with the generic versions (Ops.Predicate, Ops.Procedure, Ops.Reducer, and so on), and as a result, the rest aren't really worth studying until you need them.

You will also notice that the fork/join framework looks a bit different from the traditional Java API. The fork/join framework, like many of the current concurrency proposals, takes a more functional approach to its design, in the spirit of such functional languages as Haskell, OCaml, Lisp, F#, or Scala. That will require you to adjust your thinking a bit in order to use it effectively. Because Java doesn't consider functions/methods to be first-class objects the way those other languages do, you have to adapt slightly by creating functors (function objects). Functors are the anonymous inner-class instances that you pass into the API. This isn't an indication that Java is going to embrace functional programming, but it is another design style that can yield some interesting and powerful benefits to those who take the time to learn it.

In the meantime, the fork/join framework is still under active development and its APIs are still subject to change all the way up until the JSR is finalized and the Java 7 implementation ships. Chances are, however, that the APIs you see here are, for the most part, the way they will remain. Certainly, the concepts—passing in function objects and the fluent API design—are pretty firmly nailed down.

So don't be afraid to explore the fork/join framework, because nothing—not bugs or even concurrent bugs—is worse than letting CPU power go idle while you unwrap loops and hand-check thread-safe code.

Ted Neward is a Principal Consultant with ThoughtWorks, a global consulting firm focusing on .NET, Java and Ruby enterprise development. He is an internationally recognized speaker, instructor, consultant, and mentor and spends a great deal of time these days focusing on languages and execution engines such as the JVM and CLR.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date