String.chars（）がJava 8のintのストリームであるのはなぜですか？

Java 8には、文字コードを表すs（）のString.chars()ストリームを返す新しいメソッドがあります。代わりにここにsのストリームを期待する人が多いと思います。このようにAPIを設計する動機は何でしたか？intIntStreamchar

他の人がすでに述べたように、これの背後にある設計上の決定は、メソッドとクラスの爆発を防ぐことでした。

それでも、個人的にはこれは非常に悪い決断だったと思います。そして、彼らが作りたくないと考えるならばCharStream、それは合理的でありchars()、の代わりに異なる方法があるはずです。

• Stream<Character> chars()、ボックスストリームのストリームを提供しますが、パフォーマンスが若干低下します。
• IntStream unboxedChars()、パフォーマンスコードに使用されます。

ただし、現在このように行われる理由に焦点を当てるのではなく、この答えは、Java 8で取得したAPIでそれを行う方法を示すことに焦点を当てるべきだと思います。

Java 7では、次のようにしました。

for (int i = 0; i < hello.length(); i++) {
    System.out.println(hello.charAt(i));
}

そして私はJava 8でそれを行うための合理的な方法は次のとおりだと思います：

hello.chars()
        .mapToObj(i -> (char)i)
        .forEach(System.out::println);

ここでは、を取得IntStreamしてラムダを介してオブジェクトにマップしi -> (char)iます。これにより、自動的ににボックス化されます。Stream<Character>その後、必要なことを実行でき、メソッド参照をプラスとして使用できます。

注意してくださいあなたがそれにもかかわらず必要がありませんmapToObjあなたは忘れて、使用している場合、mapは、何も文句ないでしょうが、あなたはまだで終わるだろうIntStream、とあなたはそれが代わりの文字を表す文字列の整数値を出力しますなぜ不思議オフに左にされる可能性があります。

Java 8の他の醜い代替品：

に残り、IntStream最終的にそれらを印刷したい場合、メソッド参照を印刷に使用できなくなります。

hello.chars()
        .forEach(i -> System.out.println((char)i));

さらに、独自のメソッドへのメソッド参照を使用しても機能しなくなります。以下を検討してください。

private void print(char c) {
    System.out.println(c);
}

その後

hello.chars()
        .forEach(this::print);

非可逆変換が行われる可能性があるため、コンパイルエラーが発生します。

結論：

このAPIはCharStream、を追加したくないためにこのように設計されました。個人的には、メソッドはを返す必要があると思います。Stream<Character>現在の回避策は、を使用mapToObj(i -> (char)i)してIntStream適切に動作できるようにすることです。

スキーウィからの回答は、すでに多くの主要なポイントをカバーしています。もう少し背景を説明します。

APIの設計は一連のトレードオフです。Javaでは、難しい問題の1つは、ずっと前に行われた設計上の決定に対処することです。

プリミティブは1.0以降、Javaで使用されています。プリミティブはオブジェクトではないため、Javaは「純粋でない」オブジェクト指向言語になります。プリミティブの追加は、オブジェクト指向の純粋さを犠牲にしてパフォーマンスを改善するという実際的な決定だったと思います。

これは、今日、20年近く経った今でも生きているトレードオフです。Java 5で追加されたオートボクシング機能により、ソースコードをボクシングおよびアンボクシングのメソッド呼び出しで煩雑にする必要がほとんどなくなりましたが、オーバーヘッドは依然として残ります。多くの場合、それは目立ちません。ただし、内部ループ内でボックス化またはボックス化解除を実行すると、CPUとガベージコレクションのオーバーヘッドが大幅に増加する可能性があります。

Streams APIを設計するとき、プリミティブをサポートする必要があることは明らかでした。ボクシング/アンボクシングのオーバーヘッドは、並列処理によるパフォーマンス上の利点をすべて殺します。ただし、すべてのプリミティブをサポートする必要はありませんでした。APIに膨大な量の混乱が加わるからです。（本当に使用法がわかりShortStreamますか？）「すべて」または「なし」は、デザインが快適な場所ですが、どちらも受け入れられませんでした。したがって、「ある程度」の妥当な値を見つける必要がありました。私たちは、プリミティブ専門になってしまったint、longとdouble。（個人的に私は省略しintたでしょうが、それは私だけです。）

CharSequence.chars()戻ることを検討したためStream<Character>（初期のプロトタイプはこれを実装した可能性があります）、ボクシングのオーバーヘッドのために拒否されました。文字列がcharプリミティブとして値を持っていることを考えると、呼び出し元がおそらく値に対して少し処理を行い、それを文字列にアンボックスするだけの場合、無条件にボクシングを課すのは間違いのようです。

また、CharStreamプリミティブな特殊化についても検討しましたが、APIに追加するバルクの量に比べて、その使用はかなり狭いように思えます。追加する価値はないようです。

これが呼び出し元に課すペナルティは、IntStreamがcharとして表される値を含むこと、intsおよびキャストが適切な場所で行われる必要があることを知っている必要があることです。などのオーバーロードされたAPI呼び出しがPrintStream.print(char)ありPrintStream.print(int)、動作が著しく異なるため、これは二重に混乱します。codePoints()呼び出しもを返すため、混乱が生じる可能性IntStreamがありますが、それに含まれる値はまったく異なります。

したがって、これは要約すると、いくつかの選択肢の中から実用的に選択することになります。

1. プリミティブな特殊化を提供できなかったため、シンプルでエレガントな一貫したAPIが得られましたが、パフォーマンスとGCのオーバーヘッドが高くなっていました。

2. APIが散らかり、JDK開発者にメンテナンスの負担がかかるという犠牲を払って、完全な一連の基本的な特殊化を提供できます。または

3. プリミティブな特殊化のサブセットを提供して、かなり狭い範囲のユースケース（char処理）で呼び出し元に比較的小さな負担をかける、適度なサイズの高性能APIを提供できます。

最後のものを選びました。