Я знаю, что перечисления Java скомпилированы в классы с частными конструкторами и несколькими открытыми статическими членами. При сравнении двух членов данного перечисления я всегда использовал .equals(), например,

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

Однако я только что натолкнулся на некоторый код, который использует оператор equals ==вместо .equals ():

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

Какой оператор мне следует использовать?

Оба технически правильны. Если вы посмотрите на исходный код для .equals(), он просто откладывает на ==.

Я использую ==, однако, поскольку это будет нуль-безопасным.

Может ==быть использован на enum?

Да: перечисления имеют жесткие элементы управления экземплярами, что позволяет использовать их ==для сравнения. Вот гарантия, предоставляемая спецификацией языка (выделено мной):

JLS 8.9 Enums

Тип enum не имеет экземпляров, отличных от определенных его константами.

Это ошибка времени компиляции, чтобы попытаться явно создать экземпляр типа enum. final cloneМетод Enumгарантирует , что enumконстанты никогда не могут быть клонированы, а специальная обработка с помощью механизма сериализации гарантирует , что дублирующие экземпляры никогда не созданные в результате десериализации. Рефлексивная реализация типов перечислений запрещена. Вместе эти четыре вещи гарантируют, что экземпляры enumтипа не существуют вне тех, которые определены enumконстантами.

Поскольку существует только один экземпляр каждой enumконстанты, допустимо использовать ==оператор вместо equalsметода при сравнении двух ссылок на объекты, если известно, что хотя бы одна из них ссылается на enumконстанту . ( equalsМетод in Enum- это finalметод, который просто вызывает super.equalsсвой аргумент и возвращает результат, тем самым выполняя сравнение идентификаторов.)

Эта гарантия достаточно сильна, и Джош Блох рекомендует, что, если вы настаиваете на использовании одноэлементного шаблона, лучший способ реализовать его - это использовать одноэлементный enum(см. Effective Java 2nd Edition, Item 3: Enforment свойство singleton с помощью частный конструктор или тип enum, а также потокобезопасность в Singleton )

Каковы различия между ==и equals?

Напоминаем, что нужно сказать, что в общем случае ==это НЕ жизнеспособная альтернатива equals. Однако, когда это так (например, с enum), есть два важных различия, которые следует учитывать:

== никогда не бросает NullPointerException

enum Color { BLACK, WHITE };

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

== подлежит проверке совместимости типов во время компиляции

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!

Следует ==ли использовать, когда это применимо?

Блох, в частности, упоминает, что неизменные классы, которые имеют надлежащий контроль над своими экземплярами, могут гарантировать своим клиентам, что они ==могут использоваться. enumспециально упоминается в качестве примера.

Пункт 1: Рассмотрим статические фабричные методы вместо конструкторов

[...] он позволяет неизменному классу гарантировать, что не существует двух одинаковых экземпляров: a.equals(b)тогда и только тогда, когда a==b. Если класс дает такую ​​гарантию, его клиенты могут использовать ==оператор вместо equals(Object)метода, что может привести к повышению производительности. Типы Enum предоставляют эту гарантию.

Подводя итог, аргументы для использования ==на enum:

• Оно работает.
• Это быстрее
• Это безопаснее во время выполнения.
• Это безопаснее во время компиляции.

Использование ==для сравнения двух значений перечисления работает, потому что для каждой константы перечисления существует только один объект.

Напомним, что на самом деле нет необходимости использовать ==для написания нулевого кода, если вы пишете equals()так:

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

Это лучшая практика, известная как сравнение констант слева, которой вы обязательно должны следовать.

Как уже говорили другие, оба ==и .equals()работают в большинстве случаев. Уверенность во время компиляции в том, что вы не сравниваете совершенно разные типы объектов, на которые указывали другие, является допустимой и полезной, однако конкретный вид ошибки сравнения объектов двух разных типов времени компиляции также будет найден FindBugs (и, вероятно, Eclipse / IntelliJ проверяет время компиляции), поэтому компилятор Java, обнаружив его, не добавляет такой дополнительной безопасности.

Однако:

1. Тот факт , что ==никогда не бросает NPE на мой взгляд , является недостатком в ==. Вряд ли когда-либо возникнет необходимость в enumтипах null, поскольку любое дополнительное состояние, которое вы можете выразить через, nullможет быть просто добавлено enumв качестве дополнительного экземпляра. Если это неожиданно null, я предпочел бы иметь NPE, чем ==молча оценивать как ложное. Поэтому я не согласен с более безопасным во время выполнения мнением; лучше привыкнуть никогда не оставлять enumценности @Nullable.
2. Аргумент , что ==это быстрее , также поддельный. В большинстве случаев вы будете звонить .equals()по переменной, компиляции времени тип является классом перечисления, а также в тех случаях , компилятор может знать , что это то же самое, ==(потому что enum«S equals()метод не может быть переопределен) и может оптимизировать вызов функции прочь. Я не уверен, что компилятор в настоящее время делает это, но если это не так, и это в целом вызывает проблемы с производительностью Java, то я бы скорее исправил компилятор, чем 100 000 Java-программистов изменили свой стиль программирования в соответствии с требованиями характеристики производительности конкретной версии компилятора.
3. enumsявляются объектами. Для всех других типов объектов стандартное сравнение - .equals()нет ==. Я думаю, что делать исключение опасно, enumsпотому что вы можете случайно сравнить объекты с объектами ==вместо equals(), особенно если вы enumпреобразуете класс в не перечислимый. В случае такого рефакторинга, пункт « Работает» сверху неверен. Чтобы убедить себя в том, что использование ==является правильным, вам нужно проверить, является ли рассматриваемое значение enumили примитивом; если бы это был не enumкласс, это было бы неправильно, но легко пропустить, потому что код все еще компилируется. Единственный случай, когда использование.equals()было бы неправильно, если бы эти значения были примитивами; в этом случае код не будет компилироваться, поэтому его будет гораздо сложнее пропустить. Следовательно, .equals()гораздо легче определить, как правильно, и безопаснее от будущих рефакторингов.

