Comparing Java enum members or equals

Question

I know that Java enums are compiled to classes with private constructors and a bunch of public static members  When comparing two members of a given enum  I ve always used  equals    e g   public useEnums SomeEnum a        if a equals SomeEnum SOME ENUM VALUE                                       However  I just came across some code that uses the equals operator    instead of  equals     public useEnums2 SomeEnum a        if a    SomeEnum SOME ENUM VALUE                                      Which operator is the one I should be using

User · Answer

One of the Sonar rules is Enum values should be compared with  quot    quot   The reasons are as follows   Testing equality of an enum value with equals   is perfectly valid because an enum is an Object and every Java developer knows    should not be used to compare the content of an Object  At the same time  using    on enums   provides the same expected comparison  content  as equals    is more null-safe than equals    provides compile-time  static  checking rather than runtime checking   For these reasons  use of    should be preferred to equals     Last but not least  the    on enums is arguably more readable  less verbose  than equals

User · Answer

The reason enums work easily with    is because each defined instance is also a singleton  So identity comparison using    will always work   But using    because it works with enums means all your code is tightly coupled with usage of that enum    For example  Enums can implement an interface  Suppose you are currently using an enum which implements Interface1  If later on  someone changes it or introduces a new class Impl1 as an implementation of same interface  Then  if you start using instances of Impl1  you ll have a lot of code to change and test because of previous usage of       Hence  it s best to follow what is deemed a good practice unless there is any justifiable gain

User · Answer

I want to complement polygenelubricants answer   I personally prefer equals    But it lake the type compatibility check  Which I think is an important limitation   To have type compatibility check at compilation time  declare and use a custom function in your enum   public boolean isEquals enumVariable     compare constant from left public static boolean areEqual enumVariable  enumVariable2     compare two variable   With this  you got all the advantage of both solution  NPE protection  easy to read code and type compatibility check at compilation time   I also recommend to add an UNDEFINED value for enum

User · Answer

I prefer to use    instead of equals   Other reason  in addition to the others already discussed here  is you could introduce a bug without realizing it  Suppose you have this enums which is exactly the same but in separated pacakges  it s not common  but it could happen    First enum   package first pckg  public enum Category       JAZZ      ROCK      POP      POP ROCK     Second enum   package second pckg  public enum Category       JAZZ      ROCK      POP      POP ROCK     Then suppose you use the equals like next in item category which is first pckg Category but you import the second enum  second pckg Category  instead the first without realizing it   import second pckg Category       Category JAZZ equals item getCategory      So you will get allways false due is a different enum although you expect true because item getCategory   is JAZZ  And it could be be a bit difficult to see   So  if you instead use the operator    you will have a compilation error      operator    cannot be applied to  second pckg Category    first pckg Category    import second pckg Category        Category JAZZ    item getCategory

User · Answer

Using    to compare two enum values works  because there is only one object for each enum constant   On a side note  there is actually no need to use    to write null-safe code  if you write your equals   like this   public useEnums final SomeEnum a        if  SomeEnum SOME ENUM VALUE equals a                                   This is a best practice known as Compare Constants From The Left that you definitely should follow

User · Answer

In case of enum both are correct and right

User · Answer

Can    be used on enum  Yes  enums have tight instance controls that allows you to use    to compare instances  Here s the guarantee provided by the language specification  emphasis by me    JLS 8 9 Enums An enum type has no instances other than those defined by its enum constants  It is a compile-time error to attempt to explicitly instantiate an enum type  The final clone method in Enum ensures that enum constants can never be cloned  and the special treatment by the serialization mechanism ensures that duplicate instances are never created as a result of deserialization  Reflective instantiation of enum types is prohibited  Together  these four things ensure that no instances of an enum type exist beyond those defined by the enum constants  Because there is only one instance of each enum constant  it is permissible to use the    operator in place of the equals method when comparing two object references if it is known that at least one of them refers to an enum constant   The equals method in Enum is a final method that merely invokes super equals on its argument and returns the result  thus performing an identity comparison    This guarantee is strong enough that Josh Bloch recommends  that if you insist on using the singleton pattern  the best way to implement it is to use a single-element enum  see  Effective Java 2nd Edition  Item 3  Enforce the singleton property with a private constructor or an enum type  also Thread safety in Singleton   What are the differences between    and equals  As a reminder  it needs to be said that generally     is NOT a viable alternative to equals  When it is  however  such as with enum   there are two important differences to consider     never throws NullPointerException enum Color   BLACK  WHITE     Color nothing   null  if  nothing    Color BLACK           runs fine if  nothing equals Color BLACK       throws NullPointerException     is subject to type compatibility check at compile time 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    Should    be used when applicable  Bloch specifically mentions that immutable classes that have proper control over their instances can guarantee to their clients that    is usable  enum is specifically mentioned to exemplify   Item 1  Consider static factory methods instead of constructors       it allows an immutable class to make the guarantee that no two equal instances exist  a equals b  if and only if a  b  If a class makes this guarantee  then its clients can use the    operator instead of the equals Object  method  which may result in improved performance  Enum types provide this guarantee   To summarize  the arguments for using    on enum are   It works  It s faster  It s safer at run-time  It s safer at compile-time

