見た目はどちらもprintln()だしprintf()も使えるので、どっちも同じようなものだけど…
10万回実行してみた時間では、StringWriter版が約1900ミリ秒、PrintStream版が約5500ミリ秒だったので、StringWriterを使う方が断然良さそうだ。
（上記のソースを10万回実行、つまりWriterやOutputStreamのインスタンス生成まで含めてループさせている）

StringWriterの中身はStringBufferなので、getBuffer()でStringBufferを取得できる。
でも、StringBufferかぁ。“MTセーフなWriter”としては当然なんだろうけど。
でもこういう時にはStringBuilder版が欲しいなぁ。

てゆーか、素直にSringBuilderにappendln()があればいいんだよな…。

ちなみにこれらの場合、BufferedWriterやBufferedOutputStreamでラップすると、余計に遅くなる。[2009-02-14]
new PrintWriter(new BufferedWriter(sw))で3600ミリ秒、new PrintStream(new BufferedOutputStream(bos))は6300ミリ秒。
インスタンス生成は除いてprintln()とprintf()だけ10万回ループさせると、バッファリングしてもしなくてもあまり変わらず、Writerが1400ミリ秒、Streamが1900ミリ秒くらい。
バッファリングはファイル相手とかでないとあまり意味が無いのかも。インスタンス生成まで含めてループする場合は、バッファリングのインスタンス生成が増える分だけ遅くなってしまう訳か。

StringJoiner

JDK1.8で、区切り文字を指定して1つの文字列に結合するクラスが用意された。[2014-03-19]

import java.util.StringJoiner;

コードポイントの例

コードポイントを扱う例。[2017-01-28]

文字のStream

JDK1.8で、文字列（StringやStringBuilder等のCharSequence）を「文字（charやコードポイント）が並んでいるもの（Stream）」として扱えるようになった。[2014-04-29]

CharSequence#chars()でcharのStream、CharSequence#codePoints()でコードポイントのStreamを取得できる。
ただし、具体的にはどちらもIntStreamクラス、すなわちintのStreamになる。
特にchars()はcharのStreamなのでCharStreamといった専用のクラスになって欲しいところだし、あるいはStream<Character>の方がしっくり来るのだが。
しかしcharの為だけにCharStreamを作るのは労力が大きすぎるだろうし、Stream<Character>だとボクシングが発生するのでいまいちな感じ。
そもそもcharのStreamだとサロゲートを扱うのが困難だろうから、基本的にコードポイントの方が使われるはず。
そういった判断からIntStreamを使うようにしたのだと思う。

最後にcollectメソッドを使わないとStringに変換できないところが痛いorz
IntStreamには（Streamのような）「引数が1つ（Collectorインターフェースだけを受け取る）のcollectメソッド」が無いので、別途用意しておくことも出来ないし。

文字列の結合

文字列の連結には いくつかのコーディング方法がある。[2007-07-01]

文字列の結合は、Javaの仕様上はStringクラスに対して「+演算子」を使って行うことが出来る。
しかしStringは固定文字列しか扱えないので、文字列の結合とは、実質的には「結合された新しい文字列のStringインスタンスを作っている」ことになる。

もうちょっと言えば、文字列は結局charの配列なので、新しいchar配列を作り出してそこにコピーしていることになる。
StringもStringBuilderも、内部ではcharの配列を持っている。（Stringはchar配列の内容を変更しない、StringBuilderは変更する、というのが設計上の違い）
「+演算子」もconcat()もappend()も、内部ではchar配列上で2つの文字群をつなげて新しいStringを作っている事に変わりは無い。

単独での結合にどれくらいの時間がかかるか実験してみた。（→マシンスペック）
同じ結合を100万回繰り返して、ミリ秒単位で時間を出力。つまり一回当たりの実行時間がナノ秒単位で出ることになる。
（ここで言う「単独」とは、次の処理で使われない、完結した文字列を作り出すことを指している）

