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