Looks good to me Michael. Trivially, the test could include this bug number in its @bug tag.
-Chris > On 30 Oct 2013, at 16:51, Michael McMahon <michael.x.mcma...@oracle.com> > wrote: > > Interesting little bug this one. The precedence rules > were overlooked and the expected result of an expression evaluation > wasn't what was expected. The webrev is below, but the diff is > > diff -r 9a5048dc7c0d src/share/classes/java/net/URLPermission.java > --- a/src/share/classes/java/net/URLPermission.java Wed Oct 30 14:41:42 > 2013 +0000 > +++ b/src/share/classes/java/net/URLPermission.java Wed Oct 30 16:33:15 > 2013 +0000 > @@ -353,7 +353,7 @@ > return getActions().hashCode() > + scheme.hashCode() > + authority.hashCode() > - + path == null ? 0 : path.hashCode(); > + + (path == null ? 0 : path.hashCode()); > } > > > Without the parentheses: > > scheme.hashCode() + authority.hashCode() + path > > is evaluated as a string concatenation. The result is compared with null, > which always fails, > meaning that path.hashCode() is always called, even when path is null .... > > webrev is at http://cr.openjdk.java.net/~michaelm/8027570/webrev.1/ > > Thanks > Michael > > > > > >
