Enthuware. Why is a PrintWriter (chars) able to open a FileOutputStream? (binary)?

I thought that FileOutputStream is for binary and PrintWriter is for characters.
So I am confused why this question (Enthuware mock test 11. enthuware.ocpjp.v17.2.1905) even compiles.
When I run it and see the file contents, it is SOH which from this ASCII table, is char = 1.

package enthuware.nio; import java.io.FileOutputStream; import java.io.OutputStream; import java.io.PrintWriter; public class Writers {    public static void createFile(String name) throws Exception{        try (                OutputStream os = new FileOutputStream(name);  ) {            var pw = new PrintWriter(os);            pw.write(1);            // Size of the file depends on default character encoding.            //flush and close the streams that are open            pw.close();        }    }    public static void main(String[] args) throws Exception {        Writers.createFile(".\\enthuware_example.txt");    } }

Why wouldn't it compile? PrintWriter has a write() method that has an int parameter, and you passed it an int.

Maybe your question is: why does PrintWriter have a write() method that has an int parameter?

I'm guessing the designers chose int because it allows you to pass an int expression without having to cast it to char first. An example:
pw.write('a' + i); Instead of
pw.write((char) ('a' + i));
Or maybe you are confused and think that SOH is not textual data. It is though. It's a control character.

Because binary is Lowest Common Denominator. Characters can be mapped onto binary (bytes) using the appropriate code page, but the reverse is not always true. In fact, not every character in every codepage can be mapped to another codepage. It's easy to map the Unicode character for a Hieroglyphic character such as \u13153) to a binary array or stream, but completely impossible to map that same character to a simple ASCII codepage.

Take a look at The Java™ Tutorials Lesson: Basic I/O

Character Streams that Use Byte Streams wrote:Character streams are often "wrappers" for byte streams. The character stream uses the byte stream to perform the physical I/O, while the character stream handles translation between characters and bytes. FileReader, for example, uses FileInputStream, while FileWriter uses FileOutputStream.

From The JavaDocs

java.io.PrintWriter wrote:public PrintWriter(OutputStream out)
Creates a new PrintWriter, without automatic line flushing, from an existing OutputStream. This convenience constructor creates the necessary intermediate OutputStreamWriter, which will convert characters into bytes using the default character encoding.

Stephan van Hulst wrote:Why wouldn't it compile?

from Boyarsky page 814

One common area where the exam likes to play tricks on you is mixing and matching I/O stream classes that are not compatible with each other. For example, take a look at each of the following examples and see whether you can determine why they do not compile:
...
new BufferedWriter(new FileOutputStream("z.txt")); // DOES NOT COMPILE
...
The first two examples do not compile because they mix Reader/Writer classes with InputStream/OutputStream classes, respectively.

In fact, trying to compile it gives error

java: incompatible types: java.io.FileOutputStream cannot be converted to java.io.Writer

I realize now that the reason it would not compile is, there should have been a PrintWriter in between.

           new BufferedWriter(new PrintWriter(new FileOutputStream("z.txt"))); // OK

Was this an incorrect reason in the textbook?

Ira Go wrote:Take a look at  

Thanks. Please see my reply to Stefan.

Anil Philip wrote:from Boyarsky page 814

The first two examples do not compile because they mix Reader/Writer classes with InputStream/OutputStream classes, respectively.

[...]

Was this an incorrect reason in the textbook?

It's a bit misleading.  In general, most Reader/Writer classes and InputStream/OutputStream classes do not connect to each other directly.  In the past, only InputStreamReader and OutputStreamWriter were the exceptions.  Nowadays PrintWriter also has a variety of constructors that allow direct connections, too.  But in general, most IO classes do not.  So a more precise reason would be "The first two examples do not compile because they require specific constructors that do not exist."  Or "The first two examples do not compile [b]because they mix Reader/Writer classes with InputStream/OutputStream classes, without using one of the classes that bridge these worlds.  But their shortened explanation is still generally valid.

Classes that bridge these worlds include InputStreamReader, OutputStreamWriter, PrintWriter, Scanner, and probably others.

Note that once you're using PrintWriter, you don't need to provide a FileOutputStream or BufferedWriter, either.  Those are provided for free if you use the appropriate constructor:
new PrintStream("z.txt");
In the old days, anytime you used I/O stream you had to chain together two, three, or more different streams to do anything.  Nowadays, you often need just one class, if it's a PrintWriter or Scanner or something from the Files class.