Je sais que les énumérations Java sont compilées en classes avec des constructeurs privés et un groupe de membres statiques publics. Lorsque je compare deux membres d'une énumération donnée, j'ai toujours utilisé .equals(), par exemple

public useEnums(SomeEnum a)
{
    if(a.equals(SomeEnum.SOME_ENUM_VALUE))
    {
        ...
    }
    ...
}

Cependant, je suis juste tombé sur un code qui utilise l'opérateur égal ==au lieu de .equals ():

public useEnums2(SomeEnum a)
{
    if(a == SomeEnum.SOME_ENUM_VALUE)
    {
        ...
    }
    ...
}

Quel opérateur dois-je utiliser?

Les deux sont techniquement corrects. Si vous regardez le code source .equals(), il s'en remet simplement à ==.

J'utilise ==, cependant, car ce sera sans danger.

Peut ==être utilisé sur enum?

Oui: les énumérations ont des contrôles d'instance serrés qui vous permettent d'utiliser ==pour comparer des instances. Voici la garantie fournie par la spécification de la langue (je souligne):

JLS 8.9 Enums

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

Il s'agit d'une erreur au moment de la compilation de tenter d'instancier explicitement un type d'énumération. La final cloneméthode in Enumgarantit que les enumconstantes ne peuvent jamais être clonées, et le traitement spécial par le mécanisme de sérialisation garantit que les instances en double ne sont jamais créées à la suite de la désérialisation. L'instanciation réfléchie des types d'énumération est interdite. Ensemble, ces quatre éléments garantissent qu'aucune instance d'un enumtype n'existe au-delà de celles définies par les enumconstantes.

