The new Java 5 package java.util.concurrent has been back-ported to JDK 1.4. This allows people to use the new APIs in older VMs with just a change to the package name that you use. Since some of the features depend on the VM itself, there are a few differences, which are spelled out.

I am happy to announce availability of a back-port of java.util.concurrent API to Java 1.4. The back-port is based on sources from JSR 166 CVS repository (September 2004), and dl.util.concurrent 1.3.4. The back-port is nearly complete; unsupported functionality is limited mostly to the following classes: 1) requiring explicit JVM support (e.g. nanosecond clock), 2) some non-essential functions described as "designed primarily for use in monitoring in system state, not for synchronization control", 3) functionality that would affect performance, or 4) functionality that would require development of substantial amount of new code.

Announcing back-port of JSR166 to Java 1.4

I wrote all the stuff I needed. This would have help had I known / been able to use it earlier... not that we needed concurrency support in 1.4 or anything <
Very cool indeed!

I was under the impression that Tiger fixed certain long-standing bugs/design flaws in the Java memory model, and that these fixes were a necessary part of the java.util.concurrent stuff. Was I mistaken in this, or have they found a way around it for the 1.4 version?

Only some util.concurrent features required the jvm change...
For instance all of the asynch support - thread-pools etc.
The stuff closer to the metal (atomic-get-set) require JVM change...

From the post:
"Whenever possible, the JSR 166 code was used."
<br>
"The library is released to public domain and can be used
without acknowledgement and for any purpose."
<br>
<br>
Wow, some actual JDK code being released in the public domain. I wonder if this is legal. If so, it should help out the GNU Classpath project in catching up.

Wasn't the code for java.util.concurrent in turn taken from public domain code (Doug Lea's util), which presumably had a virally public license?

http://dictionary.reference.com/search?q=virally%20

http://encyclopedia.thefreedictionary.com/Viral%20license

From the post: "Whenever possible, the JSR 166 code was used."<br>"The library is released to public domain and can be used without acknowledgement and for any purpose."<br><br>Wow, some actual JDK code being released in the public domain. I wonder if this is legal. If so, it should help out the GNU Classpath project in catching up.

In theory yes, in practice it remains to be seen which licenses cover what parts. I'd doubt that JDK code can be released into the public domain except by explicit grant from copyright holders. :)

cheers,
dalibor topic

That's interesting. Some time ago I had a nice conversation on the concurrency-interest mailing list with David Holmes on exactly that topic. Let me quote David Holmes "System.nanoTime is not required to have nanosecond accuracy only nanosecond precision. An implementation that returned
currentTimeMillis()*1000000 would be a correct though low-quality
implementation. An implementation should document the accuracy of
nanoTime." So there's no need for this hole in the backport to last. Just implement it this cheap way. But maybe the 1.5 version provides a better precision and having two implementations of the same method which have different precisions isn't worth the possible trouble.

Cheers
Michael

Excellent news.

Hi guys, this is the author of the back-port. I am happy to see that it causes interest even before its public release. Anyway, here are couple of answers to questions raised:

* license: the code is based on Doug Lea's JSR 166 code and dl.u.c., which are public domain. The license is not viral, the code may be sublicensed, sold, changed, you can do whatever you want with it (SUN did just that including it in Java 5.0). A couple of files, however, originate from SUN code and bear SUN license; they are all in main "util" package (not "concurrent") and the license is clearly stated at each file header.

* nanosecond timer: this cannot be back-ported directly for the very simple reason that the method is in the java.lang.System class. However, backport has the "utility" class util.helpers.Utils, with the method "nanoTime()" doing exactly what you would guess. Under Java 1.4.2, it is of relatively high precision since it uses sun.misc.Perf internally. Under older Javas, it fails back to System.currentTimeMillis().

* completeness: the stuff in JSR 166 that requires JVM support is not implemented in the backport for that very reason; however, most of the JSR 166 functionality does not require JVM support and is backported. Some things are emulated: e.g. atomics are implemented similarly to synchronized variables in dl.u.c.

* availability: the official distribution of the backport is practically ready, I am now working on the Web page. New version includes a few minor bug fixes. It will be available by the end of this week at http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/.

Regards,
Dawid Kurzyniec