[concurrency-interest] jsr166y classes now in jdk7m5

Doug Lea dl at cs.oswego.edu
Sun Nov 15 09:10:38 EST 2009


ForkJoin, Phasers, and TransferQueues are now incorporated
in package java.util.concurrent in the latest JDK7 snapshots,
downloadable at http://download.java.net/jdk7/m5/

Please try these out and let us know of any problems.

We will still maintain JDK6-compatible versions
for the indefinite future in package jsr166y (see
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html)
This should also make it easier for those using these
classes from other languages and frameworks. You can
rely on jsr166y versions until JDK7 release, although at
that point you'll probably need to make a visible
switch-over to j.u.c versions. Further, it is likely
that at some point we will make changes that
rely on other JDK7 features.

Especially during this transition, please be careful
with "import" statements in sources --
avoiding "*" imports from either jsr166y or
java.util.concurrent, to avoid compile-time
or run-time errors about name clashes by users
running JDK7 snapshots.

In general, changes show up in our jsr166y
and j.u.c CVS before they appear in openjdk or
Sun JDK7 snapshot releases.
There already a few small improvements there vs
jdk7m5 versions. We plan to occasionally commit
small batches of them into openjdk.

We don't have plans for JDK5 backports. There
are a couple of performance-critical constructions
in these classes that rely on JDK6 intrinsics.
They are costly to emulate in JDK5, so it is
not clear how useful they would be.
This also impacts current IBM Java (J9) users even in
JDK6, because it doesn't support some of the
hotspot intrinsics. I understand that this will
be addressed in an IBM JDK6 update.
More generally, we are hoping to find a way to
ensure compatibility in the future across JVMs for
these JDK-internal non-public APIs (that have
escaped standardization), to avoid future problems
along these lines.

The main known remaining jsr166-related task for JDK7 is
to try to make good on schemes that avoid the need
for the controversial Fences API by improving
AtomicXUpdater APIs and somehow removing their overhead.

-Doug





More information about the Concurrency-interest mailing list