Request for Enhancement: java.io.Writer.of(Appendable) as an efficient alternative to java.io.StringWriter

[Chen Liang]

Sorry for a late reply.
I wonder if we should make the return type StringWriter, given StringWriter
does not throw on its Writer methods and has a convenient toString. (Making
its close() not throws IOE is binary compatible but possibly not source
compatible)
I think this StringBuilder-accepting version in general fits most of the
demands, and we can make it emulate StringWriter in a lot of behaviors and
avoid the nasty issues around closing/flushing.

On Sat, Mar 15, 2025, 12:58 PM Markus KARG <markus at headcrashing.eu> wrote:

> Chen,
>
> thank you for sharing your opinion!
>
> Thinking about what you wrote about the "trifecta" complexity, I think
> it might be better to restart my idea from scratch:
>
> As explained in my original proposal
> (
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-December/137807.html),
>
> the actual driver for my proposal was to provide a StringWriter
> alternative which solves two main problems: It shall prevent String
> copies, and it shall be non-synchronized.
>
> What comes into mind is: Writer.of(StringBuilder).
>
> While compared to Appendable this signature is much less flexible, it
> also makes less headaches, but solved in fact those 99% of cases that
> triggered this whole idea: It does not create String copies, and it is
> non-synchronized. What this writer would simply, simply would be routing
> all incoming "append" and "write" calls down to the provided string
> builder.
>
> Hence, kindly asking for comments on this updated idea: WDYT about
> Writer.of(StringBuilder)?
>
> Thanks!
>
> -Markus
>
>
> Am 10.02.2025 um 01:51 schrieb Chen Liang:
> > Hi Mark,
> > After thinking about the Appendable-Closeable-Flushable trio versus
> > Writer, I believe that one problem with Writer.of is that it goes
> > against interface segregation principle represented by the trifecta,
> > and accidentally leaking the Closeable or Flushable functionality is
> > still dubious to me. This appears simple, but it may cause unintended
> > consequences, such as if Appendable b implements Closeable too, its
> > closing behavior is not proxied and users may find this inconsistency
> > weird. And as for interface segregation principle, it means APIs
> > should request Appendable instead of Writer if they only need writing
> > abilities with no lifecycle; using Writer as the type implies
> > potential dependency on closing/flushing behavior, which can sometimes
> > be dangerous.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250323/6fa02ef3/attachment-0001.htm>