Henri Yandell schrieb:
On Sun, Sep 6, 2009 at 1:40 PM, Oliver
Heger wrote:
Phil Steitz schrieb:
Oliver Heger wrote:
AIUI the mission of commons-lang is to provide extensions and
improvements for existing Java API classes. The concurrent package in
Java 5 is a great step forward in supporting m
On Sun, Sep 6, 2009 at 1:40 PM, Oliver
Heger wrote:
> Phil Steitz schrieb:
>>
>> Oliver Heger wrote:
>>>
>>> AIUI the mission of commons-lang is to provide extensions and
>>> improvements for existing Java API classes. The concurrent package in
>>> Java 5 is a great step forward in supporting multi
Phil Steitz schrieb:
Oliver Heger wrote:
AIUI the mission of commons-lang is to provide extensions and
improvements for existing Java API classes. The concurrent package in
Java 5 is a great step forward in supporting multi-threaded programming
in Java, nevertheless there is certainly still room
Hi Phil...
Do you suggest to start a commons-concurrent as a commons sandbox project ?
On Sun, Sep 6, 2009 at 10:03 PM, Phil Steitz wrote:
> Oliver Heger wrote:
>> AIUI the mission of commons-lang is to provide extensions and
>> improvements for existing Java API classes. The concurrent packag
Oliver Heger wrote:
> AIUI the mission of commons-lang is to provide extensions and
> improvements for existing Java API classes. The concurrent package in
> Java 5 is a great step forward in supporting multi-threaded programming
> in Java, nevertheless there is certainly still room for improvement
I agree with regarding the point that we should extend and enhance
what we already have, either in standard Java API(s) or what is
already provided in other frameworks. For the class that you proposed,
we can consider it like a utility class that is going to be provided
instead of re-writing it.
O
AIUI the mission of commons-lang is to provide extensions and
improvements for existing Java API classes. The concurrent package in
Java 5 is a great step forward in supporting multi-threaded programming
in Java, nevertheless there is certainly still room for improvements.
The proposed concurre
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
10 matches
Mail list logo
