In particular, why can this not be implemented using the Java 5 primitives?
For instance, a thread could be created that adds tokens at a fixed rate to
a blocking queue up to a small maximum. Threads wishing to consume the load
bounded resource would request a token before sending a query. This
Sorry for the question, but why we need a new *concurrent* utils in
commons-lang while we have the concurrent package in Java SE 5 ?
On Sat, Sep 5, 2009 at 9:48 PM, Oliver
Heger wrote:
> In my day job I have written a synchronization primitive that may be of
> interest for the proposed concurrent
In my day job I have written a synchronization primitive that may be of
interest for the proposed concurrent package of the new version of
commons-lang. I first want to check whether there is interest in this
stuff, then I can talk to my employer about the code donation (which
hopefully should
Phil Steitz a écrit :
> sebb wrote:
>> There are quite a lot of assertions that don't give any details if a test
>> fails.
>>
>> For example, the following currently fails when using Harmony:
>>
>> testIncreasingTolerance(org.apache.commons.math.ode.nonstiff.AdamsBashforthIntegratorTest)
>> java.l
On Wed, Sep 2, 2009 at 2:57 PM, Rahul Akolkar wrote:
> Since the primary focus for the past few months has been the 2.0 / 2.x
> branch, I suggest we change it to trunk and move the trunk to the 1.x
> branch.
>
> OK? I'm planning on doing this in ~48 hours or sooner if enough folks agree.
>
Done (
On Fri, Sep 4, 2009 at 3:37 PM, Donald Woods wrote:
> Everyone, I think it is time again to reopen the discussions around creating
> a Validator2 release [1], which implements the upcoming JSR-303 Bean
> Validation spec [2] and [3]. Since JSR-303 is now a required component of
> Java EE 6 applica
