RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

[huizhe wang]

Thanks for the comments, Jason.

The topic about equals/hashcode had been discussed. They are currently 
inherited, and by definition of CharSequence, equality is generally 
undefined. One could argue for it to be a lexicographic comparison, but 
that means changing the current specification, potentially breaking 
compatibility. Note that we made subtle wording change to the general 
description of CharSequence.

For #2, I'll add a clarification in the spec similar to those that deal 
with appending a CharSequence or StringBuffer, that the method does not 
synchronize on the source.  A better concurrent lock mechanism could 
have been devised for StringBuffer, but it'd be a fruitless effort to 
attempt to change its poor state. Given the nature of these classes, in 
almost all cases, StringBuilder is recommended over StringBuffer. So our 
effort here is to maintain a consistency between the classes.

#3, Concurrency would be better handled outside of the compare method 
(same as the above).

#4, sounds good. I'll look into the modification and probably add some 
more test cases.

Best,
Joe

On 1/26/2018 6:23 AM, Jason Mehrens wrote:
> Joe,
>
> 1. Seems odd that StringBuilder and StringBuffer are comparable but don't have an equals/hashcode implementation.
> Seems like if you are to stick with that you'll have to add the standard "natural ordering is inconsistent with equals" verbiage.
> 2. For StringBuffer compare, won't you have to either lock the 'another' object too so it is not mutated or perform some
> sort of copy before compare? Neither sound like a good option.
> 3. Does CharSequence.compare need to specify that IndexOutOfBoundsException may be thrown under concurrent modification?
> 4. For CharSequence.compare, instead of creating a special case for string would it make sense to do:
>
> ====
> if (cs1.getClass() == cs2.getClass() && cs1 instanceof Comparable) {
>          return ((Comparable<Object>) cs1).compareTo(cs2);
>   }
> ====
>
> Given #1 and #2 maybe StringBuilder and StringBuffer shouldn't implement comparable and just rely on users either calling
>   'sb1.toString().compare(sb2.toString())' or 'CharSequence.compare(sb1, sb2)'.
>
> Jason
> ________________________________________
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Joe Wang <huizhe.wang at oracle.com>
> Sent: Thursday, January 25, 2018 9:00 PM
> To: core-libs-dev
> Subject: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer
>
> Hi,
>
> Adding methods for comparing CharSequence, StringBuilder, and StringBuffer.
>
> The Comparable implementations for StringBuilder/Buffer are similar to
> that of String, allowing comparison operations between two
> StringBuilders/Buffers, e.g.
> aStringBuilder.compareTo(anotherStringBuilder). For CharSequence
> however, refer to the comments in JIRA, a static method 'compare' is
> added instead of implementing the Comparable interface. This 'compare'
> method may take CharSequence implementations such as String,
> StringBuilder and StringBuffer, making it possible to perform comparison
> among them. The previous example for example is equivalent to
> CharSequence.compare(aStringBuilder, anotherStringBuilder).
>
> Tests for java.base have been independent from each other. The new tests
> are therefore created to have no dependency on each other or sharing any
> code.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/
>
> Thanks,
> Joe