weixin_41568196
撒拉嘿哟木头
采纳率100%
2009-11-17 17:26

比较 Java enum 成员: 还是等于() ?

已采纳

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?

转载于:https://stackoverflow.com/questions/1750435/comparing-java-enum-members-or-equals

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

15条回答

  • weixin_41568126 乱世@小熊 12年前

    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.

    点赞 26 评论 复制链接分享
  • weixin_41568208 北城已荒凉 11年前

    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.
    点赞 29 评论 复制链接分享
  • weixin_41568208 北城已荒凉 10年前

    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<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());
        }   
    
    }
    

    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.

    点赞 10 评论 复制链接分享
  • weixin_41568134 MAO-EYE 4年前

    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() 
    
    点赞 9 评论 复制链接分享
  • csdnceshi73 喵-见缝插针 4年前

    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.

    点赞 9 评论 复制链接分享
  • csdnceshi54 hurriedly% 8年前

    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:

    1. 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.
    2. 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.
    3. 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.

    点赞 7 评论 复制链接分享
  • weixin_41568208 北城已荒凉 12年前

    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(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.

    点赞 6 评论 复制链接分享
  • weixin_41568110 七度&光 3年前

    tl;dr

    Another option is the Objects.equals utility method.

    Objects.equals( thisEnum , thatEnum )
    

    Objects.equals

    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
    • 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 && a.equals(b));
    
    点赞 5 评论 复制链接分享
  • weixin_41568184 叼花硬汉 6年前

    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.

    点赞 3 评论 复制链接分享
  • csdnceshi51 旧行李 4年前

    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.)

    点赞 3 评论 复制链接分享
  • csdnceshi71 Memor.の 12年前

    In case of enum both are correct and right!!

    点赞 1 评论 复制链接分享
  • csdnceshi65 larry*wei 6年前

    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

    点赞 1 评论 复制链接分享
  • csdnceshi75 衫裤跑路 3年前

    Enum in the middle is a set of constant integers. "==" is just as valid and proper as if you compared two integers.

    点赞 评论 复制链接分享
  • csdnceshi80 胖鸭 9年前

    I would like to explicitly highlight this specific difference between the == operator and equals() method:

    The equals() method is meant to check whether the contents of the object(s) the reference variable(s) involved refer(s) to are the same.

    The == operator checks whether the reference variable(s) involved refer(s) to the same object.

    It's up to the implementing class to provide this differentiation as needed by the application.

    Otherwise the default behavior will be as provided by the Object class (in Java) where as explained in http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#equals(java.lang.Object):

    The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).

    点赞 评论 复制链接分享
  • csdnceshi59 ℙℕℤℝ 7年前

    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.

    点赞 评论 复制链接分享