[concurrency-interest] Backport in Retroweaver

Dawid Kurzyniec dawidk at mathcs.emory.edu
Wed May 18 13:49:58 EDT 2005


David Walend wrote:

>
> On May 17, 2005, at 9:42 AM, Doug Lea wrote:
>
>> David Walend wrote:
>>
>>> Any advice on testing? Is there a body of tests for JSR-166 that  I  
>>> can just grab, retroweave and run?
>>>
>>
>> Warning: At the moment, most of our CVS is in a state
>> preparing for Mustang integration, so you will need to
>> make a lot of minor ad-hoc adjustments to suppress or
>> avoid 1.6-specific classes and functionality.
>>
>
You also need to keep in mind that the backport is actually somewhere in 
the middle between Java 5.0 and Mustang. I incorporated fixes and tests 
to bugs found before Feb 7, and I've put in new features which are not 
available in Java 5.0. The "since" tags indicate whether a given piece 
of functionality is in 5.0. (Except for some TimeUnits, which I need to 
fix).

> How about the backport? Would it be a fair test to turn the eembjuc  
> imports into juc imports, then retroweave them?

You could, but I would be careful, since the API mapping is not 100% 
one-one:
1) eembjuc tests have all generics stuff removed,
2) System.nanoTime() is moved to helpers.Utils,
3) Thread.UncaughtExceptionHandler is emulated by helpers.ThreadHelpers

>
> What's the best way to incorporate the tests in the retroweaver code?  
> If I just copy them into retroweaver's code base, it'd be a fork.
>
I took the sources from Doug and made the necessary changes; I bring it 
up-to-date by applying CVS diffs from JSR 166 repository. So far, 
maintaining it was not terribly problematic.

Hope this helps,
Dawid


BTW. I think I will implement the "forward-backport" that was asked for 
some time ago, i.e. port to 5.0 that maintains binary and source 
compatibility with applications written against eembjuc, but attaining 
native speeds on 5.0. It seems simple enough, and useful enough. One of 
the main motivations is the observation that sometimes you may not have 
access to the source code, so you can't change package names and 
recompile, but you'd still like to take advantage of native j.u.c. support.




More information about the Concurrency-interest mailing list