[VOTE] Release Commons Lang 3.0 (RC1)

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release Commons Lang 3.0 (RC1)

Henri Yandell
Looking to release 3.0; there's not been a lot of JIRA activity and
it's 9 months or so since we released the beta.

Downloads:

  http://people.apache.org/~bayard/commons-lang3-RC1/

Maven repo entry:

  http://people.apache.org/~bayard/commons-lang3-RC1/maven/

Website:

  http://people.apache.org/~bayard/commons-lang3-RC1/site/

Tag:

  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1

[ ] +1
[ ] -1, because:


Thanks,

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

jodastephen
I'm not overly enthused about some of the changes, but since I've not
been paying attention its difficult for me to vote/block. Anyway here
is my review:

ArrayUtils.hashCode() has been removed, but it had different
functionality to Arrays.hashCode wrt nested arrays.

        Object[] arrayA = new Object[] {new boolean[] {true, false},
new int[] {6, 7}};
        Object[] arrayB = new Object[] {new boolean[] {true, false},
new int[] {6, 7}};
        assertEquals(true, Arrays.hashCode(arrayB) == Arrays.hashCode(arrayA));

I don't love the new Pair class. We have an interface based version
here at OpenGamma to allow primitive implementations for performance.
I might be able to get our code released if there was interest.

ArrayUtils.toArray() javadoc has example code that won't compile
(missing "new") and also misses < > in places.

Some new methods use a different brace position from the existing
code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
Validate.exclusiveBetween()...

Some new code isn't explicit about null handling, such as
AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...

Some new methods don't have an @since, such as Validate.notBlank(),
Validate.exclusiveBetween()...

StringUtils is now an odd mixture of methods that accept a
CharSequence and ones that don't. Looking at it, I'd prefer to see
CharSequenceUtils added to, and StringUtils methods just deal with
Strings (A CharSequence might be mutable, so it has a different set of
implications when writing code using it). But if that isn't OK, then
it would be better to see everything in StringUtils take a
CharSequence.

ToStringStyle doesn't have a serialization version ID.

While we've moved away from NullArgumentException, I suspect it may be
reasonably widely used.

DateUtils has added a new MODIFY int enum, rather than using a real
enum. Nor has the existing RANGE int enum been converted

The JavaVersion name field is not used.

ObjectUtils.firstNonNull() differs from Google Guava in that it can
return null. This is probably OK, but should be checked.

Range is only thread safe if the objects held inside are thread safe (javadoc).

Range.containsRange() might be better named containsAll()
Range.overlapsRange might be better named overlaps()

Public constants on StringEscapeUtils do not have javadoc.

The StringUtils.concat methods duplicate the existing join methods.

There are a number of TODOs in the code that might need addressing.

The migration guide exceptions section is missing a header.


Hope some of this helps (!)
Stephen


On 3 March 2011 07:39, Henri Yandell <[hidden email]> wrote:

> Looking to release 3.0; there's not been a lot of JIRA activity and
> it's 9 months or so since we released the beta.
>
> Downloads:
>
>  http://people.apache.org/~bayard/commons-lang3-RC1/
>
> Maven repo entry:
>
>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>
> Website:
>
>  http://people.apache.org/~bayard/commons-lang3-RC1/site/
>
> Tag:
>
>  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
>
> [ ] +1
> [ ] -1, because:
>
>
> Thanks,
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

sebb-2-2
In reply to this post by Henri Yandell
On 3 March 2011 07:39, Henri Yandell <[hidden email]> wrote:

> Looking to release 3.0; there's not been a lot of JIRA activity and
> it's 9 months or so since we released the beta.
>
> Downloads:
>
>  http://people.apache.org/~bayard/commons-lang3-RC1/
>
> Maven repo entry:
>
>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/

Are you not using Nexus?

If you use mvn deploy, the artifacts (Maven and otherwise) will all
end up in the staging repo which I think you'll probably need to use
anyway to for the Maven bits.

> Website:
>
>  http://people.apache.org/~bayard/commons-lang3-RC1/site/
>
> Tag:
>
>  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
>
> [ ] +1
> [ ] -1, because:
>
>
> Thanks,
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

garydgregory
In reply to this post by jodastephen
Good feedback, thank you for taking the time to dig in. (I do not have to
time to patch ATM...)

Gary

On Thu, Mar 3, 2011 at 6:59 AM, Stephen Colebourne <[hidden email]>wrote:

