I agree. Adding a new method that doesn't toString the CS would be
desirable. In these special cases, it's perfectly fine if there's no
string intrinsic that kicks in (and thus the actual operation is a bit
slower) -- the goal is to avoid the allocation.
On Fri, Mar 20, 2015 at 8:41 AM, Tomasz Kowalczewski <
tomasz.kowalczew...@gmail.com> wrote:
> It is more about custom implementations of CharSuqence that may be backed
> by some exotic matter and calling toString on them to create actual String
> goes against purpose of CharSequence in the first place (esp. when passing
> it to a method that accepts CharSequence). For JDK user it is easy to avoid
> calling contains and roll his/her own implementation but it would be nice
> if we can avoid such surprises.
>
>
> On Fri, Mar 20, 2015 at 1:31 PM, Aleksey Shipilev <
> aleksey.shipi...@oracle.com> wrote:
>
> > On 03/20/2015 03:28 PM, Aleksey Shipilev wrote:
> > > I wonder if the change is "only" about specializing
> > > indexOf(CharSequence) on the Java side to shortcut to indexOf(String)
> > > and others, like String.contentEquals(CharSequence) already does.
> >
> > Ah, sorry for the confusion, contains(CharSequence) already
> > "specializes" via shortcut in
> >
> > String toString() {
> > return this;
> > }
> >
> > public boolean contains(CharSequence s) {
> > return indexOf(s.toString()) > -1;
> > }
> >
> > So the question is about StringBuffers/StringBuilders then?
> >
> > -Aleksey.
> >
> >
>
>
> --
> Tomasz Kowalczewski
>
