Hi Kurchi, I had a couple quick comments:
On line 1756, you might want to allocate the StringBuilder normalizedS = new StringBuilder(s.length()); to avoid resizing during the appending. On line 1754 and 1759, is it worth restructuring the logic to avoid performing indexOf twice to find the first '%'? This might be premature optimization as hopefully the URIs are short and that indexOf would be replaced with an intrinsic if hot enough. Thanks, Dave On Tue, Jan 8, 2013 at 8:19 PM, Kurchi Hazra <kurchi.subhra.ha...@oracle.com> wrote: > Hi, > > According to RFC 3986[1], hexadecimal digits encoded by a '%' should be > case-insensitive, for example,%A2 and %a2 should be > considered equal. Although, URI.equals() does take this into consideration, > the implementation of URI.hashCode() does not and > returns different hashcodes for two URIs that are similar in all respects > except for the case of the percent-encoded hexadecimal digits. > This fix attempts to construct a normalized string from the string > representing a component before calculating its hashCode. > I converted to upper case for the normalization(and not lower case) as > required by [1]. > > For testing the fix, I added an additional test scenario to an existing > test (jdk/test/java/net/URI/Test.java). While I was there, I also made > minor changes to the test so that it does not produce rawtype and other lint > warnings. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171415 > Webrev: http://cr.openjdk.java.net/~khazra/7171415/webrev.00/ > > URI.compareTo() still suffers from the same problem - I am not sure if it > should be dealt with as a separate bug. > > Thanks, > Kurchi > > [1] http://tools.ietf.org/html/rfc3986#section-6.2.2.1
