Kiran,
> On 13 Dec 2019, at 18:28, Kiran Ravikumar
> <kiran.sidhartha.raviku...@oracle.com> wrote:
>
> Hi Guys,
>
>
>
> Could someone please review my fix to URI.java class were URI.compareTo(URI)
> behavior was different to URI.equals(URI). URI.compareTo(URI) does not
> consider two URI's to be equal when they differ only in the case of
> hexadecimal digits of escaped octets, while URI.equals(URI) does consider
> such URIs to be equal.
>
> The fix involves spec and code change. A CSR was filed and approved.
>
> Please find the webrev at -
>
>
> http://cr.openjdk.java.net/~kravikumar/5064980/webrev.0/
> <http://cr.openjdk.java.net/~kravikumar/5064980/webrev.0/>
This looks very good. Just a few minor comments:
1) In the comment: "... method is not called for 'decoded' strings",
should read "... method is not called WITH 'decoded' strings", right?
2) In comment: "The only place were a percent can be followed by
anything OTHER than hexadecimal digits is ..." - OTHER
3) While here I noticed an incorrect link in the compareTo javadoc.
Maybe this could be fixed at the same time:
+++ b/src/java.base/share/classes/java/net/URI.java
@@ -1572,7 +1572,7 @@
* component is undefined but the other is defined then the first is
* considered to be less than the second. Unless otherwise noted,
string
* components are ordered according to their natural, case-sensitive
- * ordering as defined by the {@link java.lang.String#compareTo(Object)
+ * ordering as defined by the {@link java.lang.String#compareTo(String)
* String.compareTo} method. String components that are subject to
* encoding are compared by comparing their raw forms rather than their
* encoded forms.
-Chris.