User · Answer

Enums are classes that return one instance  like singletons  for each enumeration constant declared by public static final field  immutable  so that    operator could be used to check their equality rather than using equals   method

User · Answer

In short  both have pros and cons   On one hand  it has advantages to use     as described in the other answers   On the other hand  if you for any reason replace the enums with a different approach  normal class instances   having used    bites you   BTDT

User · Answer

Here is a crude timing test to compare the two   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 lt 5   y                for int x 0 x lt 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                   Comment out the IFs one at a time  Here are the two compares from above in disassembled 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   The first  equals  performs a virtual call and tests the return boolean from the stack  The second      compares the object addresses directly from the stack  In the first case there is more activity   I ran this test several times with both IFs one at a time  The      is ever so slightly faster

User · Answer

As others have said  both    and  equals   work in most cases  The compile time certainty that you re not comparing completely different types of Objects that others have pointed out is valid and beneficial  however the particular kind of bug of comparing objects of two different compile time types would also be found by FindBugs  and probably by Eclipse IntelliJ compile time inspections   so the Java compiler finding it doesn t add that much extra safety   However    The fact that    never throws NPE in my mind is a disadvantage of     There should hardly ever be a need for enum types to be null  since any extra state that you may want to express via null can just be added to the enum as an additional instance  If it is unexpectedly null  I d rather have a NPE than    silently evaluating to false  Therefore I disagree with the it s safer at run-time opinion  it s better to get into the habit never to let enum values be  Nullable  The argument that    is faster is also bogus  In most cases you ll call  equals   on a variable whose compile time type is the enum class  and in those cases the compiler can know that this is the same as     because an enum s equals   method can not be overridden  and can optimize the function call away  I m not sure if the compiler currently does this  but if it doesn t  and turns out to be a performance problem in Java overall  then I d rather fix the compiler than have 100 000 Java programmers change their programming style to suit a particular compiler version s performance characteristics  enums are Objects  For all other Object types the standard comparison is  equals    not     I think it s dangerous to make an exception for enums because you might end up accidentally comparing Objects with    instead of equals    especially if you refactor an enum into a non-enum class  In case of such a refactoring  the It works point from above is wrong  To convince yourself that a use of    is correct  you need to check whether value in question is either an enum or a primitive  if it was a non-enum class  it d be wrong but easy to miss because the code would still compile  The only case when a use of  equals   would be wrong is if the values in question were primitives  in that case  the code wouldn t compile so it s much harder to miss  Hence   equals   is much easier to identify as correct  and is safer against future refactorings    I actually think that the Java language should have defined    on Objects to call  equals   on the left hand value  and introduce a separate operator for object identity  but that s not how Java was defined   In summary  I still think the arguments are in favor of using  equals   for enum types

User · Answer

Both are technically correct  If you look at the source code for  equals    it simply defers to      I use     however  as that will be null safe

User · Answer

tl dr  Another option is the Objects equals utility method   Objects equals  thisEnum   thatEnum     Objects equals for null-safety     equals operator    instead of  equals        Which operator is the one I should be using    A third option is the static equals method found on the Objects utility class added to Java 7 and later   Example  Here   s an example using the Month enum   boolean areEqual   Objects equals  Month FEBRUARY   Month JUNE         Returns  false     Benefits  I find a couple benefits to this method    Null-safety   Both null   true Either null   false No risk of throwing NullPointerException  Compact  readable   How it works  What is the logic used by Objects equals    See for yourself  from the Java 10 source code of OpenJDK   return  a    b      a    null  amp  amp  a equals b

User · Answer

Using anything other than    to compare enum constants is nonsense  It s like comparing class objects with equals     don t do it   However  there was a nasty bug  BugId 6277781  in Sun JDK 6u10 and earlier that might be interesting for historical reasons  This bug prevented proper use of    on deserialized enums  although this is arguably somewhat of a corner case

[java] Comparing Java enum members: == or equals()?

Examples related to java

Examples related to enums