> I'm not overly enthused about some of the changes, but since I've not
> been paying attention its difficult for me to vote/block. Anyway here
> is my review:
>
> ArrayUtils.hashCode() has been removed, but it had different
> functionality to Arrays.hashCode wrt nested arrays.
>
>        Object[] arrayA = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        Object[] arrayB = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        assertEquals(true, Arrays.hashCode(arrayB) ==
> Arrays.hashCode(arrayA));
>
> I don't love the new Pair class. We have an interface based version
> here at OpenGamma to allow primitive implementations for performance.
> I might be able to get our code released if there was interest.
>
> ArrayUtils.toArray() javadoc has example code that won't compile
> (missing "new") and also misses &lt; &gt; in places.
>
> Some new methods use a different brace position from the existing
> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
> Validate.exclusiveBetween()...
>
> Some new code isn't explicit about null handling, such as
> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...
>
> Some new methods don't have an @since, such as Validate.notBlank(),
> Validate.exclusiveBetween()...
>
> StringUtils is now an odd mixture of methods that accept a
> CharSequence and ones that don't. Looking at it, I'd prefer to see
> CharSequenceUtils added to, and StringUtils methods just deal with
> Strings (A CharSequence might be mutable, so it has a different set of
> implications when writing code using it). But if that isn't OK, then
> it would be better to see everything in StringUtils take a
> CharSequence.
>
> ToStringStyle doesn't have a serialization version ID.
>
> While we've moved away from NullArgumentException, I suspect it may be
> reasonably widely used.
>
> DateUtils has added a new MODIFY int enum, rather than using a real
> enum. Nor has the existing RANGE int enum been converted
>
> The JavaVersion name field is not used.
>
> ObjectUtils.firstNonNull() differs from Google Guava in that it can
> return null. This is probably OK, but should be checked.
>
> Range is only thread safe if the objects held inside are thread safe
> (javadoc).
>
> Range.containsRange() might be better named containsAll()
> Range.overlapsRange might be better named overlaps()
>
> Public constants on StringEscapeUtils do not have javadoc.
>
> The StringUtils.concat methods duplicate the existing join methods.
>
> There are a number of TODOs in the code that might need addressing.
>
> The migration guide exceptions section is missing a header.
>
>
> Hope some of this helps (!)
> Stephen
>
>
> On 3 March 2011 07:39, Henri Yandell <[hidden email]> wrote:
> > Looking to release 3.0; there's not been a lot of JIRA activity and
> > it's 9 months or so since we released the beta.
> >
> > Downloads:
> >
> >  http://people.apache.org/~bayard/commons-lang3-RC1/
> >
> > Maven repo entry:
> >
> >  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
> >
> > Website:
> >
> >  http://people.apache.org/~bayard/commons-lang3-RC1/site/
> >
> > Tag:
> >
> >  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
> >
> > [ ] +1
> > [ ] -1, because:
> >
> >
> > Thanks,
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Henri Yandell
In reply to this post by sebb-2-2
On Thu, Mar 3, 2011 at 4:01 AM, sebb <[hidden email]> wrote:

> On 3 March 2011 07:39, Henri Yandell <[hidden email]> wrote:
>> Looking to release 3.0; there's not been a lot of JIRA activity and
>> it's 9 months or so since we released the beta.
>>
>> Downloads:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/
>>
>> Maven repo entry:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>
> Are you not using Nexus?

Nope. Can you explain how to use it for Commons?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Henri Yandell
In reply to this post by jodastephen
*waves hands* Beta release, ages ago, 3.0, started, ages, Blue Meanies!

That said - excellent feedback, I'll try to go through it tonight.

Cancelling vote; but more feedback from anyone would be excellent.

Hen

On Thu, Mar 3, 2011 at 3:59 AM, Stephen Colebourne <[hidden email]> wrote:

