Shared handling of Jackson-owned `Writer` over caller's `OutputStream` (non-UTF-8 generators, textual backends)

Open
  • Is something wrong?
#1,740 5 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
api, backend

Research direction

Start by reading TextualTSFactory.createGenerator(...), _createWriter(), and IOContext.encodingWriter() for the non-UTF-8 OutputStream, File, and Path paths; then compare the textual-backend handling described for GuardedOutputStream. Check existing generator flush/close behavior and tests for FLUSH_PASSED_TO_STREAM and AUTO_CLOSE_TARGET. Done means the shared handling proposal works consistently without flushing or closing the caller's stream when those features are disabled.

Written by the indexing model from the issue text.

Description

3.4

Follow-up to #1738 (part 2); #1739 added GuardedOutputStream.

Problem

For non-UTF-8 encodings, TextualTSFactory.createGenerator(ObjectWriteContext, OutputStream, JsonEncoding) wraps the caller's stream directly in an OutputStreamWriter (via _createWriter()), wrapped in IOContext.encodingWriter() (#1692). With both StreamWriteFeature.FLUSH_PASSED_TO_STREAM and AUTO_CLOSE_TARGET disabled:

  • gen.flush() does not get buffered content out: e.g. with UTF16_BE, after writeString("abc") + flush() the target has received 0 bytes (encoded content stays in the OutputStreamWriter buffer)
  • gen.close() drains content via EncodingWriter.flushPending(), which calls OutputStreamWriter.flush() and thereby flushes the caller's stream, even though FLUSH_PASSED_TO_STREAM is disabled

The same applies to the File/Path generator paths using ioCtxt.encodingWriter(...).

Textual backends in jackson-dataformats-text (YAML, TOML, Properties) instead wrap the caller's stream in GuardedOutputStream, always flush/close their own Writer, and decide at flush/close time whether to flush/close the caller's stream. So JSON and those backends behave differently, and each backend generator duplicates the same flush/close branching.

Proposal
  1. In the non-UTF-8 paths, put GuardedOutputStream under the OutputStreamWriter and keep a reference to the raw stream, so that flush() always flushes the Jackson-owned Writer and only flushes the caller's stream if FLUSH_PASSED_TO_STREAM is enabled; similarly for close() and AUTO_CLOSE_TARGET (or IOContext.isResourceManaged()). This should make IOContext.EncodingWriter unnecessary.
  2. Add a shared hook in TextualTSFactory and/or helper in GeneratorBase that hands a generator both the Jackson-constructed Writer and the raw target, with the flush/close logic for that pair, so backends need not reimplement it.

🤖 Generated with Claude Code

Dominant language
Java
Stars
2.4k
Forks
952
Avg merge
3d 6h
Merged PRs (30d)
32

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FasterXML/jackson-core

All issues in FasterXML/jackson-core

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.