I think you're alluding to a generic, implicit promise of reasonable performance. I definitely think this is a valid assumption to make, so you are right to po

I think you're alluding to a generic, implicit promise of reasonable performance. I definitely think this is a valid assumption to make, so you are right to point it out. Any API function needs to have reasonable performance, or else there is no point in using it and it is not serving its purpose. It is very true that people write APIs to be used, and if their performance is unreasonably slow, they won't be used. This makes complete sense. If your argument is that the String implementation change constitutes "unreasonably poor performance," as in...for most normal use cases, then that makes sense. I disagree with it, but it makes sense to argue that if you think that is what's happening. That goes beyond the implementation vs. contract discussion, and maybe that is the real issue many people have. Maybe some feel like the performance hit will affect so many use cases that are common for String, that it is an unreasonable performance change.