blocks|key|1525424|text|不支持的不仅仅是char数组。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1525425|只有3种类型的原始流-+IntStream、LongStream和DoubleStream。|1525426|因此，Arrays具有将int[]、long[]和double[]转换为相应的原语流的方法。|1525427|boolean[]、byte[]、short[]、char[]和float[]没有对应的方法，因为这些原语类型没有对应的原语流。|1525428|entityMap^0|8|4|0|C|9|M|A|X|C|0|3|6|C|5|I|6|P|8|0|0|9|A|6|H|7|P|6|W|7|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]]|M|$]]

It's not only <code>char</code> arrays that are not supported.

There are only 3 types of primitive streams - <code>IntStream</code>, <code>LongStream</code> and <code>DoubleStream</code>.

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

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

blocks|key|1313775|text|正如埃兰所说，这不是唯一一个失踪的人。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1313776|BooleanStream是无用的，ByteStream+(如果存在的话)可以作为InputStream处理或转换为IntStream+(就像short一样)，float可以作为DoubleStream处理。|offset|length|style|CODE|1313777|由于char仍然不能表示所有字符(请参阅链接)，这将是一个遗留流。尽管大多数人无论如何都不需要处理代码点，所以看起来很奇怪。我的意思是，您使用String.charAt()时并不认为“这实际上在所有情况下都有效”。|1313778|所以有些事情被忽略了，因为他们被认为没那么重要。正如JB在关联问题中所说的|1313779|设计者明确地选择了通过将原始流限制为3种类型来避免类和方法的爆炸，因为其他类型(char、short、float)可以用它们更大的等效值(int、double)来表示，而不需要任何显著的性能损失。|blockquote|1313780|BooleanStream之所以无用，是因为您只有2个值，这大大限制了操作。没有数学运算要做，而且你多久要处理一次布尔值呢？|1313781|从注释中可以看出，不需要BooleanStream。如果是的话，将会有很多实际的用例而不是理论情况，一个可以追溯到Java1.4的用例，以及与while循环的错误比较。|1313782|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/22435833/why-is-string-chars-a-stream-of-ints-in-java-8^0|0|0|D|I|A|15|B|1M|9|1Z|5|28|5|2H|C|0|2|4|1Z|F|0|T|4|0|0|0|0|D|0|C|D|1Z|5|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@$D|12|E|13|F|G]|$D|14|E|15|F|G]|$D|16|E|17|F|G]|$D|18|E|19|F|G]|$D|1A|E|1B|F|G]|$D|1C|E|1D|F|G]|$D|1E|E|1F|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1G|8|@$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1L|8|@]|9|@$D|1M|E|1N|1|1O]]|A|$]]|$1|L|3|M|5|N|7|1P|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1T|8|@$D|1U|E|1V|F|G]|$D|1W|E|1X|F|G]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

As Eran said, it's not the only one missing.
A <code>BooleanStream</code> would be useless, a <code>ByteStream</code> (if it existed) can be handled as an <code>InputStream</code> or converted to <code>IntStream</code> (as can <code>short</code>), and <code>float</code> can be handled as a <code>DoubleStream</code>.
As <code>char</code> 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 <code>String.charAt()</code> without thinking &quot;this doesn't actually work in all cases&quot;.
So some things were left out because they weren't deemed that important. As said by JB Nizet in the <a href="https://stackoverflow.com/questions/22435833/why-is-string-chars-a-stream-of-ints-in-java-8">linked question</a>:
<blockquote>
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.
</blockquote>
The reason <code>BooleanStream</code> 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?
<hr />
As can be seen from the comments, a <code>BooleanStream</code> 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 <code>while</code> loop.