> I'm not overly enthused about some of the changes, but since I've not
> been paying attention its difficult for me to vote/block. Anyway here
> is my review:
>
> ArrayUtils.hashCode() has been removed, but it had different
> functionality to Arrays.hashCode wrt nested arrays.
>
>        Object[] arrayA = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        Object[] arrayB = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        assertEquals(true, Arrays.hashCode(arrayB) == Arrays.hashCode(arrayA));
>
> I don't love the new Pair class. We have an interface based version
> here at OpenGamma to allow primitive implementations for performance.
> I might be able to get our code released if there was interest.
>
> ArrayUtils.toArray() javadoc has example code that won't compile
> (missing "new") and also misses &lt; &gt; in places.
>
> Some new methods use a different brace position from the existing
> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
> Validate.exclusiveBetween()...
>
> Some new code isn't explicit about null handling, such as
> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...
>
> Some new methods don't have an @since, such as Validate.notBlank(),
> Validate.exclusiveBetween()...
>
> StringUtils is now an odd mixture of methods that accept a
> CharSequence and ones that don't. Looking at it, I'd prefer to see
> CharSequenceUtils added to, and StringUtils methods just deal with
> Strings (A CharSequence might be mutable, so it has a different set of
> implications when writing code using it). But if that isn't OK, then
> it would be better to see everything in StringUtils take a
> CharSequence.
>
> ToStringStyle doesn't have a serialization version ID.
>
> While we've moved away from NullArgumentException, I suspect it may be
> reasonably widely used.
>
> DateUtils has added a new MODIFY int enum, rather than using a real
> enum. Nor has the existing RANGE int enum been converted
>
> The JavaVersion name field is not used.
>
> ObjectUtils.firstNonNull() differs from Google Guava in that it can
> return null. This is probably OK, but should be checked.
>
> Range is only thread safe if the objects held inside are thread safe (javadoc).
>
> Range.containsRange() might be better named containsAll()
> Range.overlapsRange might be better named overlaps()
>
> Public constants on StringEscapeUtils do not have javadoc.
>
> The StringUtils.concat methods duplicate the existing join methods.
>
> There are a number of TODOs in the code that might need addressing.
>
> The migration guide exceptions section is missing a header.
>
>
> Hope some of this helps (!)
> Stephen
>
>
> On 3 March 2011 07:39, Henri Yandell <[hidden email]> wrote:
>> Looking to release 3.0; there's not been a lot of JIRA activity and
>> it's 9 months or so since we released the beta.
>>
>> Downloads:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/
>>
>> Maven repo entry:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>>
>> Website:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/site/
>>
>> Tag:
>>
>>  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
>>
>> [ ] +1
>> [ ] -1, because:
>>
>>
>> Thanks,
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Simone Tripodi-2
Hi Henri,
I'm not in the position to review ATM, maybe tonight, I'll let you know!!!
Have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, Mar 3, 2011 at 5:04 PM, Henri Yandell <[hidden email]> wrote:

> *waves hands* Beta release, ages ago, 3.0, started, ages, Blue Meanies!
>
> That said - excellent feedback, I'll try to go through it tonight.
>
> Cancelling vote; but more feedback from anyone would be excellent.
>
> Hen
>
> On Thu, Mar 3, 2011 at 3:59 AM, Stephen Colebourne <[hidden email]> wrote:
>> I'm not overly enthused about some of the changes, but since I've not
>> been paying attention its difficult for me to vote/block. Anyway here
>> is my review:
>>
>> ArrayUtils.hashCode() has been removed, but it had different
>> functionality to Arrays.hashCode wrt nested arrays.
>>
>>        Object[] arrayA = new Object[] {new boolean[] {true, false},
>> new int[] {6, 7}};
>>        Object[] arrayB = new Object[] {new boolean[] {true, false},
>> new int[] {6, 7}};
>>        assertEquals(true, Arrays.hashCode(arrayB) == Arrays.hashCode(arrayA));
>>
>> I don't love the new Pair class. We have an interface based version
>> here at OpenGamma to allow primitive implementations for performance.
>> I might be able to get our code released if there was interest.
>>
>> ArrayUtils.toArray() javadoc has example code that won't compile
>> (missing "new") and also misses &lt; &gt; in places.
>>
>> Some new methods use a different brace position from the existing
>> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
>> Validate.exclusiveBetween()...
>>
>> Some new code isn't explicit about null handling, such as
>> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...
>>
>> Some new methods don't have an @since, such as Validate.notBlank(),
>> Validate.exclusiveBetween()...
>>
>> StringUtils is now an odd mixture of methods that accept a
>> CharSequence and ones that don't. Looking at it, I'd prefer to see
>> CharSequenceUtils added to, and StringUtils methods just deal with
>> Strings (A CharSequence might be mutable, so it has a different set of
>> implications when writing code using it). But if that isn't OK, then
>> it would be better to see everything in StringUtils take a
>> CharSequence.
>>
>> ToStringStyle doesn't have a serialization version ID.
>>
>> While we've moved away from NullArgumentException, I suspect it may be
>> reasonably widely used.
>>
>> DateUtils has added a new MODIFY int enum, rather than using a real
>> enum. Nor has the existing RANGE int enum been converted
>>
>> The JavaVersion name field is not used.
>>
>> ObjectUtils.firstNonNull() differs from Google Guava in that it can
>> return null. This is probably OK, but should be checked.
>>
>> Range is only thread safe if the objects held inside are thread safe (javadoc).
>>
>> Range.containsRange() might be better named containsAll()
>> Range.overlapsRange might be better named overlaps()
>>
>> Public constants on StringEscapeUtils do not have javadoc.
>>
>> The StringUtils.concat methods duplicate the existing join methods.
>>
>> There are a number of TODOs in the code that might need addressing.
>>
>> The migration guide exceptions section is missing a header.
>>
>>
>> Hope some of this helps (!)
>> Stephen
>>
>>
>> On 3 March 2011 07:39, Henri Yandell <[hidden email]> wrote:
>>> Looking to release 3.0; there's not been a lot of JIRA activity and
>>> it's 9 months or so since we released the beta.
>>>
>>> Downloads:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-RC1/
>>>
>>> Maven repo entry:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>>>
>>> Website:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-RC1/site/
>>>
>>> Tag:
>>>
>>>  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
>>>
>>> [ ] +1
>>> [ ] -1, because:
>>>
>>>
>>> Thanks,
>>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

