On Wed, 14 May 2025 20:22:02 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>>> 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. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089733821
