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
-
JSR-166: java.util.concurrent back-ported to Java 1.4 (11 messages)
- Posted by: Dion Almaer
- Posted on: September 28 2004 10:25 EDT
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.Threaded Messages (11)
- Well Frak.... by Leif Ashley on September 28 2004 10:37 EDT
- memory model bugs by Kenny MacLeod on September 29 2004 04:58 EDT
- memory model bugs by Nick Minutello on September 30 2004 10:41 EDT
- memory model bugs by Kenny MacLeod on September 29 2004 04:58 EDT
- Public Domain? by Jason Gerard on September 28 2004 10:57 EDT
- Public Domain? by Sumit K on September 28 2004 11:28 EDT
- virally? by John Childress on September 28 2004 11:49 EDT
- Public Domain? by Dalibor Topic on September 28 2004 21:10 EDT
- Public Domain? by Sumit K on September 28 2004 11:28 EDT
- Remark to Point 1): Nanosecond Timer by Michael Mayr on September 28 2004 13:56 EDT
- JSR-166: java.util.concurrent back-ported to Java 1.4 by Nick Minutello on September 28 2004 17:37 EDT
- a couple of answers by Dawid Kurzyniec on December 01 2004 01:05 EST
-
Well Frak....[ Go to top ]
- Posted by: Leif Ashley
- Posted on: September 28 2004 10:37 EDT
- in response to Dion Almaer
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! -
memory model bugs[ Go to top ]
- Posted by: Kenny MacLeod
- Posted on: September 29 2004 04:58 EDT
- in response to Leif Ashley
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? -
memory model bugs[ Go to top ]
- Posted by: Nick Minutello
- Posted on: September 30 2004 22:41 EDT
- in response to Kenny MacLeod
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... -
Public Domain?[ Go to top ]
- Posted by: Jason Gerard
- Posted on: September 28 2004 10:57 EDT
- in response to Dion Almaer
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. -
Public Domain?[ Go to top ]
- Posted by: Sumit K
- Posted on: September 28 2004 11:28 EDT
- in response to Jason Gerard
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? -
virally?[ Go to top ]
- Posted by: John Childress
- Posted on: September 28 2004 11:49 EDT
- in response to Sumit K
-
virally![ Go to top ]
- Posted by: Sumit K
- Posted on: September 28 2004 12:55 EDT
- in response to John Childress
-
Public Domain?[ Go to top ]
- Posted by: Dalibor Topic
- Posted on: September 28 2004 21:10 EDT
- in response to Jason Gerard
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 -
Remark to Point 1): Nanosecond Timer[ Go to top ]
- Posted by: Michael Mayr
- Posted on: September 28 2004 13:56 EDT
- in response to Dion Almaer
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 -
JSR-166: java.util.concurrent back-ported to Java 1.4[ Go to top ]
- Posted by: Nick Minutello
- Posted on: September 28 2004 17:37 EDT
- in response to Dion Almaer
Excellent news. -
a couple of answers[ Go to top ]
- Posted by: Dawid Kurzyniec
- Posted on: December 01 2004 01:05 EST
- in response to Dion Almaer
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