If CharSequence is mutable and thread-safe, I would expect toString() implementation to provide the atomic snapshot (e.g. do the synchronization). Therefore, I find Sherman's argument interesting.
On the other hand, we don't seem to be having any details/requirements for contains(CharSequence) w.r.t. it's own argument. What if String.contains pulls the values one charAt at a time? The concurrency requirements are not enforceable in CharSequence alone then, unless you call the supposed-to-be-atomic toString() first. -Aleksey. On 03/20/2015 06:48 PM, Vitaly Davidovich wrote: > Yes, but that ought to be for the caller to decide. Also, although the > resulting String is immutable, toString() itself may observe mutation. > > On Fri, Mar 20, 2015 at 11:40 AM, Xueming Shen <xueming.s...@oracle.com> > wrote: > >> On 03/20/2015 02:34 AM, Tomasz Kowalczewski wrote: >> >>> Hello! >>> >>> Current implementation of String.contains that accepts CharSequence calls >>> toString on it and passes resulting string to indexOf(String). This IMO >>> defeats the purpose of using CharSequences (that is to have a mutable >>> character buffer and not allocate unnecessary objects). >>> >>> >> It is arguable that cs.toString() may serve the purpose of taking a >> snapshot of an otherwise >> "mutable" character buffer? >> >> -Sherman >> >> >> Is changing this a desirable development? It seems pretty straightforward >>> to port indexOf(String) to use CharSequence. >>> >>> If all you need is patch then I can work on it (I have signed OCA) just >>> wanted to make sure it is not a futile work. >>> >>> >> >>