long start = System.currentTimeMillis();String str = "";for (int i = 0; i < 1000000; i++) {str = add("abc", "def");//文字列を結合するルーチンを呼ぶ}long end = System.currentTimeMillis();System.out.println(end - start);System.out.println(str);

String str = s1 + s2;

String str = s1.concat(s2);

String str = new StringBuilder(s1).append(s2).toString();

char[] buf = new char[s1.length() + s2.length()];int pos = 0;s1.getChars(0, s1.length(), buf, pos);
pos += s1.length();
s2.getChars(0, s2.length(), buf, pos);
String str = new String(buf);

2つのStringを結合する場合、String#concat()とStringBuilder#append()では、concat()の方が高速。
なぜなら、どちらもnew char[]でchar配列を準備して最後にnew String()するのだが、StringBuilderを使う方法では、（最初に）StringBuilder自身のインスタンス生成をしないといけないから。
（また、concat()はnullチェック等を行わないから）

自分自身で行ったchar配列での結合がconcat()より遅い理由は、最後の「new String()」にある。
new String()では、その中で新しいchar配列を作り、渡されたchar配列から内容をコピーしている。（Stringは不変であることが仕様なので、渡された配列の参照をそのまま保持する訳にはいかないのだろう…プログラマーが書き換えたら影響を受けてしまうので）
対してconcat()では、作ったchar配列（の参照）をそのまま新しいStringで保持しているのでコピーする手間が無い分早い。（concat()が使っているStringのコンストラクターはpublicではないので、一般プログラマーは使えない）

「+演算子」を使うと実質的にはStringBuilderが使われるにも関わらず独自に使ったStringBuilderとの差が出ている訳は、具体的には「+演算子」は「new StringBuilder(String.valueOf(s1)).append(s2).toString()」に変換されているから。
このString.valueOf()の分だけ遅い。→どう変換されるかの実験

String str = s1 + s2 + s3;

String str = s1.concat(s2).concat(s3);

String str = new StringBuilder(s1).append(s2).append(s3).toString();

char[] buf = new char[s1.length() + s2.length() + s3.length()];int pos = 0;s1.getChars(0, s1.length(), buf, pos);pos += s1.length();s2.getChars(0, s2.length(), buf, pos);pos += s2.length();s3.getChars(0, s3.length(), buf, pos);String str = new String(buf);

3つ以上のStringを結合する場合は、String#concat()よりもStringBuilder#append()の方が高速になってくる。
なぜなら、concat()では（結合一回につきnew char[]とnew String()を一回ずつ行うので）結合の回数分のインスタンス生成が発生するが、StringBuilderでは（バッファサイズが足りなくならない限り）new char[]もnew String()も一回しか行わないから。

自分でchar配列を使う方法が早いのは、nullチェック等が入っていないから。（append()では、nullを"null"という文字列にしたり バッファが超えないか確認したり、色々やっている。char配列で扱う前にString.valueOf(s1)を追加すると、append()と同等かそれ以上の時間がかかるようになる）

ループして文字列を結合していって最後に1つの文字列を作り上げる場合は、実行効率面での注意が特に必要となる。

String str = "";for (int i = 0; i < 10000; i++) {str += i;}

String str = "";for (int i = 0; i < 10000; i++) {str = str.concat(String.valudOf(i));}

StringBuilder sb = new StringBuilder();for (int i = 0; i < 1000000; i++) {sb.append(i);}String str = sb.toString();

StringBuilder sb = new StringBuilder(6*1000000);for (int i = 0; i < 1000000; i++) {sb.append(i);}String str = sb.toString();

char[] buf = new char[6 * 1000000];int pos = 0;for (int i = 0; i < 1000000; i++) {String s = String.valueOf(i);s.getChars(0, s.length(), buf, pos);pos += s.length();}String str = new String(buf, 0, pos);

StringBuilderを1つ作ってループ内でappend()していくのと 毎回Stringを作っている（「+演算子」とconcat()）のでは、実行速度の桁が違う（上記の例で200〜500倍も違う）。

初期値を指定していないStringBuilder（途中でバッファの拡張が何回か行われる）より初期値を指定した（バッファサイズが変わらない）独自のchar配列の方が早いのは当然だが。
試しにStringBuilderに初期値を指定してみると、圧倒的に早くなった。これに独自char配列方式が負けたのは、String.valueOf(int)のせい。valueOf(int)が無ければ110msくらいなので、初期値指定StringBuilderよりも早くなる。
append(int)ではString.valueOf(int)（＝Integer#toString(int)）より効率のいいIntegerクラス内のメソッドを使ってchar配列に変換しているようだ。（これもpublicメソッドではない…）

JDK1.5で「+演算子」が実際にどう変換されるか、jadを使って見てみた。

String str = "abc" + "def";

String str = "abc" + 123;

String str = "abcdef";

String str = "abc123";

String s = "def";String str = "abc" + s;

int i = 123;String str = "abc" + i;

String s = "def";String str = (new StringBuilder("abc")).append(s).toString();

int i = 123;String str = (new StringBuilder("abc")).append(i).toString();

String s = "def";String str = 123 + s;

String s = "def";String str = (new StringBuilder(String.valueOf(123))).append(s).toString();

String s = "abc";String str = s + "def";

String s = "abc";String str = (new StringBuilder(String.valueOf(s))).append("def").toString();

String str = "abc";str += "def";str += "ghi";

String str = "abc";str = (new StringBuilder(String.valueOf(str))).append("def").toString();str = (new StringBuilder(String.valueOf(str))).append("ghi").toString();

String s = "abc";StringBuilder sb = new StringBuilder();sb.append(123 + s);

String s = "abc";StringBuilder sb = new StringBuilder();sb.append((new StringBuilder(String.valueOf(123))).append(s).toString());

つまり、文字列の結合を1行でしか使わない場合は、わざわざ自分でStringBuilderに書き換える意味は無い。

複数行にまたがって結合する場合は、自分でStringBuilder#append()を使ってやらないと実行効率が悪い。
特にappend()の引数の中で「+演算子」を使って結合するのは、とっても無駄な感じ。
なんだか残念賞な感じだ。これがappendしたい対象のStringBuilderインスタンスを使った形に分割されれば良かったのに。
sb.append(123 + s) →sb.append(123).append(s)
ただ、これもロード時のバイトコード変更を考えるとやっちゃダメなんだろうなー…。[/2008-01-27]

あとは、JITコンパイル（実行時のコンパイル）の最適化がどれくらい効いてくれるかだなー。（HotSpotって、最適化してくれるのか？？）

文字列の結合に関する結論

結合を単独で使う場合、いくつの文字列を結合するかによって早さが異なるので、一概にどの方法がいいとは言えない。
しかし差が一番顕著な“2つの文字列の結合”のケースでもconcat()とappend()で2倍程度、3つ・4つの結合になれば差は縮まっていく（逆転する）ようなので、よほど速度に厳しいのでない限りは、多機能なStringBuilder（+演算子）で充分だろう。
文字列をいくつ結合するかによってコーディングを変えるなんて、ばからしい。（分かりにくいし、将来バージョンのJavaでは速い方法が変わってくるかもしれない）

自分でStringBufferやStringBuilderを使うより「+演算子」を使った方がいい理由は、JDKのバージョンによってコンパイラーが勝手に効率よい方を使ってくれること。[2007-07-04]
JDK1.5で明らかになったように、JDK1.4で「+演算子」を使っていたプログラムは（StringBufferが使われていたわけだが）、ソースを全く修正することなくJDK1.5でコンパイルし直すだけで自動的にStringBuilderが使われて実行効率がよくなる。
今後StringBuilderに替わる効率よいクラスが出来たとしたら、同じことが期待できるだろう。と言っても、そんな事そうそうあるとも思えないけどねー(爆)

でも、結合をループで使う場合や複数行で使う場合はStringBuilderを使うべき。というか、使わなきゃ許さんって感じ
（また、append()の引数で文字列結合はせず、別々にappend()すること）

• きしださんの文字列連結関連ブログ[2014-04-29]
  • StringBuilderを使ったクソコードはどこまで遅いか
  • Java8時代の文字列連結まとめ
  • Java8時代の文字列連結変態さんまとめ

文字列の等値比較

文字列が等しいかどうか比較するには、==演算子でなくequals()メソッドを使う。[2008-04-16]
==はインスタンス自体が等しいかどうかの比較を意味し、equals()は保持している内容が等しいかどうかを調べる。→オブジェクトの比較イメージ

intern()は文字列プールの中から一意となるStringを返すので、この戻り値同士ならば==で比較すると一致する。
しかしintern()はかなりコストが高い処理なので、実用的ではない。

for (int i = 0; i < 1000000; i++) {String s = new String("abc");if (sと"abc"が一致しているか判断) {}}

等値比較の書き順

文字列変数が定数と等しいかどうかを比較する場合は「str.equals("abc")」と書くのが普通。[2008-05-02]
しかしこれだと、strがnullの場合にNullPointerExceptionが発生してしまう。
なのでnullになる可能性があるのであれば、「str != null && str.equals("abc")」とするのが正しい。

しかしこれだと判断したいのは「strが"abc"と等しいかどうか」なのに、ソース上に条件が増えてしまってちょっとくどい。
この場合、オブジェクトを逆にして「"abc".equals(str)」と書くことが出来る。
そうすれば、strがnullでもfalseになるので、意図した動作になる。

しかし基本的にはプログラムは仕様と同じになるように書くべきなので、strが必ずnull以外だという分かっている（そういう仕様である）場合は、「str.equals("abc")」と書く方がいいと思う。
基本的にnullチェックはstrに値を入れた時にすべき（もしくはメソッドの引数であれば、Javadocにnull不可の旨を書く（＝nullを渡してはいけないという仕様））だと思うので、equals()を使う前にnullをはじいておけば、「str.equals("abc")」で問題ない。

自分では、必ず上記の表の判断に沿うように使っている。
すなわち「"abc".equals(str)」を使うのは、nullが有り得るという時（nullチェックを省略したい手抜きプログラムを含む）のみ。

半角カタカナ→全角カタカナ→全角ひらがな変換

半角片仮名から全角片仮名への変換は、Normalizerクラス（JDK1.6以降）を使って行うことが出来る。[2012-06-15]

import java.text.Normalizer;import java.text.Normalizer.Form;

String zen = Normalizer.normalize("ｱｲｳｴｵ", Form.NFKC);

※半角片仮名はアイウエオ順に並んでいるが、全角片仮名は間に小文字が入っていたりして綺麗に並んでいない為、文字コードの差分を使って単純に変換することは出来ない。

• 参考
  • kuwalabさんの半角カナを全角カナにする。
  • みかん箱さんの全角英数を半角に、半角カナを全角にする

全角カタカナ→全角ひらがな

全角片仮名から全角平仮名への変換（あるいはその逆）は、文字コードの差分を使って行うことが出来る。
（全角カタカナと全角ひらがなは並び順は同一なので単純に変換できる）

String from = "アイウエオ";StringBuilder sb = new StringBuilder(from.length());for (int i = 0; i < from.length(); i++) {char c = (char) (from.charAt(i) + 'あ' - 'ア');sb.append(c);}String hira = sb.toString();

全角英数→半角英数変換

全角英数から半角英数への変換もNormalizerクラス（JDK1.6以降）を使って行うことが出来る。[2014-04-29]

import java.text.Normalizer;import java.text.Normalizer.Form;

String half = Normalizer.normalize("ＡＢＣ１２３", Form.NFKC);

※これは半角カタカナを全角カタカナに変換する方法と全く同じなので、半角カタカナが混ざっているとそれも変換されてしまう点は注意が必要。