Я действительно думаю, что язык Java должен был определить == для объектов, чтобы вызвать .equals () для значения слева, и ввести отдельный оператор для идентификации объекта, но это не то, как Java была определена.

Таким образом, я все еще думаю, что аргументы в пользу использования .equals()для enumтипов.

Я предпочитаю использовать ==вместо equals:

Другая причина, в дополнение к другим, уже обсужденным здесь, состоит в том, что вы можете внести ошибку, не осознавая этого. Предположим, у вас есть эти перечисления, которые точно такие же, но в разделенных пакетах (это не часто, но это может произойти):

Первое перечисление :

package first.pckg

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

Второе перечисление:

package second.pckg

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

Затем предположим, что вы используете равенства, как в следующем item.category, first.pckg.Categoryно вы импортируете второй enum ( second.pckg.Category) вместо первого, не осознавая этого:

import second.pckg.Category;
...

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

Таким образом, вы всегда получите falseиз-за другого перечисления, хотя вы ожидаете, потому что item.getCategory()это правда JAZZ. И это может быть немного трудно увидеть.

Итак, если вы вместо этого используете оператор, у ==вас будет ошибка компиляции:

Оператор == не может быть применен к "second.pckg.Category", "first.pckg.Category"

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Вот грубый временной тест для сравнения двух:

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

}

Закомментируйте IFs по одному. Вот два сравнения сверху в разобранном байт-коде:

 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

Первый (равно) выполняет виртуальный вызов и проверяет возвращаемое логическое значение из стека. Второй (==) сравнивает адреса объектов непосредственно из стека. В первом случае больше активности.

Я провел этот тест несколько раз с обоими IF, по одному. «==» немного быстрее.

В случае enum оба являются правильными и правильными !!

ТЛ; др

Другим вариантом является Objects.equalsслужебный метод.

Objects.equals( thisEnum , thatEnum )

Objects.equals для нулевой безопасности

оператор равенства == вместо .equals ()

Какой оператор мне следует использовать?

Третий вариант - статический equalsметод, найденный в Objectsслужебном классе, добавленном в Java 7 и более поздние .

пример

Вот пример использования Monthenum.

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

Льготы

Я нахожу пару преимуществ для этого метода:

• Null-безопасности
  • Оба ноль ➙ true
  • Либо ноль ➙ false
  • Нет риска броска NullPointerException
• Компактный, читаемый

Как это работает

Какая логика используется Objects.equals ?

Смотрите сами, из исходного кода Java 10 из OpenJDK :

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

Использование чего-либо, кроме как ==для сравнения констант перечисления, - нонсенс. Это как сравнивать classобъектыequals - не делай этого!

Однако в Sun JDK 6u10 и более ранних версиях имелась неприятная ошибка (BugId 6277781 ), которая может быть интересной по историческим причинам. Эта ошибка не позволяла правильно использовать ==десериализованные перечисления, хотя это, возможно, в некотором роде случайный случай.

Перечисления - это классы, которые возвращают один экземпляр (например, одиночные) для каждой константы перечисления, объявленной public static final field (неизменяемой), так что ==оператор может использоваться для проверки их равенства вместо использования equals()метода.

Перечисления легко работают с ==, потому что каждый определенный экземпляр также является одиночным. Поэтому сравнение тождеств с использованием == всегда будет работать.

Но использование ==, потому что оно работает с перечислениями, означает, что весь ваш код тесно связан с использованием этого перечисления.

Например: Enums может реализовать интерфейс. Предположим, вы используете enum, который реализует интерфейс Interface1. Если позже кто-то изменит его или представит новый класс Impl1 как реализацию того же интерфейса. Затем, если вы начнете использовать экземпляры Impl1, у вас будет много кода для изменения и тестирования из-за предыдущего использования ==.

Следовательно, лучше всего следовать тому, что считается хорошей практикой, если нет какой-либо оправданной выгоды.

Одно из правил эхолота Enum values should be compared with "==". Причины следующие:

Проверка на равенство значения перечисления с equals()совершенно допустимо, потому что перечисление является объектом, и каждый Java-разработчик ==не должен использовать его для сравнения содержимого объекта. В то же время, используя ==перечисления:

• обеспечивает такое же ожидаемое сравнение (содержание), как equals()

• более нуль-безопасен, чем equals()

• обеспечивает проверку во время компиляции (статическую), а не проверку во время выполнения

По этим причинам использование ==должно быть предпочтительным equals().

Наконец, что не менее ==важно, перечисления могут быть более читабельными (менее подробными), чем equals().

Одним словом, у обоих есть плюсы и минусы.

С одной стороны, он имеет преимущества в использовании ==, как описано в других ответах.

С другой стороны, если вы по какой-либо причине замените перечисления другим подходом (обычные экземпляры классов), воспользовавшись ==укусами. (BTDT.)

Хочу дополнить ответом полигеномасла:

Я лично предпочитаю равно (). Но это проверка совместимости типов. Что я считаю важным ограничением.

Для проверки совместимости типов во время компиляции объявите и используйте пользовательскую функцию в вашем перечислении.

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

Благодаря этому вы получаете все преимущества обоих решений: защиту NPE, легкий для чтения код и проверку совместимости типов во время компиляции.

Я также рекомендую добавить значение UNDEFINED для enum.