Ich weiß, dass Java-Enums zu Klassen mit privaten Konstruktoren und einer Reihe öffentlicher statischer Mitglieder kompiliert werden. Beim Vergleich zweier Mitglieder einer bestimmten Aufzählung habe ich immer .equals()z

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

Ich bin jedoch gerade auf Code ==gestoßen , der den Operator equals anstelle von .equals () verwendet:

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

Welchen Operator sollte ich verwenden?

Beide sind technisch korrekt. Wenn Sie sich den Quellcode ansehen .equals(), wird er einfach aufgeschoben ==.

Ich benutze ==jedoch, da dies null sicher sein wird.

Kann ==verwendet werden enum?

Ja: Aufzählungen verfügen über strenge Instanzsteuerelemente, mit denen Sie ==Instanzen vergleichen können. Hier ist die Garantie der Sprachspezifikation (Hervorhebung von mir):

JLS 8.9 Enums

Ein Aufzählungstyp hat keine anderen Instanzen als die durch seine Aufzählungskonstanten definierten.

Es ist ein Fehler beim Kompilieren, wenn versucht wird, einen Aufzählungstyp explizit zu instanziieren. Die final cloneMethode in Enumstellt sicher, dass enumKonstanten niemals geklont werden können, und die spezielle Behandlung durch den Serialisierungsmechanismus stellt sicher, dass niemals doppelte Instanzen als Ergebnis der Deserialisierung erstellt werden. Die reflektierende Instanziierung von Aufzählungstypen ist verboten. Zusammen stellen diese vier Dinge sicher, dass keine Instanzen eines enumTyps existieren, die über die durch die enumKonstanten definierten hinausgehen .

Da es nur eine Instanz jeder enumKonstante gibt, ist es zulässig, den ==Operator anstelle der equalsMethode zu verwenden, wenn zwei Objektreferenzen verglichen werden, wenn bekannt ist, dass mindestens eine von ihnen auf eine enumKonstante verweist . (Die equalsMethode in Enumist eine finalMethode, die lediglich super.equalsihr Argument aufruft und das Ergebnis zurückgibt, wodurch ein Identitätsvergleich durchgeführt wird.)

Diese Garantie ist stark genug, die Josh Bloch empfiehlt. Wenn Sie darauf bestehen, das Singleton-Muster zu verwenden, können Sie es am besten implementieren, indem Sie ein einzelnes Element verwenden enum(siehe: Effektive Java 2nd Edition, Punkt 3: Erzwingen Sie die Singleton-Eigenschaft mit a privater Konstruktor oder ein Aufzählungstyp ; auch Thread-Sicherheit in Singleton )

Was sind die Unterschiede zwischen ==und equals?

Zur Erinnerung muss gesagt werden, dass dies im Allgemeinen ==KEINE Alternative ist equals. Wenn dies jedoch der Fall ist (z. B. bei enum), sind zwei wichtige Unterschiede zu berücksichtigen:

== wirft nie NullPointerException

enum Color { BLACK, WHITE };

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

== wird zur Kompilierungszeit einer Typpompatibilitätsprüfung unterzogen

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!

Sollte ==gegebenenfalls verwendet werden?

Bloch erwähnt ausdrücklich, dass unveränderliche Klassen, die die richtige Kontrolle über ihre Instanzen haben, ihren Kunden garantieren können, dass sie ==verwendbar sind. enumwird ausdrücklich als Beispiel erwähnt.

Punkt 1: Betrachten Sie statische Factory-Methoden anstelle von Konstruktoren

[...] es ermöglicht einer unveränderlichen Klasse, die Garantie zu geben, dass keine zwei gleichen Instanzen existieren: a.equals(b)genau dann, wenn a==b. Wenn eine Klasse diese Garantie übernimmt, können ihre Clients den ==Operator anstelle der equals(Object)Methode verwenden, was zu einer verbesserten Leistung führen kann. Aufzählungstypen bieten diese Garantie.

Zusammenfassend sind die Argumente für die Verwendung von ==on enum:

• Es klappt.
• Es ist schneller.
• Zur Laufzeit ist es sicherer.
• Beim Kompilieren ist es sicherer.

Das ==Vergleichen von zwei Aufzählungswerten funktioniert, da für jede Aufzählungskonstante nur ein Objekt vorhanden ist.

Nebenbei bemerkt, es ist eigentlich nicht nötig ==, null-sicheren Code zu schreiben, wenn Sie Ihren folgenden Code schreiben equals():

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

Dies ist eine bewährte Methode, die als Konstanten von links vergleichen bekannt ist und die Sie unbedingt befolgen sollten.

