このJava 9機能について読んだところですhttps://bugs.openjdk.java.net/browse/JDK-8085796 StringBuilderを使用した「遅い」文字列連結が改善されると言っています。
だから私の質問は、次の方法で int を String にキャストすることの欠点がまだあるかどうかです。
int i = 16;
String s = ""+i;
または、 or を使用して int を String にキャストすることの長所/短所はありますInteger.toString(i)かString.valueOf(i)?
編集：私の質問は意見に基づいていたので（それは残念です）、変更しました。さまざまなキャスティングのプラス面またはマイナス面に興味があります。そして、誰もがどちらを使用するかを自分で決定する必要があります。
まず第一に、Integer.toString(i)常により速いという仮定""+iは成立しません。
最も注目に値するのiは、 がコンパイル時定数である場合、""+iとは反対に、同様になりString.valueOf(i)ます。もちろん、定義が のようなものである場合final int i=16;、読者は の使用に反対する""+iでしょ"16"う。final int DEFAULT_USER = DEFAULT_GROUP << GROUP_BIT;しかし、 ,について話している場合は""+DEFAULT_USER、実際の数値を含むリテラル文字列よりもはるかに明確です。また、コンパイル時の定数であることは、単なるパフォーマンスの問題ではなく、ステートメントの注釈またはcaseラベルで文字列を使用できるようにします。switch
がコンパイル時の定数でない場合i、必須のコンパイル済み形式はないため、原則として、コンパイラはいずれにコンパイル""+iしてもかまいませInteger.toString(i)ん。通常の単純な (または「単純な」と呼びましょう) 実装new StringBuilder().append("").append(i).toString()をInteger.toString(i)バリアントまたは仮想的に最適化された Java 9 実装と比較すると、StringBuilderのバッファーから resultStringの値配列への最終的なコピー アクションのみがパフォーマンスを発揮する可能性があります。影響はありますが、これは HotSpot JVM によって最適化される可能性があります。Java 9 ソリューションが目指すもう 1 つの問題であるStringBuilderの初期容量は、ここでは関係ありませintん16 char。
ほとんどの重要intな値では、小数形式への変換のコストが他のコストを大幅に上回り""+iますInteger.toString(i)。これは、Java 9 の実装で劇的なスピードアップを期待するべきではないことも意味します。主な操作はこれまでと同じです。
Java 9 ソリューションの最大の改善点は、コード サイズの縮小だと思います。これは、すべての文字列連結式に対して生成されるこれらの同様の呼び出しシーケンスがすべて 1 つの命令に折りたたまれるためです (これは、複数の式の連結に特に関連します)。パフォーマンスを向上させる機会は素晴らしいアドオンにすぎませんが、特に JRE 9 の最初のバージョンでは、劇的な改善は期待できません。
したがって、""+iandInteger.toString(i)またはの決定String.valueOf(i)は単にスタイル上の問題 (ここでは説明しません) であり、パフォーマンスの問題ではありません。