On Thu, 15 May 2025 06:27:36 GMT, Johannes Döbler <d...@openjdk.org> wrote:
>> 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. If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090841625