Puisqu'il n'y a qu'une seule instance de chaque enumconstante, il est permis d'utiliser l' ==opérateur à la place de la equalsméthode lors de la comparaison de deux références d'objet s'il est connu qu'au moins l'une d'entre elles se réfère à une enumconstante . (La equalsméthode in Enumest une finalméthode qui invoque simplement super.equalsson argument et renvoie le résultat, effectuant ainsi une comparaison d'identité.)

Cette garantie est suffisamment forte pour que Josh Bloch recommande que si vous insistez pour utiliser le modèle singleton, la meilleure façon de l'implémenter est d'utiliser un seul élément enum(voir: Effective Java 2nd Edition, Item 3: Enforce the singleton property with a constructeur privé ou type enum ; également Thread safety in Singleton )

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

Pour rappel, il faut dire qu'en général, ce ==n'est PAS une alternative viable à equals. Quand c'est le cas (comme avec enum), il y a deux différences importantes à considérer:

== ne jette jamais NullPointerException

enum Color { BLACK, WHITE };

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

== est soumis à une vérification de compatibilité des types lors 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!

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

Bloch mentionne spécifiquement que les classes immuables qui ont un contrôle approprié sur leurs instances peuvent garantir à leurs clients qu'elles ==sont utilisables. enumest spécifiquement mentionné pour illustrer.

Point 1: envisager des méthodes d'usine statiques plutôt que des constructeurs

[...] il permet à une classe immuable de garantir qu'il n'existe pas deux instances égales: a.equals(b)si et seulement si a==b. Si une classe fait cette garantie, ses clients peuvent utiliser l' ==opérateur à la place de la equals(Object)méthode, ce qui peut améliorer les performances. Les types d'énumération offrent cette garantie.

Pour résumer, les arguments pour utiliser ==on enumsont:

• Ça marche.
• C'est plus rapide.
• C'est plus sûr à l'exécution.
• C'est plus sûr au moment de la compilation.

Utiliser ==pour comparer deux valeurs d'énumération fonctionne, car il n'y a qu'un seul objet pour chaque constante d'énumération.

Sur une note latérale, il n'est en fait pas nécessaire d'utiliser ==pour écrire du code null-safe, si vous écrivez votre equals()comme ceci:

public useEnums(final SomeEnum a) {
    if (SomeEnum.SOME_ENUM_VALUE.equals(a)) {
        …
    }
    …
}

Il s'agit d'une meilleure pratique connue sous le nom de comparaison des constantes de gauche que vous devez absolument suivre.

Comme d' autres l' ont dit, à la fois ==et le .equals()travail dans la plupart des cas. La certitude de temps de compilation que vous ne comparez pas des types d'objets complètement différents que d'autres ont signalés est valide et bénéfique, mais le type particulier de bogue de comparaison d'objets de deux types de temps de compilation différents serait également trouvé par FindBugs (et probablement par Inspections de temps de compilation Eclipse / IntelliJ), donc le compilateur Java qui le trouve n'ajoute pas beaucoup de sécurité supplémentaire.

Toutefois:

1. Le fait que ==jette jamais NPE dans mon esprit est un inconvénient de ==. Il ne devrait presque jamais y avoir besoin de enumtypes null, car tout état supplémentaire que vous souhaitez exprimer via nullpeut simplement être ajouté à l' enuminstance supplémentaire. Si cela se produit de manière inattendue null, je préfère avoir un NPE que d' ==évaluer silencieusement à faux. Par conséquent, je ne suis pas d'accord avec l' opinion qu'il est plus sûr au moment de l'exécution ; il vaut mieux prendre l'habitude de ne jamais laisser de enumvaleurs @Nullable.
2. L'argument qui ==est plus rapide est également faux. Dans la plupart des cas, vous appellerez .equals()une variable dont le type de temps de compilation est la classe enum, et dans ces cas, le compilateur peut savoir que c'est la même chose que ==(car enumla equals()méthode d'un ne peut pas être remplacée) et peut optimiser l'appel de fonction un moyen. Je ne sais pas si le compilateur fait actuellement cela, mais si ce n'est pas le cas, et s'avère être un problème de performance dans Java dans l'ensemble, je préfère corriger le compilateur plutôt que 100 000 programmeurs Java modifient leur style de programmation en fonction de les caractéristiques de performance d'une version de compilateur particulière.
3. enumssont des objets. Pour tous les autres types d'objets, la comparaison standard ne l'est .equals()pas ==. Je pense qu'il est dangereux de faire une exception enumscar vous pourriez finir par comparer accidentellement des objets avec ==au lieu de equals(), surtout si vous refactorisez un enumen une classe non énumérée. Dans le cas d'une telle refactorisation, le point Ça marche d'en haut est faux. Pour vous convaincre qu'une utilisation de ==est correcte, vous devez vérifier si la valeur en question est une enumou une primitive; s'il s'agissait d'une non- enumclasse, ce serait faux mais facile à manquer car le code serait toujours compilé. Le seul cas où une utilisation de.equals()serait erroné si les valeurs en question étaient primitives; dans ce cas, le code ne serait pas compilé, il est donc beaucoup plus difficile à manquer. Par conséquent, il .equals()est beaucoup plus facile de l'identifier comme étant correct et il est plus sûr contre les remaniements futurs.

En fait, je pense que le langage Java aurait dû définir == sur les objets pour appeler .equals () sur la valeur de gauche, et introduire un opérateur distinct pour l'identité de l'objet, mais ce n'est pas ainsi que Java a été défini.

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

Je préfère utiliser ==plutôt que equals:

Une autre raison, en plus des autres déjà discutées ici, est que vous pourriez introduire un bogue sans vous en rendre compte. Supposons que vous ayez ces énumérations qui sont exactement les mêmes mais dans des pacakges séparés (ce n'est pas courant, mais cela pourrait arriver):

Première énumération :

package first.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Deuxième énumération:

package second.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Supposez ensuite que vous utilisez les égaux comme suivant dans item.categorylequel se trouve first.pckg.Categorymais que vous importez le deuxième enum ( second.pckg.Category) à la place du premier sans vous en rendre compte:

import second.pckg.Category;
...

Category.JAZZ.equals(item.getCategory())

Donc , vous obtiendrez AllWays à falsecause est un autre ENUM bien que vous attendez vrai parce que item.getCategory()est JAZZ. Et cela pourrait être un peu difficile à voir.

Donc, si vous utilisez plutôt l'opérateur, ==vous aurez une erreur de compilation:

L'opérateur == ne peut pas être appliqué à "second.pckg.Category", "first.pckg.Category"

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Voici un test de synchronisation brut 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());
    }   

}

Commentez les FI une par une. Voici les deux comparaisons ci-dessus en octet-code démonté:

 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

Le premier (égal) effectue un appel virtuel et teste le retour booléen de la pile. Le second (==) compare les adresses des objets directement à partir de la pile. Dans le premier cas, il y a plus d'activité.