blocks|key|680713|text|当然，答案是“因为这是设计师们的决定”。没有技术上的原因可以解释为什么CharStream不存在。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|680714|如果要说明理由，通常需要打开OpenJDK邮件列表*。JDK的文档并不习惯于解释为什么是这样的。|680715|有人问|680716|使用IntStream来表示char/字节流有点不方便。我们也应该添加CharStream和ByteStream吗？|blockquote|680717|Brian+(Java语言架构师)的答复说|680718|简短回答:不。
对于这些几乎从未使用过的表单，JDK占用的每一个100K%2B都是不值得的。如果我们加上这些，有人会要求短、浮点或布尔值。
换句话说，如果人们坚持我们拥有所有的原始专业，我们就不会有原始的专门化。会比现状更糟。|680719|来源|680720|他在其他地方也说过同样的话|680721|如果你想把它们当作字符来处理，你可以很容易地将它们降为字符。似乎不像一个重要的用例，不足以有一个完整的‘其他的一组流。(同样的短，拜特，浮点)。|680722|680723|TL;DR:不值得维护费用。|BOLD|680724|*如果您好奇，我使用的google查询是|680725|site:http://mail.openjdk.java.net/+charstream|code-block|syntax|javascript|680726|entityMap|0|LINK|mutability|MUTABLE|url|http://mail.openjdk.java.net/pipermail/lambda-dev/2013-March/008535.html|1|http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December.txt^0|Z|A|0|0|0|0|0|0|0|2|0|0|0|0|0|2|1|0|0|E|0|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1K|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1L|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1M|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|1N|8|@]|D|@]|E|$]]|$1|O|3|P|5|L|7|1O|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1P|8|@]|D|@$9|1Q|A|1R|1|1S]]|E|$]]|$1|S|3|T|5|6|7|1T|8|@]|D|@]|E|$]]|$1|U|3|V|5|L|7|1U|8|@]|D|@]|E|$]]|$1|W|3|R|5|6|7|1V|8|@]|D|@$9|1W|A|1X|1|1Y]]|E|$]]|$1|X|3|Y|5|6|7|1Z|8|@$9|20|A|21|B|Z]]|D|@]|E|$]]|$1|10|3|11|5|6|7|22|8|@]|D|@]|E|$]]|$1|12|3|13|5|14|7|23|8|@]|D|@]|E|$15|16]]|$1|17|3|-4|5|6|7|24|8|@]|D|@]|E|$]]]|18|$19|$5|1A|1B|1C|E|$1D|1E]]|1F|$5|1A|1B|1C|E|$1D|1G]]]]

Of course, the answer is "because that's what the designers decided". There is no technical reason why <code>CharStream</code> 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

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

The reply from Brian Goetz (Java Language Architect) says

<blockquote>
 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. 
</blockquote>

<a href="http://mail.openjdk.java.net/pipermail/lambda-dev/2013-March/008535.html" rel="noreferrer">Source</a>

He also says the same elsewhere

<blockquote>
 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).
</blockquote>

<a href="http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December.txt" rel="noreferrer">Source</a>

TL;DR: Not worth the maintenance cost.

<hr>

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

<pre><code>site:http://mail.openjdk.java.net/ charstream
</code></pre>

blocks|key|1313841|text|char是存储UTF-16值的String的依赖部分.Unicode符号，代码点，有时是代理字符对。因此，任何使用chars的简单解决方案都只涉及Unicode域的一部分。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1313842|有一段时间，char有自己的权利成为一个公共类型。但是现在最好使用代码点，一种IntStream。一个字符流不能直接处理代理项对。|BOLD|1313843|另一个更平淡的原因是JVM“处理器”模型使用int作为最小的“寄存器”，在这样一个int大小的存储位置保留布尔值、字节、短裤和字符。为了不一定要膨胀java类，可以避免所有可能的复制变体。|1313844|在遥远的未来中，人们可能会期望允许基元类型作为泛型类型参数，从而提供一个List<int>。那么我们可能会看到一个Stream<char>。|1313845|目前最好避免使用char，并可能将java.text.Normalizer用于代码点/+Unicode字符串的唯一规范形式。|1313846|entityMap|0|LINK|mutability|MUTABLE|url|https://openjdk.java.net/jeps/218^0|0|4|F|6|0|6|4|13|9|X|3|0|M|3|0|10|9|1L|C|1|5|0|0|8|4|H|K|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|H]]|D|@]|E|$]]|$1|I|3|J|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]]|D|@$9|1G|A|1H|1|1I]]|E|$]]|$1|M|3|N|5|6|7|1J|8|@$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1O|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]]]

<code>char</code> is a dependent part of <code>String</code> - 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 <code>char</code> had its own right to be a public type. But nowadays it is better to use code points, an <code>IntStream</code>. A stream of char could not straightforwardly handle surrogate pairs.

The other more prosaic reason is that the JVM "processor" model uses an <code>int</code> 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 <a href="https://openjdk.java.net/jeps/218" rel="noreferrer">the far future</a> one might expect primitive types allowed to function as generic type parameters, providing a <code>List&lt;int&gt;</code>. Then we might see a <code>Stream&lt;char&gt;</code>.

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

While going through the ways of converting primitive arrays to Streams, I found that <code>char[]</code> are not supported while other primitive array types are supported. Any particular reason to leave them out in the stream?

Why are char[] the only arrays not supported by Arrays.stream()?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在研究将原始数组转换为流的方法时，我发现不支持char[]，而支持其他基元数组类型。有什么特别的理由把他们丢在河里吗？

问为什么char[]是Arrays.stream()不支持的唯一数组？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么char[]是Arrays.stream()不支持的唯一数组？EN