[concurrency-interest] Java 6 support in backport-concurrent

Dawid Kurzyniec dawid.kurzyniec at gmail.com
Thu Aug 16 20:05:28 EDT 2007


I apologize everyone for being slow on handling this so far. Now, seeing the
demand being that high (which is great!), I pledge to improve.

Anyway, the 6.0 version has actually been ready for quite a while now, it is
just that I've never found enough time to properly publish it. So, before it
appears on the Web page, you can download the sources directly from the
frozen branch in SVN at:

http://dcl.mathcs.emory.edu/cgi-bin/viewvc.cgi/software/harness2/tags/backport-util-concurrent/3.1/util/backport-util-concurrent-Java60/

Select 'download tarball', then run ant, and you've got yourself a
6.0-compliant backport ready, and with a few minor fixes as well since the
previous version (see the changelog at
http://dcl.mathcs.emory.edu/cgi-bin/viewvc.cgi/software/harness2/tags/backport-util-concurrent/3.1/util/backport-util-concurrent-Java60/README.html
).

I have run stress tests on it, but as usual, run them on your target
machines as well to verify that there are no surprises.

And yes, the reason why the 5.0 version does not work on 6.0 is that atomics
in 5.0 backport inherit from j.u.c., and add lazySet methods, introduced as
final in 6.0. This is one of these rare corner cases when a new Java release
breaks backward binary compatibility. I had to add lazySets so that 1.4 and
5.0 backports remained fully compatible from the client code perspective. I
actually knew that the 6.0 incompatibility is going to happen, but the
alternative would be to use delegation instead of inheritance in atomics,
which would double the object count, impacting performance. I came to the
conclusion that if compatibility and convenience of using a single JAR
everywhere is more important to somebody than performance, they can just use
the 1.4 backport version on all Java platform versions.

The good news is that the backport transition from 6.0 to 7.0 is likely to
go without hoops like that - it should 'just work'.


So, to summarize:

The 1.4 version can be used on 1.4, 5.0, 6.0, and future versions. Unless
the concurrency code is a performance bottleneck, it may be best to just
stick to this version to avoid deployment issues.
The 5.0 version can be used on 5.0 only; it enjoys full performance of j.u.c
.
The 6.0 version can be used on 6.0 and hopefully future versions; it enjoys
full performance of j.u.c.
The 1.3 version can be used on 1.2, 1.3, 1.4, 5.0, 6.0, and future versions,
but I would recommend against using it unless you need to, because I won't
be supporting it much longer.

Regards,
Dawid


On 8/16/07, Greg Luck <gluck at gregluck.com> wrote:
>
> Dawid
> You probably saw the thread on the backport-concurrent list.
>
> It seems that the 1.4 version of backport-concurrent is needed for use
> with 1.6.
>
> It would be a lot better for me people like me using your library in their
> projects if the end users could have a less confusing
> installation. I am getting bugs logged against ehcache.
>
>
>
> Begin forwarded message:
>
> There's no reason to ditch the backport - Java6 users can just use the
>
> 1.4-flavored backport version! It's what I've been using and it works fine
>
> on all JDKs. The performance impact is a lot less than expected; overall
>
> performance improvements in the Java6 VM outweigh the concurrency bits by
>
> a large factor. Add any kind of I/O to the mix and it becomes even less of
>
> a problem.
>
> If you want to move ehcache to Java5 in order to take advantage of
>
> generics and new methods, you can continue to support JDK 1.4 deployment
>
> by using retrotranslator (on SourceForge).
>
>
> Regards
>
>
> Greg Luck
>
> web: http://gregluck.com
> skype: gregrluckyahoo: gregrluck
> mobile: +61 408 061 622
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070817/5e7c571d/attachment.html 


More information about the Concurrency-interest mailing list