On Wed, 14 May 2025 20:52:00 GMT, Markus KARG <d...@openjdk.org> wrote:
>> There's nothing in the CharSequence interface that requires or indicates >> that the implementation is or is not immutable. Interfaces only have loosely >> defined contracts, only the signature of the methods, the caller can not >> hold any more expectations about the semantics of the implementation. >> Immutable objects are among the best tools we have for making reliable >> software. >> The caller does not have to have a deep knowledge of the implementation to >> get predictable results. >> For most OpenJDK public APIs, the objective is to have well defined >> semantics with no implementation surprises. > > Granted in general, but again, it is not the job of *this particular API* to > forbid mutation *iff* the caller and / or producer of the object see a good > reason for that. This completely overdesigns the target of *this* API. > Callers are no dummies, they can read JavaDocs, and they can `.toString()` on > their own *iff* needed. Actually, in 30 years I never heard a Java Programmer > say "oops, I did not expect `CharSequence` to mutate". With that attitude we > could simply deprecate `CharSequence` for removal...! > > BTW, how will you mutate a `CharSequence` if you don't know its actual > implementation? Try-and-error? 🤔 Or with "immutable" do you mean *constant* > objects (i. e. *the producer* will not modify it after creation)? > > It is a *good* thing not to know what you have in your hands, as you *do not > start* making assumptions (like "it is immutable"). I am fond of getting > *away* from those restricted semantics, towards a cleaner "do not assume, do > not trust" policy. > > Maybe a good idea at this point if @mkarg could provide an example of > > server code benefitting from returning a CharSequence... > > The most simple example is a file server. Incidential fact, just today I > wrote a function that simply passes JSON documents received in a REST call > forward to another server using another REST call (without parsing it). The > document is not changed. It is _inefficient_ to force it into a `String` > temporarily. This is not untypical, such use cases exists often in server > computing. Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090374558
