Hi Angela,
That's right. Probably a leftover from when we factored out
AbstractTree. We should probably move the null checks up to the public
facing tree implementations.
Michael
On 6.11.15 10:40 , Angela Schreiber wrote:
hi michael
but it's an internal method in an internal class and i don't see
how an API consumer can overwrite it... that's why the check really
looks redundant to me in particular as it would equally result in an NPE,
which looks bad anyway.
kind regards
angela
On 06/11/15 11:31, "Michael Dürig" <[email protected]> wrote:
Hi,
On 6.11.15 10:03 , [email protected] wrote:
Author: angela
Date: Fri Nov 6 10:03:03 2015
New Revision: 1712931
URL: http://svn.apache.org/viewvc?rev=1712931&view=rev
Log:
OAK-3593 : improvements to plugins/tree
Modified:
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plu
gins/tree/impl/AbstractTree.java
URL:
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/
org/apache/jackrabbit/oak/plugins/tree/impl/AbstractTree.java?rev=1712931
&r1=1712930&r2=1712931&view=diff
=========================================================================
=====
---
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plu
gins/tree/impl/AbstractTree.java (original)
+++
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plu
gins/tree/impl/AbstractTree.java Fri Nov 6 10:03:03 2015
@@ -18,7 +18,6 @@
protected void buildPath(@Nonnull StringBuilder sb) {
AbstractTree parent = getParentOrNull();
if (parent != null) {
- parent.buildPath(checkNotNull(sb));
+ parent.buildPath(sb);
sb.append('/').append(getName());
}
I don't think those null check are redundant here and I would like to
have them back. The @Nonnull annotation does some rather week static
analysis, which is helpful but by no means complete. The missing null
check easily makes a API usage error look like an implementation error
thus causing bogus bug reports.
Michael
