Я знаю, що перерахунки 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 Енуми

Тип enum не має інших випадків, ніж ті, які визначені його константами enum.

Це помилка часу компіляції для спроби явно інстанціювати тип enum. Цей final cloneметод Enumзабезпечує те, що enumконстанти ніколи не можуть бути клоновані, а спеціальне звернення за допомогою механізму серіалізації забезпечує те, що повторювані екземпляри ніколи не створюються в результаті десеріалізації. Відображаюча інсталяція типів перерахувань заборонена. Ці чотири речі разом забезпечують відсутність екземплярів enumтипу, що перевищують enumконстанти.

Оскільки існує лише один примірник кожної enumконстанти, допустимо використовувати ==оператор замість equalsметоду при порівнянні двох посилань на об'єкти, якщо відомо, що принаймні одна з них відноситься до enumконстанти . ( equalsМетод в Enum- це finalметод, який просто викликає super.equalsсвій аргумент і повертає результат, виконуючи таким чином порівняння ідентичності.)

Ця гарантія є достатньо сильною, що рекомендує Джош Блок: якщо ви наполягаєте на використанні однотонного шаблону, найкращим способом його реалізації є використання одноелемента enum(див .: Ефективне Java 2-е видання, Пункт 3: Застосування властивості одиночного з допомогою приватний конструктор або тип 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наступні:

• Це працює.
• Це швидше.
• Це безпечніше під час виконання.
• Це безпечніше під час компіляції.

Використання ==для порівняння двох значень 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, ніж ==мовчки оцінювати значення false. Тому я не погоджуюся з безпечнішою думкою під час виконання ; краще ввійти в звичку ніколи не допускати enumцінностей @Nullable.
2. Аргумент , що ==це швидше , також підроблений. У більшості випадків ви звертаєтесь .equals()до змінної, типом якої часу компіляції є перелік enum, і в цих випадках компілятор може знати, що це те саме, що ==(оскільки метод 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. І це може бути трохи важко помітити.

Отже, якщо ви замість цього використовуєте оператор, ==ви отримаєте помилку компіляції:

operator == не можна застосувати до "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

Перший (дорівнює) виконує віртуальний виклик і випробовує зворотний буль з стека. Другий (==) порівнює адреси об'єктів безпосередньо зі стека. У першому випадку активності більше.

Я кілька разів проводив цей тест з обома ІФ, по одному. "==" стає настільки дещо швидшим.

У випадку перерахунків обидва є правильними і правильними !!

тл; д-р

Інший варіант - Objects.equalsкорисний метод.

Objects.equals( thisEnum , thatEnum )

Objects.equals для забезпечення нульової безпеки

дорівнює оператору == замість .equals ()

Яким оператором я повинен користуватися?

Третій варіант - статичний equalsметод, знайдений у Objectsкласі утиліти, доданому до Java 7 та новіших версій.

Приклад

Ось приклад використання Monthenum.

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

Переваги

Я знаходжу пару переваг цього методу:

• Нульова безпека
  • Обидва нульові ➙ 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 "==". Причини такі:

Тестування рівності значення enum з equals()цілком справедливо, тому що enum є Об'єктом, і кожен відомий розробник Java не ==повинен використовуватися для порівняння вмісту Об'єкта. У той же час, використовуючи ==переліки:

• забезпечує таке ж очікуване порівняння (зміст), що і equals()

• є більш безпечним, ніж ніж equals()

• забезпечує перевірку часу компіляції (статичну), а не перевірку часу виконання

З цих причин ==слід віддати перевагу використанню equals().

І останнє , але не менш важливе , ==на перерахувань, можливо , більш зручним для читання (менш багатослівним) , ніж equals().

Коротше кажучи, у обох є плюси і мінуси.

З одного боку, він має переваги використання ==, як описано в інших відповідях.

З іншого боку, якщо ви з якихось причин заміните ентузіастів іншим підходом (нормальні екземпляри класу), використовуючи ==вас, кусає вас. (BTDT.)

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

Я особисто віддаю перевагу рівним (). Але це озеро перевірка сумісності типу. Я вважаю, що це важливе обмеження.

Щоб перевірити сумісність типів під час компіляції, оголосити та використовувати користувальницьку функцію у вашому переліку.

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

Завдяки цьому ви отримали всі переваги обох рішень: захист NPE, легкий для читання код і перевірку сумісності типу під час компіляції.

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

==може кинути, NullPointerExceptionякщо примітивний тип порівнюється з його версією Class. Наприклад:

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
    }
}