commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] New synchronization primitive
Date Sun, 06 Sep 2009 23:26:11 GMT
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-threaded programming
>>> in Java, nevertheless there is certainly still room for improvements.
>>> The proposed concurrent utilities for lang are not intended to reinvent
>>> the wheel, but to implement additional and convenience functionality on
>>> top of the existing API.
>> +1
>>> @Ted: The proposed class is not high-sophisticated, but given the
>>> additional timing aspect it is not trivial either. Of course, it can be
>>> implemented using standard Java means (that's what I did), but having
>>> something that works out of the box is surely preferable than having to
>>> create your own implementation. This is the purpose of a library, isn't
>>> it?
>> Agree on characterization of [lang].  I wonder though whether what
>> you have in mind might quickly grow to be too large for [lang].  How
>> about starting in the sandbox (once you have the grant) so we have
>> something concrete to talk about?  Looks useful and interesting to me.
>> Phil
> The sandbox would be an option, but I don't know whether these suggestions
> really become too large for [lang].
> When we talked about a new version of [lang] that would be compatible with
> JDK 1.5 I made the proposal for some utilities related to multi-threading.
> Since then I have added some JIRA tickets for this topic, namely LANG-496,
> LANG-499, and LANG-501. IMHO this is comparable in amount and intension to
> the text package already existing in [lang].
> Maybe an active [lang] committer can comment on this?

Far as I'm concerned you're the active lang committer for concurrency :)

I think adding it as a package is fine and that you should continue to
grow the package. You've my +1 to go ahead and start committing to a
subpackage (concurrent seems the right name).

Can you open a JIRA issue for adding the package, and link various
tickets to it? Then we can argue about whether it's a separate commons
component or a subpackage before releasing 3.0 and after it's had the
time to justify its existence.

Basically please go for it, and try to keep its changes decoupled from
the other packages pending happiness that it fits.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message