Re: backport-concurrent vs. concurrent-1.3.4

Holger Hoffstaette wrote:

> Hi -
>
> I've been using util.concurrent-1.3.4 for some time and recently
> discovered the backport-effort. Just as in JDK 5.0 some rather handy
> classes are missing compared to concurrent-1.3.4 and I was wondering if
> there are any recommendations for or against either one? I very much like
> the stress-testing and the backport's obvious ease of forward-migration to
> 5.0 (if that becomes a requirement one day) but so far had nothing but the
> best experiences with Doug Lea's classes. Also, quite a few OpenSource
> packages have adopted concurrent-1.3.4 and just mixing things - while
> technically possible - is IMHO not desirable. Any wise words for or
> against  either one? The backport docs unfortunately do not talk about
> this (or did I miss it?)
>
>  
Hi Holger,

Well, you must decide what is best for your project, but here is a 
couple of pros and cons, the way I see it:

Against:

* well, stating the obvious: any code reengineering = costs of 
development, testing, and a risk of introducing new bugs into the 
software. If you have a perfectly stable software that is used in 
production environments, migration can only be justified if it offers 
benefits that outweight the costs.

* if your software depends on external libraries using dl.u.c., as you 
pointed out, mixing can be painful. (BTW, interesting project idea would 
be to develop adapter classes allowing to expose java.util.concurrent 
(and backport) classes to dl.u.c.-dependent code).

* as you pointed out, java.util.concurrent, as well as the backport, 
misses a few useful classes found in dl.u.c. If you cannot live without 
them, it may be better to wait until the functionality is supported.

* some people say that since you have to pay the migration costs anyway, 
it is better to do it all in one shot when switching to Java 5.0.

* dl.u.c. will probably work as well on future Java platforms as it 
works on current ones.

OK, now pros. First, why switching to java.util.concurrent in the long run:

* Again, stating the obvious: in the perspective of a few years, 
domination of java.util.concurrent above any other Java concurrency API 
seems inevitable. (example: see how java.util collections dominated 
preceding collection libraries).

* Even though dl.u.c. works on Java 5.0, locks in java.util.concurrent 
are  much faster due to the JVM support. In a recent mailing, Matthias 
Ernst quotes Brian Goetz reporting that java.u.c.ReentrantLock may 
outperform JVM monitors ("synchronized"). In comparison, the dl.u.c. 
(and also the backport) version measures a few times slower. Obviously, 
this means a strong motivation to migrate for applications that are 
sensitive to this.

* True, dl.u.c. still has some functionality that is not supported in 
java.u.c. But these gaps are gradually filled out. On the other hand, 
java.u.c. (and the backport) has a lot of new and useful stuff that is 
not in dl.u.c. And since dl.u.c. is no longer actively developed, the 
time will work in favor of java.u.c.

* Even though the APIs are a bit different, the principles are similar, 
making the migration relatively painless in most cases, at least from my 
experience. And as long as you don't use something dl.u.c.-exclusive.

OK, now motivating the backport:

* In many cases you cannot control the JVM at the user's side. 
Therefore, you often need to target multiple Java versions. Backport 
seems to be the easiest way to simultaneously support Java 5.0 and 1.4 
while 1) exploiting the performance advantages on 5.0 and 2) keeping the 
differences between versions as small as possible (maybe even 
automatically-generated).

* backport gives you a standard API for a nanosecond-precision timer. On 
1.4.2, out-of-the-box, its resolution will be between a few hundred ns 
and 1 us. On earlier platforms, it will gracefully degrade to 
System.currentTimeMillis. And it allows you to plug in your own native 
timer implementation.

* Switching early (before ultimately committing to Java 5.0) means that 
you are no longer developing new code that will later require migration.

* If you've come to trust Doug Lea's code, you will like the backport 
since it is mostly Doug Lea's code in one way or the other. Locks come 
directly from dl.u.c. 1.3.4, and most other things from 
java.util.concurrent. The last available version, 1.1_01, is having so 
far about 13 downloads per day on average since the release, and no bug 
reports so far (I keep fingers crossed).


Hope that helps, but of course I am biased -
Dawid Kurzyniec