Javaでプログラミングを始めたとき、switchステートメントが文字列を受け取らないという事実にイライラしました。その後、列挙型を使用すると、型の安全性（リファクタリングが容易になる）と他の開発者にとってわかりやすい値を渡すのではなく、列挙型を使用するメリットを実感しました。

SE7では、Enumではなく、文字列を入力として使用するスイッチを使用することにした状況を考えるのに苦労しています。文字列全体を切り替えることで実装されている場合（たとえば、部分一致または正規表現の一致ではなく）、コードが変更される理由が少なくなるようには見えません。

また、IDEツールとコーディングの読み取り/書き込み比率により、文字列値を渡すよりも余分なEnumを自動生成する方がはるかに幸せです。

彼らはプログラマーとしてどのような利益をもたらしますか？ボイラープレートが少ない？

この機能のために言語が泣き叫ぶような気はしません。たぶん私は見落としているユースケースがあります。

私の知る限り、問題は、String定数をenumにラップするだけでは言語ユーザーのニーズを十分に満たせないと考えられることです。これは公式で対処されています、JDK 7（プロジェクトコイン）メーリングリストで発表され機能提案で。

私が提案を読んだことによると、enumsを使用する代替案は、タイプが肥大化するという理由で却下されました。便宜上、提案の関連部分を以下に引用し、列挙型に対応するステートメントはます。太字でます。

主な利点：提案が好ましい変化をもたらすのは何ですか？

一連の定数文字列値に基づいて選択された操作には、より規則的なコーディングパターンを使用できます。新しいコンストラクトの意味は、Java開発者には明らかなはずです。

主な利点：提案が採用された場合、プラットフォームはなぜ優れているのですか？

文字列ベースのディスパッチコードの潜在的に優れたパフォーマンス。

主な欠点：常にコストがかかります。

コンパイラの実装とテストの複雑さが多少増加しました。

代替案：言語を変更せずに、何らかの方法で利益と利点を得ることができますか？

いいえ。文字列の等価性の連鎖if-then-elseテストは潜在的に高価であり、目的の文字列値ごとに1つの切り替え可能な定数の列挙を導入すると、正当な理由なくプログラムに別の型が追加されます...

コードを読みやすくするだけでなく、if/else if比較と比較してパフォーマンスが向上する可能性があります。変更が価値があるかどうかは、比較の回数によって異なります。文字列スイッチは、2つの個別のスイッチ命令として発行されます。最初はハッシュコードで動作するためlookupswitch、最終的にはO(log n)複雑になる傾向があります。2番目は常に完全O(1) tableswitchであるので、複合複雑さはまだO(log n)です。単一の直線的な一連のif/else ifステートメントは、ややO(n)複雑になります。

たとえば3つ以上の文字列を比較する場合、a switchはおそらくより読みやすくコンパクトです。ホットコードパスで多数の比較を行わない限り、違いに気付くことはほとんどありませんが、パフォーマンスは向上する可能性があります。

文字列のスイッチは、enum値が外部から取得される場合、つまりデータベースに保存される場合に使用できます。

JDK 7のもう1つの注目すべき点はswitch、if-elseコンストラクトよりもパフォーマンスが高いことです。

また、高速な文字列switchesの優れたユースケースは、ノードタイプと属性タイプで多くのスイッチを作成する必要がある場合のJSON / XMLストリーム解析です。私はこれのためのより良いオプションを考えることはできません。

シンプルさ

スイッチのサポートの文字列は、列挙型またはif-elseロジックに変換せずにデータを処理するのに役立ちます。Stringを有効にする方が簡単な場合があります。

JDK 7（プロジェクトコイン）メーリングリストでの機能の提案（@gnat答え）

対象の文字列値ごとに1つの切り替え可能な定数の列挙型を導入すると、正当な理由なくプログラムに別の型が追加されます...

If-Elseバージョン

これは短いですが、多くif'sは読みにくいです。そして、これは遅いです。

if (color.equals("red")) {
    System.out.println("Color is Red");
} else if (color.equals("green")) {
    System.out.println("Color is Green");
} else {
    System.out.println("Color not found");
}

列挙バージョン

