You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Streams.writerForAppendable allows us to wrap an Appendable into a Writer. In the old implementation, the wrapped Writer does nothing on invocation of flush and close. Imagine we wrapped an object which implements both Appendable and Closeable, this might confuse the user.
Description
If the wrapped object implements Flushable or Closeable, the corresponding function will be delegated to the Writer.
Checklist
New code follows the Google Java Style Guide
This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.
Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
If necessary, new public API validates arguments, for example rejects null
New public API has Javadoc
Javadoc uses @since $next-version$
($next-version$ is a special placeholder which is automatically replaced during release)
If necessary, new unit tests have been added
Assertions in unit tests use Truth, see existing tests
No JUnit 3 features are used (such as extending class TestCase)
If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
mvn clean verify javadoc:jar passes without errors
In Java I rarely see a class which implements both Appendable and one of Flushable/Closable while it's not a Writer. Maybe this case happens in pure Kotlin libs more commonly.
In Java I rarely see a class which implements both Appendable and one of Flushable/Closable while it's not a Writer
Yes, you are probably right. One such case is java.io.PrintStream though, so this change here could be a problem if a user provides System.out or System.err and the stream is now closed due to these changes.
However, it seems for all cases where Streams#writerForAppendable is used internally in Gson, the AppendableWriter is not actually 'leaked' to the user1, and Gson itself apparently does not call close() or flush() on it either. So maybe this change is not actually noticeable by users and does not have any negative side effect.
And I agree that this is a reasonable change.
Footnotes
Unless they implement a custom type adapter which calls jsonWriter.close(), though that is rather unlikely. ↩
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Streams.writerForAppendableallows us to wrap anAppendableinto aWriter. In the old implementation, the wrapped Writer does nothing on invocation offlushandclose. Imagine we wrapped an object which implements bothAppendableandCloseable, this might confuse the user.Description
If the wrapped object implements
FlushableorCloseable, the corresponding function will be delegated to the Writer.Checklist
This is automatically checked by
mvn verify, but can also be checked on its own usingmvn spotless:check.Style violations can be fixed using
mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.null@since $next-version$(
$next-version$is a special placeholder which is automatically replaced during release)TestCase)mvn clean verify javadoc:jarpasses without errors