J'ai effectué ce test plusieurs fois avec les deux FI, un à la fois. Le "==" est toujours un peu plus rapide.

En cas d'énumération, les deux sont corrects et corrects !!

tl; dr

Une autre option est la Objects.equalsméthode utilitaire.

Objects.equals( thisEnum , thatEnum )

Objects.equals pour une sécurité nulle

est égal à l'opérateur == au lieu de .equals ()

Quel opérateur dois-je utiliser?

Une troisième option est la equalsméthode statique trouvée sur la Objectsclasse d'utilitaires ajoutée à Java 7 et versions ultérieures.

Exemple

Voici un exemple utilisant l' Monthénumération.

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

Avantages

Je trouve quelques avantages à cette méthode:

• Sécurité nulle
  • Les deux null ➙ true
  • Soit nul ➙ false
  • Aucun risque de lancer NullPointerException
• Compact, lisible

Comment ça fonctionne

Quelle est la logique utilisée par Objects.equals?

Voyez par vous-même, à partir du code source Java 10 d' OpenJDK :

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

Utiliser autre chose que ==de comparer des constantes enum est un non-sens. C'est comme comparer des classobjets avecequals - ne le faites pas!

Cependant, il y avait un bogue désagréable (BugId 6277781 ) dans Sun JDK 6u10 et versions antérieures qui pouvait être intéressant pour des raisons historiques. Ce bogue a empêché une utilisation correcte de ==sur les énumérations désérialisées, bien qu'il s'agisse sans doute d'un cas d'angle.

Les énumérations sont des classes qui renvoient une instance (comme des singletons) pour chaque constante d'énumération déclarée par public static final field(immuable) afin que l' ==opérateur puisse être utilisé pour vérifier leur égalité plutôt que d'utiliser la equals()méthode

La raison pour laquelle les énumérations fonctionnent facilement avec == est que chaque instance définie est également un singleton. La comparaison d'identité à l'aide de == fonctionnera donc toujours.

Mais utiliser == parce qu'il fonctionne avec des énumérations signifie que tout votre code est étroitement associé à l'utilisation de cette énumération.

Par exemple: les énumérations peuvent implémenter une interface. Supposons que vous utilisez actuellement une énumération qui implémente Interface1. Si plus tard, quelqu'un la modifie ou introduit une nouvelle classe Impl1 en tant qu'implémentation de la même interface. Ensuite, si vous commencez à utiliser des instances d'Impl1, vous aurez beaucoup de code à modifier et à tester en raison de l'utilisation précédente de ==.

Par conséquent, il est préférable de suivre ce qui est considéré comme une bonne pratique, sauf s'il y a un gain justifiable.

L'une des règles du sondeur est Enum values should be compared with "==". Les raisons sont les suivantes:

Tester l'égalité d'une valeur d'énumération avec equals()est parfaitement valide car une énumération est un objet et chaque développeur Java sait ==qu'il ne doit pas être utilisé pour comparer le contenu d'un objet. En même temps, en utilisant ==sur les énumérations:

• fournit la même comparaison attendue (contenu) que equals()

• est plus sûr que nul equals()

• fournit une vérification à la compilation (statique) plutôt qu'une vérification à l'exécution

Pour ces raisons, l'utilisation de ==devrait être préférée à equals().

Enfin, ==on enums est sans doute plus lisible (moins verbeux) que equals().

Bref, les deux ont des avantages et des inconvénients.

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

D'un autre côté, si pour une raison quelconque, vous remplacez les énumérations par une approche différente (instances de classe normales), après avoir utilisé des ==morsures. (BTDT.)

Je veux compléter la réponse des polygénelubrifiants:

Personnellement, je préfère equals (). Mais c'est la vérification de compatibilité des types. Je pense que c'est une limitation importante.

Pour faire vérifier la compatibilité des types au moment de la compilation, déclarez et utilisez une fonction personnalisée dans votre énumération.

public boolean isEquals(enumVariable) // compare constant from left
public static boolean areEqual(enumVariable, enumVariable2) // compare two variable

Avec cela, vous avez tous les avantages des deux solutions: protection NPE, code facile à lire et vérification de la compatibilité des types au moment de la compilation.

Je recommande également d'ajouter une valeur UNDEFINED pour enum.