Wie andere gesagt haben, funktionieren beide ==und .equals()in den meisten Fällen. Die Gewissheit über die Kompilierungszeit, dass Sie keine völlig unterschiedlichen Objekttypen vergleichen, auf die andere hingewiesen haben, ist gültig und vorteilhaft. Die besondere Art des Fehlers beim Vergleichen von Objekten mit zwei verschiedenen Kompilierungszeittypen wird jedoch auch von FindBugs (und wahrscheinlich auch von) gefunden Eclipse / IntelliJ-Inspektionen zur Kompilierungszeit), sodass der Java-Compiler, der dies feststellt, nicht so viel zusätzliche Sicherheit bietet.

Jedoch:

1. Die Tatsache, dass ==ich nie an NPE denke, ist ein Nachteil von ==. Es sollte kaum jemals eine Notwendigkeit für enumTypen geben null, da jeder zusätzliche Status, über den Sie möglicherweise ausdrücken möchten, nulleinfach enumals zusätzliche Instanz zu hinzugefügt werden kann . Wenn es unerwartet ist null, hätte ich lieber eine NPE als ==stillschweigend falsch zu bewerten. Daher bin ich nicht der Meinung, dass es zur Laufzeit sicherer ist . Es ist besser, sich daran zu gewöhnen, niemals enumWerte sein zu lassen @Nullable.
2. Das Argument, ==das schneller ist, ist auch falsch. In den meisten Fällen rufen Sie .equals()eine Variable auf, deren Kompilierungszeittyp die Enum-Klasse ist, und in diesen Fällen kann der Compiler wissen, dass dies dasselbe ist wie ==(da enumdie equals()Methode von an nicht überschrieben werden kann) und den Funktionsaufruf optimieren Weg. Ich bin mir nicht sicher, ob der Compiler dies derzeit tut, aber wenn dies nicht der Fall ist und sich insgesamt als Leistungsproblem in Java herausstellt, würde ich den Compiler lieber reparieren, als 100.000 Java-Programmierer ihren Programmierstil entsprechend ändern zu lassen Leistungsmerkmale einer bestimmten Compilerversion.
3. enumssind Objekte. Für alle anderen Objekttypen ist der Standardvergleich .equals()nicht ==. Ich denke, es ist gefährlich, eine Ausnahme zu machen, enumsweil Sie möglicherweise versehentlich Objekte mit ==anstatt vergleichen equals(), insbesondere wenn Sie eine enumin eine Nicht-Enum-Klasse umgestalten . Im Falle eines solchen Refactorings ist der Punkt Es funktioniert von oben falsch. Um sich davon zu überzeugen, dass eine Verwendung von ==korrekt ist, müssen Sie prüfen, ob der betreffende Wert entweder ein enumoder ein Grundelement ist. Wenn es keine enumKlasse wäre, wäre es falsch, aber leicht zu übersehen, da der Code immer noch kompiliert würde. Der einzige Fall, wenn eine Verwendung von.equals()wäre falsch, wenn die fraglichen Werte primitiv wären; In diesem Fall würde der Code nicht kompiliert, sodass es viel schwieriger ist, ihn zu übersehen. Daher .equals()ist es viel einfacher, als korrekt zu identifizieren, und es ist sicherer gegen zukünftige Refactorings.

Ich denke tatsächlich, dass die Java-Sprache == für Objekte definiert haben sollte, um .equals () auf der linken Seite aufzurufen und einen separaten Operator für die Objektidentität einzuführen, aber so wurde Java nicht definiert.

Zusammenfassend denke ich immer noch, dass die Argumente für die Verwendung .equals()für enumTypen sprechen .

Ich benutze lieber ==anstelle von equals:

Ein weiterer Grund, zusätzlich zu den anderen, die hier bereits besprochen wurden, ist, dass Sie einen Fehler einführen können, ohne es zu merken. Angenommen, Sie haben diese Aufzählung, die genau gleich ist, aber in getrennten Paketen (es ist nicht üblich, aber es könnte passieren):

Erste Aufzählung :

package first.pckg

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

Zweite Aufzählung:

package second.pckg

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

Nehmen wir dann an, Sie verwenden die Gleichheit wie item.categoryfolgt, first.pckg.Categoryaber Sie importieren die zweite Aufzählung ( second.pckg.Category) anstelle der ersten, ohne es zu merken:

import second.pckg.Category;
...

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

So werden Sie immer falsefällig, ist eine andere Aufzählung, obwohl Sie wahr erwarten, weil item.getCategory()ist JAZZ. Und es könnte etwas schwierig zu sehen sein.

Wenn Sie stattdessen den Operator verwenden ==, wird ein Kompilierungsfehler angezeigt:

operator == kann nicht auf "second.pckg.Category", "first.pckg.Category" angewendet werden.

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Hier ist ein grober Timing-Test, um die beiden zu vergleichen:

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

}

Kommentieren Sie die IFs einzeln aus. Hier sind die beiden Vergleiche von oben in zerlegtem Bytecode:

 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

Der erste (gleich) führt einen virtuellen Aufruf aus und testet den Rückgabewert vom Stack. Das zweite (==) vergleicht die Objektadressen direkt vom Stapel. Im ersten Fall gibt es mehr Aktivität.

