[concurrency-interest] ReentrantReadWriteLock backport non-matching signature

Holger Hoffstätte holger at wizards.de
Mon Jul 10 11:39:05 EDT 2006


David Holmes wrote:
> Holger Hoffstatte writes:
>> Maybe I'm missing something but why does the u.c ReentrantReadWriteLock
>> return the static inner class instead of the Read/WriteLock interfaces in
>> the first place?
> 
> I thought it was because the implementation classes had additional
> house-keeping methods that are not part of the Lock interface. But that
> isn't actually the case. The idea being that you could just type those
> classes directly without having to do a cast.

Maybe it was just an oversight. Still, the whole point of having
interfaces is to decouple from the concrete class. I remember when I tried
to make the backport run (at least partly) on native j.u.c. this was one
of the primary showstoppers, at least for me.

>> The incompatibility is a serious problem for everybody using
>> retrotranslator or -weaver, and will likely just force people to continue
>> using the backport.
> 
> I'm not familiar with those tools - what do they do? And why does this cause
> them a problem? Do they try to match j.u.c signatures to those found in the
> backport?

(see e.g. http://retrotranslator.sourceforge.net/)

Both wrangle 1.5-compiled classes back to 1.4 via bytecode rewriting,
either statically or at load time. In the case of the concurrent classes
that's pretty simple since just the package names have to be changed;
everything else is done by a small extension jar that contains the
appropriate new classes and methods, including annotations, the valueOf
wrapper caches etc. This is a highly efficient way to use quite a few good
parts of 1.5 and still deliver 1.4-compatible products to clients.

Regarding the incompatibility it seems Moran has found a good solution by
just referring to the interface in client code. (phew!)

cheers
Holger


More information about the Concurrency-interest mailing list