It’s been a long time coming, Java SE 7. After years of development, one major company acquisition and at least a hundred thousand discussions over the future of Java, yesterday Oracle and the OpenJDK community finally released the updates they’ve been working on all this time. There are a lot of changes in this version, not the least of which is the switch in naming conventions: The OpenJDK is the basis of Java SE 7, and its the project where all work has been done on the language, rather than within the JCP.

So, let’s all grab ourselves a nice symbolic cup of coffee to tide us over while we examine the biggest changes in Java SE 7.

Concurrency and collections updates (JSR 166y)

Core proliferation has been an issue for a while now. With every new PC and server including more cores than the last, developers are constantly receiving more horsepower for their applications. Unfortunately, as enterprises have learned over the last 10 years, developing parallel and concurrent software is not as easy as adding all those new cores to a server farm.

Doug Lea, the Java genius from SUNY Oswego, headed up the design of JSR 166y, also known as the Concurrency and collections update. He designed the Fork/Join functionality that’s used in this update.

Perhaps the best way to describe the new functions is to take a clip from the project’s wiki:

Parallel*Array (often referred to as PA) and its planned follow-ons for sets and maps, provide an easier/better way of routinely programming to take advantage of dozens to hundreds of processors/cores: If you can think about a programming problem in terms of aggregate operations on collections of elements, then we can automate parallel execution. This generally pays off if either you have lots of elements (in which case, it works well even if the operations are small/cheap), or if each of the operations are time-consuming (in which case it works well even if there are not a lot of elements). To take advantage of this, though, the aggregate processing must have a regular structure, which means that you must be able to express things in terms of apply, reduce, filter, map, cumulate, sort, uniquify, paired mappings, and so on.

So that’s what Parallel*Array does. Some people (especially those with experience with either database programming or functional programming) like this style anyway, and might use this API even without the parallelism benefits. But in turn, the fact that this style can be awkward to write out has led to all the language extension controversies about closures, function types, and related syntactic support.

Like all lightweight-task frameworks, Fork/Join (FJ) does not explicitly cope with blocked IO: If a worker thread blocks on IO, then (1) it is not available to help process other tasks, and (2) other worker threads waiting for the task to complete (i.e., to join it) may run out of work and waste CPU cycles. Neither of these issues completely eliminates potential use, but they do require a lot of explicit care.

About Alex Handy

Alex Handy is the Senior Editor of Software Development Times.