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







Reply via email to