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-boun...@openjdk.java.net> on behalf of Joe Wang
<huizhe.w...@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
