Hi Mike,
I agree with Peter,
a new method is better than changing subSequence to return a
CharSequence implementation that try to fake itself as a String.
And as a guys that have written several parsers (for HTTP servers or not),
ByteBuffer/CharBuffer was introduced in 1.4 to write effective
Am 19.02.2013 06:27, schrieb Mike Duigou:
http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/
I think, you should add
|| (s instanceof AbstractStringBuilder)
as third in
else if ((s instanceof StringBuilder) || (s instanceof StringBuffer)) {
, as someone could use his own subclass of
On 19/02/2013 05:27, Mike Duigou wrote:
:
http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/
From our current testing we found that applications currently using subSequence() failed
if the equals(), hashCode() and toString() implementations did not exactly match String.
Additionally we had
On Feb 19 2013, at 10:50 , Alan Bateman wrote:
On 19/02/2013 05:27, Mike Duigou wrote:
:
http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/
From our current testing we found that applications currently using
subSequence() failed if the equals(), hashCode() and toString()
Am 19.02.2013 20:00, schrieb Mike Duigou:
If I update this patch I will add Ulf suggestion of adding AbstractStringBuilder as a third
instanceof case. Mike
Thanks!
I'm stil wondering, why HotSpot doesn't optimize
for (int i = start, j = count; i end; i++, j++) {
I think it's really easy for users to write a SubSequence by
themselves if they need to solve the problem; there is no need for
String to do it, and definitely not at the expense of breaching
previous explicit contracts. We should solve this problem externally,
explicitly; not internally with some
On 02/19/2013 10:35 PM, Zhong Yu wrote:
I think it's really easy for users to write a SubSequence by
themselves if they need to solve the problem; there is no need for
String to do it, and definitely not at the expense of breaching
previous explicit contracts. We should solve this problem
Hello all;
JDK 7u6 included a significant change to java.lang.String. The change was
internal to the String implementation and didn't result in any API changes but
it does have a significant impact on the performance of some uses cases. (See
