Thanks Chris. I'll add the bug number
Michael
On 30/10/13 17:52, Chris Hegarty wrote:
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