Weeding out backport-util-concurrent

[Jason Dillon <ja...@planet57.com>]

Now that server/trunk requires 1.5 to build and run, I think we  
should start to weed out our usage of the backport-util-concurrent  
package (and concurrent if there is still anything left of that in  
our src tree).

I think we may still have to include backport-util-concurrent-*.jar  
in the assembly until all of our dependencies have weeded it out  
too... or perhaps just have to live with that in the repository.  But  
hopefully we can remove our usage of these classes and not need to  
include this puppy in lib/* anymore.

Looks like we are currently using edu.emory.mathcs.backport in 39  
locations (based on imports) which are over 25 files.

  * * *

Anyone know of any reason why we shouldn't change all of these to use  
the java.util.concurrent.* classes?

Even after weeding out *our* usage, if we still need to include this  
jar I recommend we update to the latest release 3.0.

--jason

Re: Weeding out backport-util-concurrent

[Dain Sundstrom <da...@iq80.com>]

On Mar 19, 2007, at 2:44 PM, Jason Dillon wrote:

> Now that server/trunk requires 1.5 to build and run, I think we  
> should start to weed out our usage of the backport-util-concurrent  
> package (and concurrent if there is still anything left of that in  
> our src tree).
>
> I think we may still have to include backport-util-concurrent-*.jar  
> in the assembly until all of our dependencies have weeded it out  
> too... or perhaps just have to live with that in the repository.   
> But hopefully we can remove our usage of these classes and not need  
> to include this puppy in lib/* anymore.
>
> Looks like we are currently using edu.emory.mathcs.backport in 39  
> locations (based on imports) which are over 25 files.
>
>  * * *
>
> Anyone know of any reason why we shouldn't change all of these to  
> use the java.util.concurrent.* classes?

Let's do it.

-dain