列挙型を定義する必要があります。これは適切ですが、いつかは不要です。

enum Color {RED, GREEN}

通常通りの処理

try {
    switch (Color.valueOf(color)) {
        case RED:
            System.out.println("Color is Red");
            break;
        case GREEN:
            System.out.println("Color is Green");
            break;
    }
} catch (IllegalArgumentException e) {
    System.out.println("Color not found");
}

JDK 7-switchステートメントバージョンの文字列

追加の型を変換および定義せずに処理できます。

switch (color) {
    case "red":
        System.out.println("Color is Red");
        break;
    case "green":
        System.out.println("Color is Green");
        break;
    default:
        System.out.println("Color not found");
}

どの言語でもほとんどの改善はコードを読みやすくすることです。私はいつでも空想よりも読みやすいコードを好みます。

あなたはこれを信じないかもしれませんが、試してください：

public enum JettStaff {
  ADRIAN("Adrian German") {
    public String toString() {
      return name + " (dgerman@indiana.edu)";
    }
  },
  ARJIT("Arjit Sengupta") {
    public String toString() {
      return name + " (asengupt@indiana.edu)";
    }
  },

  // and on for the rest...

  private String name;

  public JettStaff(String n) { this.name = n; }
}

JettStaff x = JettStaff.SUZANNE;
System.out.println(x);

列挙型は優れているため、使用できる場合は文字列の代わりにこれらを使用する必要があります。しかし、できなかった場合があります。たとえば、Javaの外部からの外部オブジェクトを操作する必要がある場合などです。何かを解析する必要があると想像してください。サーバーの応答、構成、ログファイルなどに似ています。探しているオプションがたくさんあり、それらを列挙する方法はありません。そのため、Java <7では、たくさんのスタックに陥ります。

  if (something.equals("foo")) {
    // foo processing
  } else 
  if (something.equals("bar")) {
   // bar processing
  }

名前でそれらを取得しようとするか、カスタムString-> Enumルーチンを提供することで、この場合でも列挙を使用できますが、時には不可能または実用的ではありません（つまり、あまりにも多くの列挙を作成する必要がある場合）

TLDR：純粋にJavaコードで作業しているときは必ずEnumsを使用する必要がありますが、外部オブジェクトでは常に使用できるとは限りません。私の説明が理にかなっていることを願っています。

Stringsswitchステートメントで使用すると、コードがより読みやすく、読みやすく、プログラミングの悪い習慣だと思うという意見には同意しません。保存に使用する値を変更する場合、スイッチまたはif-elseifが発生するたびに値を変更する必要があります。コードのすべての部分にハードコードされた値を入れているため、これは良くありません。これらのハードコードされた値の1つを変更することにした場合、何をするつもりですか？すべてのコピーを検索して置き換えますか？

if-elseifステートメントでハードコーディングされた値がある場合、Java 1.5より前では、型の安全性をもたらすという理由だけで、定数プリミティブ値を使用する方がはるかに優れています。

OK、文字列値（HTTPリクエスト、ファイルなどから）を取得する場合があり、それらをプリミティブ値に変換するのは大変なことです。しかしEnum、この時点でsは良い仕事をしています。Enumに保存する値を変更する場合は、宣言するときに変更するだけです。コードの他の部分を変更する必要はありません。（もちろん、他の場所に保存されている値を変更する必要があります）。

汚くて怠codeなコードを実装するだけなら、それは完璧です。たくさんのEnums をコーディングしたくないのですが、大規模で複雑なソフトウェアはあなたを殺します。

どんな情報が入ってくるのか、そしてそれが5つの州のみになりうることを知っているなら、 Enum。ただし、可能な状態が9000を超える可能性があり、42だけを検索する必要がある場合、すべての状態を入力する必要はないため、スイッチを使用することをお勧めします。

ほとんどの状況では、可能な状態が不明であるか、多くがあり、少数しか気にしない場合を除き、ほとんどの場合、Enumが選択される傾向があります。

しかし、なぜ彼らは今それを導入しましたか？よりクリーンなコードを可能にしたのは単なる変更でした。

1.5では、Enumのカスタムボディも作成できました。