Hi Tagir,
Yes, it applies to all implementations.
I think the risk of incompatibility is low for 9. Based on analysis on grepcode
most CharSequence implementations don’t override the stream returning methods,
those few that do defer to some other sequence.
Paul.
> On 21 Nov 2016, at 19:44, Tagir Valeev <amae...@gmail.com> wrote:
>
> Hello!
>
>
>> diff -r a11577c64a1d src/java.base/share/classes/java/lang/CharSequence.java
>> --- a/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21
>> 10:50:01 2016 -0800
>> +++ b/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21
>> 12:17:08 2016 -0800
>> @@ -121,8 +121,11 @@
>> * href="{@docRoot}/java/lang/Character.html#unicode">surrogate code
>> * point</a> is passed through uninterpreted.
>> *
>> - * <p>If the sequence is mutated while the stream is being read, the
>> - * result is undefined.
>> + * <p>The stream binds to this sequence when the terminal stream
>> operation
>> + * commences. If the sequence is modified during that operation then
>> the
>> + * result is undefined. (Specifically, for mutable sequences the
>> + * spliterator for the stream is
>> + * <a href="../Spliterator.html#binding"><em>late-binding</em></a>.)
>
> As this an interface method with default implementation, I think, it should be
> clear whether this states a method contract for all implementors or an
> implementation detail of
> the default implementation. Here it's not in the @implNote section, so
> I assume that the new statement
> tightens the specification for all possible implementors (probably
> making valid Java-8 code invalid in Java-9
> if somebody reimplemented chars() for custom CharSequence in
> non-late-binding manner).
> Is this spec change intended?
>
> With best regards,
> Tagir Valeev.