jodastephen
In reply to this post by Henri Yandell
I know. Me late. Hope its better late than never...
Stephen

On 3 March 2011 16:04, Henri Yandell <[hidden email]> wrote:

> *waves hands* Beta release, ages ago, 3.0, started, ages, Blue Meanies!
>
> That said - excellent feedback, I'll try to go through it tonight.
>
> Cancelling vote; but more feedback from anyone would be excellent.
>
> Hen
>
> On Thu, Mar 3, 2011 at 3:59 AM, Stephen Colebourne <[hidden email]> wrote:
>> I'm not overly enthused about some of the changes, but since I've not
>> been paying attention its difficult for me to vote/block. Anyway here
>> is my review:
>>
>> ArrayUtils.hashCode() has been removed, but it had different
>> functionality to Arrays.hashCode wrt nested arrays.
>>
>>        Object[] arrayA = new Object[] {new boolean[] {true, false},
>> new int[] {6, 7}};
>>        Object[] arrayB = new Object[] {new boolean[] {true, false},
>> new int[] {6, 7}};
>>        assertEquals(true, Arrays.hashCode(arrayB) == Arrays.hashCode(arrayA));
>>
>> I don't love the new Pair class. We have an interface based version
>> here at OpenGamma to allow primitive implementations for performance.
>> I might be able to get our code released if there was interest.
>>
>> ArrayUtils.toArray() javadoc has example code that won't compile
>> (missing "new") and also misses &lt; &gt; in places.
>>
>> Some new methods use a different brace position from the existing
>> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
>> Validate.exclusiveBetween()...
>>
>> Some new code isn't explicit about null handling, such as
>> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...
>>
>> Some new methods don't have an @since, such as Validate.notBlank(),
>> Validate.exclusiveBetween()...
>>
>> StringUtils is now an odd mixture of methods that accept a
>> CharSequence and ones that don't. Looking at it, I'd prefer to see
>> CharSequenceUtils added to, and StringUtils methods just deal with
>> Strings (A CharSequence might be mutable, so it has a different set of
>> implications when writing code using it). But if that isn't OK, then
>> it would be better to see everything in StringUtils take a
>> CharSequence.
>>
>> ToStringStyle doesn't have a serialization version ID.
>>
>> While we've moved away from NullArgumentException, I suspect it may be
>> reasonably widely used.
>>
>> DateUtils has added a new MODIFY int enum, rather than using a real
>> enum. Nor has the existing RANGE int enum been converted
>>
>> The JavaVersion name field is not used.
>>
>> ObjectUtils.firstNonNull() differs from Google Guava in that it can
>> return null. This is probably OK, but should be checked.
>>
>> Range is only thread safe if the objects held inside are thread safe (javadoc).
>>
>> Range.containsRange() might be better named containsAll()
>> Range.overlapsRange might be better named overlaps()
>>
>> Public constants on StringEscapeUtils do not have javadoc.
>>
>> The StringUtils.concat methods duplicate the existing join methods.
>>
>> There are a number of TODOs in the code that might need addressing.
>>
>> The migration guide exceptions section is missing a header.
>>
>>
>> Hope some of this helps (!)
>> Stephen
>>
>>
>> On 3 March 2011 07:39, Henri Yandell <[hidden email]> wrote:
>>> Looking to release 3.0; there's not been a lot of JIRA activity and
>>> it's 9 months or so since we released the beta.
>>>
>>> Downloads:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-RC1/
>>>
>>> Maven repo entry:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>>>
>>> Website:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-RC1/site/
>>>
>>> Tag:
>>>
>>>  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
>>>
>>> [ ] +1
>>> [ ] -1, because:
>>>
>>>
>>> Thanks,
>>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Jörg Schaible
In reply to this post by jodastephen
Stephen Colebourne wrote:

> I'm not overly enthused about some of the changes, but since I've not
> been paying attention its difficult for me to vote/block. Anyway here
> is my review:

[snip]

> ArrayUtils.toArray() javadoc has example code that won't compile
> (missing "new") and also misses &lt; &gt; in places.

DONE.

>
> Some new methods use a different brace position from the existing
> code, such as ArrayUtils.toArray(),

DONE.

> Validate.matchesPattern(),
> Validate.exclusiveBetween()...

[snip]

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Matt Benson-2
In reply to this post by jodastephen
On Thu, Mar 3, 2011 at 5:59 AM, Stephen Colebourne <[hidden email]> wrote:
> I'm not overly enthused about some of the changes, but since I've not
> been paying attention its difficult for me to vote/block. Anyway here
> is my review:
>
[SNIP]
> I don't love the new Pair class. We have an interface based version
> here at OpenGamma to allow primitive implementations for performance.
> I might be able to get our code released if there was interest.

Providing interfaces without code that consumes them doesn't feel like
[lang]'s mission; this is akin to providing exceptions we don't use
IMHO.  It might be okay for Pair<L, R> to implement Map.Entry<L, R>,
for example.  But when you say primitive implementations, do you mean
implementations based around primitive types, or simplistic
implementations?  If the latter, how much more simplistic could it
get?

Beyond this it would seem many of the points you raise are
documentation-related, which wouldn't seem to preclude a beta release.

Matt

[SNIP]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

jodastephen
On 3 March 2011 18:56, Matt Benson <[hidden email]> wrote:

> [SNIP]
>> I don't love the new Pair class. We have an interface based version
>> here at OpenGamma to allow primitive implementations for performance.
>> I might be able to get our code released if there was interest.
>
> Providing interfaces without code that consumes them doesn't feel like
> [lang]'s mission; this is akin to providing exceptions we don't use
> IMHO.  It might be okay for Pair<L, R> to implement Map.Entry<L, R>,
> for example.  But when you say primitive implementations, do you mean
> implementations based around primitive types, or simplistic
> implementations?  If the latter, how much more simplistic could it
> get?

Our OpenGamma pair is an abstract class (not an interface!):
public abstract class Pair<A, B> implements Map.Entry<A, B>,
Comparable<Pair<A, B>>, Serializable

There are concrete implementations for ObjectsPair, DoublesPair,
IntDoublePair etc. where the user can access the primitive type
directly, or just use the base generified class. The question is
whether [lang] wants no Pair, a simple one, or a full-featured one
(where people may disagree on what full-featured should look like).

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

garydgregory
Hi All,

For my needs, I need something akin to a Smalltalk Association and the
current Pair works but it is not how I would like to see it implemented.

I want an interface and a generics-based implementation (like Pair.)

I find it weird to write "Map.Entry myAssoc = ..." but our Pair should
implement Map.Entry because M.E is a JRE interface just for this kind of
stuff even if the pair is not used in a Map.

How about this pseudo-code:

interface Pair extends Map.Entry (add some of our stuff in there if we need
it.)
class BasicPair<K,V> implements Pair.

Then we can talk about adding primitive Pairs.

Gary

On Thu, Mar 3, 2011 at 2:08 PM, Stephen Colebourne <[hidden email]>wrote:

> On 3 March 2011 18:56, Matt Benson <[hidden email]> wrote:
> > [SNIP]
> >> I don't love the new Pair class. We have an interface based version
> >> here at OpenGamma to allow primitive implementations for performance.
> >> I might be able to get our code released if there was interest.
> >
> > Providing interfaces without code that consumes them doesn't feel like
> > [lang]'s mission; this is akin to providing exceptions we don't use
> > IMHO.  It might be okay for Pair<L, R> to implement Map.Entry<L, R>,
> > for example.  But when you say primitive implementations, do you mean
> > implementations based around primitive types, or simplistic
> > implementations?  If the latter, how much more simplistic could it
> > get?
>
> Our OpenGamma pair is an abstract class (not an interface!):
> public abstract class Pair<A, B> implements Map.Entry<A, B>,
> Comparable<Pair<A, B>>, Serializable
>
> There are concrete implementations for ObjectsPair, DoublesPair,
> IntDoublePair etc. where the user can access the primitive type
> directly, or just use the base generified class. The question is
> whether [lang] wants no Pair, a simple one, or a full-featured one
> (where people may disagree on what full-featured should look like).
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

garydgregory
And I now realize that we could consider mutable vs. immutable Pairs

interface Pair (no setters)
interface MutablePair extends Pair (same as Map.Entry)
class BasicPair<K,V> implements Map.Entry, Pair.

?

Gary

On Thu, Mar 3, 2011 at 2:26 PM, Gary Gregory <[hidden email]> wrote:

> Hi All,
>
> For my needs, I need something akin to a Smalltalk Association and the
> current Pair works but it is not how I would like to see it implemented.
>
> I want an interface and a generics-based implementation (like Pair.)
>
> I find it weird to write "Map.Entry myAssoc = ..." but our Pair should
> implement Map.Entry because M.E is a JRE interface just for this kind of
> stuff even if the pair is not used in a Map.
>
> How about this pseudo-code:
>
> interface Pair extends Map.Entry (add some of our stuff in there if we need
> it.)
> class BasicPair<K,V> implements Pair.
>
> Then we can talk about adding primitive Pairs.
>
> Gary
>
> On Thu, Mar 3, 2011 at 2:08 PM, Stephen Colebourne <[hidden email]>wrote:
>
>> On 3 March 2011 18:56, Matt Benson <[hidden email]> wrote:
>> > [SNIP]
>> >> I don't love the new Pair class. We have an interface based version
>> >> here at OpenGamma to allow primitive implementations for performance.
>> >> I might be able to get our code released if there was interest.
>> >
>> > Providing interfaces without code that consumes them doesn't feel like
>> > [lang]'s mission; this is akin to providing exceptions we don't use
>> > IMHO.  It might be okay for Pair<L, R> to implement Map.Entry<L, R>,
>> > for example.  But when you say primitive implementations, do you mean
>> > implementations based around primitive types, or simplistic
>> > implementations?  If the latter, how much more simplistic could it
>> > get?
>>
>> Our OpenGamma pair is an abstract class (not an interface!):
>> public abstract class Pair<A, B> implements Map.Entry<A, B>,
>> Comparable<Pair<A, B>>, Serializable
>>
>> There are concrete implementations for ObjectsPair, DoublesPair,
>> IntDoublePair etc. where the user can access the primitive type
>> directly, or just use the base generified class. The question is
>> whether [lang] wants no Pair, a simple one, or a full-featured one
>> (where people may disagree on what full-featured should look like).
>>
>> Stephen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>



--
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Henri Yandell
In reply to this post by jodastephen
Going through each.

On Thu, Mar 3, 2011 at 3:59 AM, Stephen Colebourne <[hidden email]> wrote:

> I'm not overly enthused about some of the changes, but since I've not
> been paying attention its difficult for me to vote/block. Anyway here
> is my review:
>
> ArrayUtils.hashCode() has been removed, but it had different
> functionality to Arrays.hashCode wrt nested arrays.
>
>        Object[] arrayA = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        Object[] arrayB = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        assertEquals(true, Arrays.hashCode(arrayB) == Arrays.hashCode(arrayA));

Fair. Should be brought back in.

> I don't love the new Pair class. We have an interface based version
> here at OpenGamma to allow primitive implementations for performance.
> I might be able to get our code released if there was interest.

Tbh, ENOCARE :) I'm happy to see there's good discussion, but I only
ever needed one when porting Scheme tutorials to Java for amusement.

