*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 <scolebou...@joda.org> 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 < > 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 <flame...@gmail.com> 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: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
