Chen,
limiting param type to StringBuilder (instead of Appendable) really
makes things easier (without standing in the way of some future more
general of() variant, eventually): We can easily clarify in JavaDocs how
things work like (in the sense of "close and flush are no-ops"). I will
prepare a PR on that agreement to have some code at hand to discuss in
detail.
Restricting result type to StringWriter (instead of Writer) IMHO is
*impossible*, due to the existence of StringWriter::getBuffer(): That
method returns StringBuffer, which is synchronized (hence spoils the
core idea of Writer.of(): being *non*-synchronized), and unfortunately
also is final (so we can't get rid of synchronized using inheritance).
Did I miss something?
Anyways, I actually think that being *as least specific as possible*
regarding the actual result type is a *good* thing, so users do not
imply anything, but actually accept the rules we lay out in the
JavaDocs. We should not limit our future possibilities to change without
good reason.
-Markus
Am 23.03.2025 um 10:06 schrieb 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 <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.