Ich habe diesen Test mehrmals mit beiden IFs nacheinander durchgeführt. Das "==" ist etwas schneller.

Im Falle einer Aufzählung sind beide richtig und richtig !!

tl; dr

Eine weitere Option ist die Objects.equalsDienstprogrammmethode.

Objects.equals( thisEnum , thatEnum )

Objects.equals für Null-Sicherheit

gleich operator == anstelle von .equals ()

Welchen Operator sollte ich verwenden?

Eine dritte Option ist die statische equalsMethode für die ObjectsDienstprogrammklasse , die Java 7 und höher hinzugefügt wurde .

Beispiel

Hier ist ein Beispiel mit der MonthAufzählung.

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

Leistungen

Ich finde ein paar Vorteile für diese Methode:

• Null-Sicherheit
  • Beide null ➙ true
  • Entweder null ➙ false
  • Keine Gefahr zu werfen NullPointerException
• Kompakt, lesbar

Wie es funktioniert

Welche Logik wird verwendet Objects.equals?

Überzeugen Sie sich selbst vom Java 10-Quellcode von OpenJDK :

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

Es ==ist Unsinn, etwas anderes zu verwenden, als Enum-Konstanten zu vergleichen. Es ist wie ein Vergleich von classObjekten mitequals - tu es nicht!

Es gab jedoch einen bösen Fehler (BugId 6277781 ) in Sun JDK 6u10 und früher, der aus historischen Gründen interessant sein könnte. Dieser Fehler verhinderte die ordnungsgemäße Verwendung ==bei deserialisierten Aufzählungen, obwohl dies wohl eher ein Eckfall ist.

Aufzählungen sind Klassen, die eine Instanz (wie Singletons) für jede von public static final field(unveränderlich) deklarierte Aufzählungskonstante zurückgeben, sodass der ==Operator verwendet werden kann, um ihre Gleichheit zu überprüfen, anstatt eine equals()Methode zu verwenden

Der Grund, warum Aufzählungen mit == problemlos funktionieren, liegt darin, dass jede definierte Instanz auch ein Singleton ist. Der Identitätsvergleich mit == funktioniert also immer.

Wenn Sie jedoch == verwenden, weil es mit Aufzählungen funktioniert, ist Ihr gesamter Code eng mit der Verwendung dieser Aufzählung verbunden.

Zum Beispiel: Enums können eine Schnittstelle implementieren. Angenommen, Sie verwenden derzeit eine Aufzählung, die Interface1 implementiert. Wenn es später jemand ändert oder eine neue Klasse Impl1 als Implementierung derselben Schnittstelle einführt. Wenn Sie dann anfangen, Instanzen von Impl1 zu verwenden, müssen Sie aufgrund der vorherigen Verwendung von == viel Code ändern und testen.

Daher ist es am besten, eine bewährte Methode zu befolgen, es sei denn, es gibt einen vertretbaren Gewinn.

Eine der Sonarregeln ist Enum values should be compared with "==". Die Gründe sind folgende:

Das Testen der Gleichheit eines Aufzählungswerts mit equals()ist absolut gültig, da eine Aufzählung ein Objekt ist und jeder Java-Entwickler weiß, ==dass sie nicht zum Vergleichen des Inhalts eines Objekts verwendet werden sollte. Zur gleichen Zeit mit ==Aufzählungen:

• bietet den gleichen erwarteten Vergleich (Inhalt) wie equals()

• ist null-sicherer als equals()

• Bietet eher eine (statische) Überprüfung zur Kompilierungszeit als eine Laufzeitprüfung

Aus diesen Gründen sollte die Verwendung von ==bevorzugt werden equals().

Last but not least ist die ==on-Aufzählung wohl besser lesbar (weniger ausführlich) als equals().

Kurz gesagt, beide haben Vor- und Nachteile.

Einerseits hat es Vorteile ==, wie in den anderen Antworten beschrieben.

Wenn Sie jedoch aus irgendeinem Grund die Aufzählungen durch einen anderen Ansatz ersetzen (normale Klasseninstanzen), haben ==Sie Bisse verwendet. (BTDT.)

Ich möchte Polygenschmierstoffe ergänzen Antwort:

Ich persönlich bevorzuge equals (). Aber es gibt die Typpompatibilitätsprüfung. Was ich für eine wichtige Einschränkung halte.

Deklarieren und verwenden Sie eine benutzerdefinierte Funktion in Ihrer Enumeration, um die Typkompatibilität zur Kompilierungszeit zu überprüfen.

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

Damit haben Sie alle Vorteile beider Lösungen: NPE-Schutz, einfach zu lesender Code und Typpompatibilitätsprüfung zur Kompilierungszeit.

Ich empfehle auch, einen UNDEFINED-Wert für enum hinzuzufügen.

==kann werfen, NullPointerExceptionwenn ein primitiver Typ mit seiner Klassenversion verglichen wird. Zum Beispiel:

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