It's not only char arrays that are not supported.

There are only 3 types of primitive streams - IntStream, LongStream and DoubleStream.

As a result, Arrays has methods that convert int[], long[] and double[] to the corresponding primitive streams.

There are no corresponding methods for boolean[], byte[], short[], char[] and float[], since these primitive types have no corresponding primitive streams.

As Eran said, it's not the only one missing.

A BooleanStream would be useless, a ByteStream (if it existed) can be handled as an InputStream or converted to IntStream (as can short), and float can be handled as a DoubleStream.

As char is not able to represent all characters anyway (see linked), it would be a bit of a legacy stream. Although most people don't have to deal with codepoints anyway, so it can seem strange. I mean you use String.charAt() without thinking "this doesn't actually work in all cases".

So some things were left out because they weren't deemed that important. As said by JB Nizet in the linked question:

The designers explicitly chose to avoid the explosion of classes and methods by limiting the primitive streams to 3 types, since the other types (char, short, float) can be represented by their larger equivalent (int, double) without any significant performance penalty.

The reason BooleanStream would be useless, is because you only have 2 values and that limits the operations a lot. There's no mathematical operations to do, and how often are you working with lots of boolean values anyway?

As can be seen from the comments, a BooleanStream is not needed. If it were, there would be a lot of actual use cases instead of theoretical situations, a use case going back to Java 1.4, and a fallacious comparison to while loop.

Of course, the answer is "because that's what the designers decided". There is no technical reason why CharStream could not exist.

If you want justification, you usually need to turn the the OpenJDK mailing list*. The JDK's documentation is not in the habit of justifying why anything is why it is.

Someone asked

Using IntStream to represent char/byte stream is a little inconvenient. Should we add CharStream and ByteStream as well?

The reply from Brian Goetz (Java Language Architect) says

Short answer: no.

It is not worth another 100K+ of JDK footprint each for these forms which are used almost never. And if we added those, someone would demand short, float, or boolean.

Put another way, if people insisted we had all the primitive specializations, we would have no primitive specializations. Which would be worse than the status quo.

Source

He also says the same elsewhere

If you want to deal with them as chars, you can downcast them to chars easily enough. Doesn't seem like an important enough use case to have a whole 'nother set of streams. (Same with Short, Byte, Float).

Source

TL;DR: Not worth the maintenance cost.

*In case you're curious, the google query I used was

site:http://mail.openjdk.java.net/ charstream

char is a dependent part of String - storing UTF-16 values. A Unicode symbol, a code point, is sometimes a surrogate pair of chars. So any simple solution with chars only covers part of the Unicode domain.

There was a time that char had its own right to be a public type. But nowadays it is better to use code points, an IntStream. A stream of char could not straightforwardly handle surrogate pairs.

The other more prosaic reason is that the JVM "processor" model uses an int as smallest "register", keeping booleans, bytes, shorts and also chars in such an int sized storage location. To not necessarily bloat java classes, one refrained from all possible copy variants.

In the far future one might expect primitive types allowed to function as generic type parameters, providing a List<int>. Then we might see a Stream<char>.

For the moment better avoid char, and maybe use java.text.Normalizer for a unique canonical form of code points / Unicode strings.