JDK-8276970 : Default charset for PrintWriter that wraps PrintStream
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2021-11-10
  • Updated: 2024-09-11
  • Resolved: 2021-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18 b25Fixed
Related Reports
CSR :  
JDK-8277078 - Default charset for PrintWriter that wraps PrintStream
Duplicate :  
JDK-8277046 - Incorrect default encoding for System.getLogger(..).log(..) console output
Duplicate :  
JDK-8274544 - Langtools command's usage were garbled on Japanese Windows
Relates :  
JDK-8274544 - Langtools command's usage were garbled on Japanese Windows
Relates :  
JDK-8260265 - UTF-8 by Default
Relates :  
JDK-8277046 - Incorrect default encoding for System.getLogger(..).log(..) console output
Sub Tasks
JDK-8277357 :  
Release Note: Default charset for PrintWriter That Wraps PrintStream - Closed
Description
This issue was raised during the conversations in the following PR:
https://github.com/openjdk/jdk/pull/5771
The constructors that take `OutputStream` w/o explicit charset defaults to use the `Charset.defaultCharset()` encoding. This is causing an issue if the OutputStream to wrap is a PrintStream, which holds its own charset, and it will be ignored. If those charsets differ, apps would end up specifying explicit charset on creating the PrintWriter, as in the said PR.
This is especially problematic when PrintWriter wraps System.out/err, because with the JEP400, the default charset is now UTF-8 while standard I/O remains in `native.encoding`.
Comments
Changeset: 231fb61a Author: Naoto Sato <naoto@openjdk.org> Date: 2021-11-18 01:12:12 +0000 URL: https://git.openjdk.java.net/jdk/commit/231fb61aaeae04787c06a4c972197943d9085627
18-11-2021
Wrapping a PrintStream with a Writer (any Writer) has always been fragile as the charsets may not match. So yes, a PrintStream::charset method would be useful. Having PrintWriter's constrictors special-case output streams of type PrintStream might be okay but I suspect it will require the same in the 1-arg OutputStreamWriter constructor so it's consistent.
11-11-2021
The problem is made worse by not being able to access the charset in the PrintStream object. In other words, it is not even possible to go PrintStream ps = ...some stream... PrintWriter pw = new PrintWriter(ps, ps.getCharset())
10-11-2021