> ArrayUtils.toArray() javadoc has example code that won't compile
> (missing "new") and also misses &lt; &gt; in places.

Jörg fixed.

> Some new methods use a different brace position from the existing
> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
> Validate.exclusiveBetween()...

Jörg fixed.

> Some new code isn't explicit about null handling, such as
> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...

Do you mean that the javadoc doesn't explicitly say what happens when
null is passed in?

> Some new methods don't have an @since, such as Validate.notBlank(),
> Validate.exclusiveBetween()...

Note; action item to go through the hack-Clirr and cross-reference
missing @sinces.

> StringUtils is now an odd mixture of methods that accept a
> CharSequence and ones that don't. Looking at it, I'd prefer to see
> CharSequenceUtils added to, and StringUtils methods just deal with
> Strings (A CharSequence might be mutable, so it has a different set of
> implications when writing code using it). But if that isn't OK, then
> it would be better to see everything in StringUtils take a
> CharSequence.

By design :(

The aim is that everything in StringUtils that can reasonably take a
CharSequence does; but to move a method to CharSequenceUtils simply
because we made it use a higher interface is silly.

Given the 1 method in CharSequenceUtils, discussing this makes me tend
towards shoving it in the bloated StringUtils class.

> ToStringStyle doesn't have a serialization version ID.

Presumably hasn't had one for a long time :) It's an abstract class -
it feels to me that it doesn't need to have a serialization version
ID.

> While we've moved away from NullArgumentException, I suspect it may be
> reasonably widely used.

People can make the case to add it back in :) Having Exceptions that
weren't related to our actual API turned into an exercise in navel
gazing.

> DateUtils has added a new MODIFY int enum, rather than using a real
> enum. Nor has the existing RANGE int enum been converted

Good point.

I'm still very tempted to pull the entire package. It would be fun to
port/submit the code into Joda Time and see what you parts you find
acceptable there.

> The JavaVersion name field is not used.

It is in spirit :) Pretend there's a map there with the name as the
key. Then pretend that I unrolled the map to have a simple String case
statement :)

Or ignore that and I should probably add a toString that will make it used.

> ObjectUtils.firstNonNull() differs from Google Guava in that it can
> return null. This is probably OK, but should be checked.

Six of one, half a dozen of the other. I'm not sure if returning null
or throwing NPE has any specific value over the other.

> Range is only thread safe if the objects held inside are thread safe (javadoc).

Added.

> Range.containsRange() might be better named containsAll()
> Range.overlapsRange might be better named overlaps()

I've gone with containsAll() and overlapsWith().

> Public constants on StringEscapeUtils do not have javadoc.

Reported as LANG-682 (as I have to do work now).

> The StringUtils.concat methods duplicate the existing join methods.

LANG-683.

> There are a number of TODOs in the code that might need addressing.

I've gone through these and none have been critical. Please feel free
to call them out if they are (the website has a todo report).

> The migration guide exceptions section is missing a header.

Fixed.

> Hope some of this helps (!)

Very much so. Stick around a bit more :)

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

jodastephen
On 4 March 2011 06:16, Henri Yandell <[hidden email]> wrote:
> Going through each.
>> ArrayUtils.hashCode() has been removed, but it had different
>> functionality to Arrays.hashCode wrt nested arrays.

DONE

>> I don't love the new Pair class.

New thread.

>> ArrayUtils.toArray() javadoc has example code that won't compile
>> (missing "new") and also misses &lt; &gt; in places.

DONE

>> Some new methods use a different brace position from the existing
>> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
>> Validate.exclusiveBetween()...

DONE

>> Some new code isn't explicit about null handling, such as
>> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...
> Do you mean that the javadoc doesn't explicitly say what happens when
> null is passed in?

Most of these have been done now. Arguments and results should say
"not null" or "may be null" or "null not recomended".

>> Some new methods don't have an @since, such as Validate.notBlank(),
>> Validate.exclusiveBetween()...

NOT done.

>> StringUtils is now an odd mixture of methods that accept a
>> CharSequence and ones that don't. Looking at it, I'd prefer to see
>> CharSequenceUtils added to, and StringUtils methods just deal with
>> Strings (A CharSequence might be mutable, so it has a different set of
>> implications when writing code using it). But if that isn't OK, then
>> it would be better to see everything in StringUtils take a
>> CharSequence.
>
> The aim is that everything in StringUtils that can reasonably take a
> CharSequence does; but to move a method to CharSequenceUtils simply
> because we made it use a higher interface is silly.
> Given the 1 method in CharSequenceUtils, discussing this makes me tend
> towards shoving it in the bloated StringUtils class.

