commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC2)
Date Sun, 10 Apr 2011 16:22:53 GMT
On Sun, Apr 10, 2011 at 8:30 AM, Luc Maisonobe <> wrote:
> Le 09/04/2011 07:06, Henri Yandell a écrit :
>> Lang is ready to consider 3.0 release again.
>> RC2 is available here:
>> Maven artifacts:
>> Website:
>> Note that there is a 2.6->3.0 Clirr report in the site that may prove useful:
>> This vote will close in 72 hours, 0400 GMT 31-March 2010
>> ================
>>     [ ] +1
>>     [ ] -1, with reason
>> ================
> -0
> In the userguide, the subsection titles style refer to lang as the
> top-level package name instead of lang3.

Not a blocker as this is website only.

> From the comments above it, I guess the str == "true" check at the
> beginning of BooleanUtils.toBooleanObject(String str) is voluntary and
> is an optimization. It should be declared as such by adding an exclusion
> filter in findbugs so it does not appear.

Not a blocker.

> The various null returns other methods of the same BooleanUtils class
> also seem to be OK since they are documented in javadoc. So they should
> also be filtered out from findbugs report.

Not a blocker; please feel free to dive in and handle both if you're willing.

> When I generate the site locally, I get an additional findbugs error not
> shown in the site linked above. This error reads:
> Null pointer dereference of System.err in
> org.apache.commons.lang3.SystemUtils.getSystemProperty(String)
> I don't understand this error. The findbugs version seem to be the same
> in both cases (1.3.9).

Very odd. There's nothing obvious with the code there; though maybe
it's confused and there's somewhere where getSystemProperty is used
(via a variable) and is referenced without being null.

I don't see this as a blocker as it's not defined enough.

> Concerning the error in ExtendedMessageFormat, it seems the superclass
> does call applyPattern from its constructor. As one cannot initialize
> any field before the superconstructor is called, it seems impossible to
> fix this error. As there is a check against null at the very beginning,
> it is probably OK and should be filtered out. However, I would like to
> see someone else analyze this error too.

The code seems fine given we can't touch the superclass.


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

View raw message