La comparaison de Java enum membres: == ou equals()?

Peut == être utilisé sur enum?

Oui: les énumérations ont serré instance de contrôle qui vous permet d'utiliser == de comparer les instances. Voici la garantie fournie par la spécification du langage (accent mis par moi):

JLS 8.9 Enums

Un type enum n'a pas d'instances autres que celles définies par son enum constantes.

C'est une erreur de compilation pour tenter d'instancier explicitement un type enum. Le final clone méthode dans Enum assure que enum constantes ne peut jamais être cloné, et le traitement spécial par le mécanisme de sérialisation s'assure que les instances dupliquées ne sont jamais créées à la suite de la désérialisation. Réfléchissant à l'instanciation des types enum est interdite. Ensemble, ces quatre choses s'assurer qu'aucun cas d'un enum type existent au-delà de celles définies par la enum constantes.

Car il n'existe qu'une seule instance de chaque enum constante, il est permis d'utiliser le == de l'opérateur en place de la equals méthode lorsque l'on compare les deux références de l'objet si il est connu qu'au moins l'un d'eux se réfère à une enum constante. (Le equals méthode dans Enum est un final méthode qui se borne à invoquer super.equals sur son argument et renvoie le résultat, réalisant ainsi une identité comparaison).

Cette garantie est suffisamment forte pour que Josh Bloch recommande, si vous insistez sur l'utilisation d'un singleton, la meilleure façon de la mettre en œuvre est l'utilisation d'un seul élément enum (voir: Efficace Java 2nd Edition, Point 3: Appliquer le singleton de la propriété avec un constructeur privé ou un type enum; aussi Fil de sécurité dans Singleton)

---

Quelles sont les différences entre == et equals?

Comme un rappel, il doit être dit qu'en général, == n'est PAS une alternative viable à equals. Quand il est, cependant (comme avec enum), il y a deux différences importantes à prendre en compte:

== jamais jette NullPointerException

enum Color { BLACK, WHITE };

Color nothing = null;
if (nothing == Color.BLACK);      //runs fine
if (nothing.equals(Color.BLACK)); //throws NullPointerException

== est sous réserve de la compatibilité du type de vérifier au moment de la compilation

enum Color { BLACK, WHITE };
enum Chiral { LEFT, RIGHT };

if (Color.BLACK.equals(Chiral.LEFT)); //compiles fine
if (Color.BLACK == Chiral.LEFT);      //DOESN'T COMPILE!!! Incompatible types!

---

Devrait == être utilisé le cas échéant?

Bloch mentionne spécifiquement que immuables classes qui ont le contrôle de leurs instances peuvent garantir à leurs clients que == est utilisable. enum est spécifiquement mentionné pour illustrer.

Article 1: Envisager statique usine méthodes à la place des constructeurs

[...] il permet immuable classe pour vous la garantie de l'absence de deux cas existent: a.equals(b) si et seulement si a==b. Si une classe rend cette garantie, puis à ses clients d'utiliser le == opérateur au lieu de la equals(Object) méthode, ce qui peut entraîner une amélioration des performances. Les types Enum fournir cette garantie.

Pour résumer, les arguments pour l'utilisation de == sur enum sont:

• Il fonctionne.
• C'est plus rapide.
• C'est plus prudent au moment de l'exécution.
• Il est plus sûr au moment de la compilation.

Comme d'autres l'ont dit, les deux == et .equals() de travail dans la plupart des cas. Le temps de compilation de certitude que vous n'êtes pas en comparant complètement différents types d'Objets que d'autres ont souligné est valide et bénéfique, cependant ce type de bug des objets de comparaison de deux différents moment de la compilation types serait également trouvé par FindBugs (et probablement par Eclipse/IntelliJ moment de la compilation des inspections), de sorte que le compilateur Java de trouver qu'il n'ajoute pas beaucoup plus de sécurité.

Cependant:

1. Le fait que == jamais jette des NPE dans mon esprit, c'est un inconvénient de ==. Il ne devrait presque jamais besoin de enum types de null, depuis supplémentaires de l'état que vous souhaitez exprimer via null peut simplement être ajouté à la enum comme une instance supplémentaire. Si c'est de façon inattendue null, je préfère avoir un NPE que == silencieusement de l'évaluation à la valeur false. Donc je suis en désaccord avec la , c'est plus prudent au moment de l'exécution opinion; il est préférable de prendre l'habitude de ne jamais laisser les enum valeurs @Nullable.
2. L'argument que == est plus rapide est aussi faux. Dans la plupart des cas, vous pourrez appeler .equals() sur une variable dont le temps de compilation est de type enum classe, et dans ces cas, le compilateur ne peut pas savoir que c'est le même que == (car un enum's equals() méthode peut pas être modifiée) et permet d'optimiser l'appel de la fonction de distance. Je ne suis pas sûr si le compilateur ne le fait actuellement, mais si ça ne marche pas, et s'avère être un problème de performances en Java dans l'ensemble, alors, je préfère fixer le compilateur de 100 000 programmeurs Java changer leur style de programmation pour répondre à un particulier version compilateur caractéristiques de performance.
3. enums sont des Objets. Pour tous les autres types d'Objet de la norme de comparaison est .equals(), pas ==. Je pense qu'il est dangereux de faire une exception pour enums parce que vous pourriez accidentellement Objets de comparaison avec == au lieu de equals(), surtout si vous refactoriser un enum dans une situation de non-enum class. Dans le cas d'un refactoring, la Il fonctionne point à partir de ci-dessus est faux. Pour vous convaincre que l'utilisation de == est correcte, vous devez vérifier si la valeur en question est soit un enum ou un primitif; si c'était un non-enum classe, il avait mal, mais facile de manquer parce que le code serait encore de la compilation. Le seul cas où une utilisation de .equals() serait faux est de savoir si les valeurs en question étaient primitives; dans ce cas, le code ne compile pas, donc il est beaucoup plus difficile de manquer. Par conséquent, .equals() est beaucoup plus facile à identifier comme étant correcte, et est plus sûr contre les futures refactorings.

En fait, je pense que le langage Java doivent avoir défini == sur les Objets à l'appel .equals() sur la valeur de la main gauche, et d'introduire un opérateur séparées pour l'identité de l'objet, mais ce n'est pas la façon de Java, a été défini.

En résumé, je pense que les arguments sont en faveur de l'utilisation de .equals() pour enum types.

Ici n'est qu'une grossière calendrier de test pour comparer les deux:

import java.util.Date;

public class EnumCompareSpeedTest {

    static enum TestEnum {ONE, TWO, THREE }

    public static void main(String [] args) {

        Date before = new Date();
        int c = 0;

        for(int y=0;y<5;++y) {
            for(int x=0;x<Integer.MAX_VALUE;++x) {
                if(TestEnum.ONE.equals(TestEnum.TWO)) {++c;}
                if(TestEnum.ONE == TestEnum.TWO){++c;}              
            }
        }

        System.out.println(new Date().getTime() - before.getTime());
    }   

}

Commentaire de l'IFs, un à un. Voici les deux se compare à partir de ci-dessus dans démonté byte-code:

 21  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 24  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 27  invokevirtual EnumCompareSpeedTest$TestEnum.equals(java.lang.Object) : boolean [28]
 30  ifeq 36

 36  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 39  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 42  if_acmpne 48

La première (est égal à) effectue un appel virtuel et tests le retour booléen à partir de la pile. La deuxième (==) compare l'objet d'adresses directement à partir de la pile. Dans le premier cas, il n'y a plus d'activité.

J'ai couru ce test plusieurs fois avec les deux IFs, un à la fois. Le "==" est un peu plus rapide.

Utiliser autre chose que le == de comparer enum constantes est un non-sens. C'est comme en comparant class objets avec equals – ne pas le faire!

Cependant, il y a un méchant bug (BugId Six million deux cent soixante dix sept mille sept cent quatre vingt un) dans Sun JDK 6u10 et antérieures qui pourrait être intéressant pour des raisons historiques. Ce bug empêchait la bonne utilisation de == sur désérialisé enums, même si c'est sans doute un peu un cas de coin.

tl;dr

Une autre option est le Objets.égal à méthode utilitaire.

Objects.equals( thisEnum , thatEnum )

Objects.equals pour les nuls-la sécurité

opérateur = = = au lieu de .equals()

De l'opérateur qui est celui que je dois utiliser?

Une troisième option est la statique equals méthode trouvée sur le Objets classe utilitaire ajoutée à Java 7 et plus tard.

Exemple

Voici un exemple d'utilisation de la Mois enum.

boolean areEqual = Objects.equals( Month.FEBRUARY , Month.JUNE ) ;  //Returns `false`.

Avantages

J'ai trouver quelques avantages à cette méthode:

• Null-sécurité
  • Nulles ➙ true
  • Null ➙ false
  • Pas de risque de jeter NullPointerException
• Compact, lisible

Comment il fonctionne

Qu'est-ce que la logique utilisée par Objets.égal à?

Voir pour vous-même, à partir de la Java 10 code source de OpenJDK:

return (a == b) || (a != null && a.equals(b));

En bref, les deux ont des avantages et des inconvénients.

D'une part, il a des avantages à utiliser ==, comme décrit dans les autres réponses.

D'autre part, si vous pour une raison quelconque remplacer les énumérations avec une approche différente (normal des instances de classe), ayant utilisé == vous pique. (BTDT.)

== pouvez jeter NullPointerException si un type primitif est par rapport à sa version de la Classe. Par exemple:

private static Integer getInteger() {
    return null;
}

private static void foo() {
    int a = 10;

    //Following comparison throws a NPE, it calls equals() on the 
    //non-primitive integer which is itself null. 
    if(a == getInteger()) { 
        //Some code
    }
}