If we're sticking with this as is then we should merge CharSeqUtils in.

More methods could take CharSequence too. and then convert to String
if necessary. Since this is the most important class, we need to get
it right.

>> ToStringStyle doesn't have a serialization version ID.

DONE

>> While we've moved away from NullArgumentException, I suspect it may be
>> reasonably widely used.
>
> People can make the case to add it back in :) Having Exceptions that
> weren't related to our actual API turned into an exercise in navel
> gazing.

Just saying that I think we may be asked where it went.

>> DateUtils has added a new MODIFY int enum, rather than using a real
>> enum. Nor has the existing RANGE int enum been converted

The Modify enum wasn't publicly used, so I made it private.

> I'm still very tempted to pull the entire package. It would be fun to
> port/submit the code into Joda Time and see what you parts you find
> acceptable there.

No, Date and Calendar here makes sense.

>> The JavaVersion name field is not used.

DONE (toString)

>> Range is only thread safe if the objects held inside are thread safe (javadoc).

DONE

>> Range.containsRange() might be better named containsAll()
>> Range.overlapsRange might be better named overlaps()

DONE

>> Public constants on StringEscapeUtils do not have javadoc.

LANG-682

>> The StringUtils.concat methods duplicate the existing join methods.

LANG-683.

More items:

The UTC constant in DateUtils isn't safe as TimeZone isn't immutable.
I copied the constant into DateFormatUtils for safety, but we should
probably remove it.

Spring AnnotatonUtils has a lot more useful methods. Expand in the future.

More <code>foo</code> to change to {@code foo}.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Oliver Heger-3
In reply to this post by Henri Yandell
Two minor points from my side:

- There are still many checkstyle errors in the current code base.

- Just a proposal: There are some translators in the new translate
package which can be configured with a range of the codes to be
processed. Would it make sense to use the Range class for this purpose?
Then configuration could be more flexible (because multiple ranges could
be specified), and there would probably be less duplicate code for
checking the ranges.

Oliver

Am 03.03.2011 08:39, schrieb Henri Yandell:

> Looking to release 3.0; there's not been a lot of JIRA activity and
> it's 9 months or so since we released the beta.
>
> Downloads:
>
>    http://people.apache.org/~bayard/commons-lang3-RC1/
>
> Maven repo entry:
>
>    http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>
> Website:
>
>    http://people.apache.org/~bayard/commons-lang3-RC1/site/
>
> Tag:
>
>    https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
>
> [ ] +1
> [ ] -1, because:
>
>
> Thanks,
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Commons Lang 3.0 (RC1)

Henri Yandell
On Sat, Mar 5, 2011 at 8:46 AM, Oliver Heger
<[hidden email]> wrote:
> Two minor points from my side:
>
> - There are still many checkstyle errors in the current code base.

Can be improved but nothing felt hugely critical. A large amount are
lines greater than 120 chars. Looks like SystemUtils has been
formatted for 135 chars and creates a lot of the warnings.

A fair number of generic parameter javadoc items.

Nothing I'd want to hold a release up for; but anyone can jump in and
improve. I've added javadoc for StringEscapeUtils and EntityArray as
they felt like large ones.

> - Just a proposal: There are some translators in the new translate package
> which can be configured with a range of the codes to be processed. Would it
> make sense to use the Range class for this purpose? Then configuration could
> be more flexible (because multiple ranges could be specified), and there
> would probably be less duplicate code for checking the ranges.

Very interesting.

Also makes me wonder if Range should support the notion of
Range.above, Range.below and Range.outside in addition to
Range.between and Range.is. That change the API from:

  UnicodeEscaper.between(x, y)

to:

  new UnicodeEscaper(Range.between(x,y))
  new UnicodeEscaper(Range.above(y))
  new UnicodeEscaper(Range.below(x))
  new UnicodeEscaper(Range.outsideOf(x,y))

For the translators; sounds great. I'm trying to remember if I hit
problems introducing the feature of either an open-ended Range, or an
inverted Range. Looking at LANG-551, it looks like I tried to
introduce the inverted Range notion (outsideOf) so that I could merge
in CharRange, and it never really worked.

Worth trying again I think.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]