On Sun, Apr 10, 2011 at 8:30 AM, Luc Maisonobe <luc.maison...@free.fr> wrote: > Le 09/04/2011 07:06, Henri Yandell a écrit : >> Lang is ready to consider 3.0 release again. >> >> RC2 is available here: >> >> http://people.apache.org/~bayard/commons-lang3-3.0-RC2/ >> >> Maven artifacts: >> >> http://people.apache.org/~bayard/commons-lang3-3.0-RC2/maven/ >> >> Website: >> >> http://people.apache.org/~bayard/commons-lang3-3.0-RC2/site/ >> >> Note that there is a 2.6->3.0 Clirr report in the site that may prove useful: >> >> >> http://people.apache.org/~bayard/commons-lang3-3.0-RC2/site/lang2-lang3-clirr-report.html >> >> 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) > CORRECTNESS NP_ALWAYS_NULL 1247 High > > 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. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
