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 <mar...@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. >
