Sé que las enumeraciones de Java se compilan en clases con constructores privados y un grupo de miembros estáticos públicos. Al comparar dos miembros de una enumeración dada, siempre he usado .equals(), por ejemplo

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

Sin embargo, acabo de encontrar un código que usa el operador igual en ==lugar de .equals ():

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

¿Qué operador es el que debería usar?

Ambas son técnicamente correctas. Si observa el código fuente .equals(), simplemente difiere ==.

Lo uso ==, sin embargo, ya que será nulo seguro.

Se ==puede utilizar en enum?

Sí: las enumeraciones tienen controles de instancia ajustados que le permiten usar ==para comparar instancias. Aquí está la garantía proporcionada por la especificación del idioma (énfasis por mí):

JLS 8.9 Enums

Un tipo de enumeración no tiene instancias distintas de las definidas por sus constantes de enumeración.

Es un error en tiempo de compilación intentar crear una instancia explícita de un tipo de enumeración. El final clonemétodo Enumasegura que las enumconstantes nunca se puedan clonar, y el tratamiento especial por el mecanismo de serialización asegura que nunca se creen instancias duplicadas como resultado de la deserialización. Se prohíbe la creación de instancias reflexivas de tipos de enumeración. Juntas, estas cuatro cosas aseguran que no existan instancias de un enumtipo más allá de las definidas por las enumconstantes.

Debido a que solo hay una instancia de cada enumconstante, está permitido usar el ==operador en lugar del equalsmétodo al comparar dos referencias de objeto si se sabe que al menos una de ellas se refiere a una enumconstante . (El equalsmétodo en Enumes un finalmétodo que simplemente invoca super.equalssu argumento y devuelve el resultado, realizando así una comparación de identidad).

Esta garantía es lo suficientemente sólida como para que Josh Bloch recomiende que, si insiste en usar el patrón singleton, la mejor manera de implementarlo es usar un elemento único enum(consulte: Java 2nd Edition, elemento 3: aplicar la propiedad singleton con un constructor privado o un tipo de enumeración ; también seguridad de subprocesos en Singleton )

¿Cuáles son las diferencias entre ==y equals?

Como recordatorio, hay que decir que, en general, ==NO es una alternativa viable para equals. Sin embargo, cuando es así (como con enum), hay dos diferencias importantes a considerar:

== nunca tira NullPointerException

enum Color { BLACK, WHITE };

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

== está sujeto a verificación de compatibilidad de tipos en tiempo de compilación

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!

¿Debe ==usarse cuando corresponda?

Bloch menciona específicamente que las clases inmutables que tienen un control adecuado sobre sus instancias pueden garantizar a sus clientes que ==es utilizable. enumse menciona específicamente para ejemplificar.

Elemento 1: Considere métodos de fábrica estáticos en lugar de constructores

[...] permite que una clase inmutable garantice que no existen dos instancias iguales: a.equals(b)si y solo si a==b. Si una clase hace esta garantía, sus clientes pueden usar el ==operador en lugar del equals(Object)método, lo que puede mejorar el rendimiento. Los tipos de enumeración proporcionan esta garantía.

Para resumir, los argumentos para usar ==en enumson:

• Funciona.
• Es mas rapido.
• Es más seguro en tiempo de ejecución.
• Es más seguro en tiempo de compilación.

Usar ==para comparar dos valores de enumeración funciona, porque solo hay un objeto para cada constante de enumeración.

En una nota al margen, en realidad no hay necesidad de usar ==para escribir código nulo-seguro, si escribe equals()así:

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

Esta es una práctica recomendada conocida como Comparar constantes desde la izquierda que definitivamente debes seguir.

Como han dicho otros, tanto ==y .equals()de trabajo en la mayoría de los casos. La certeza de tiempo de compilación de que no está comparando tipos completamente diferentes de Objetos que otros han señalado es válida y beneficiosa, sin embargo, FindBugs también encontraría el tipo particular de error de comparar objetos de dos tipos de tiempo de compilación diferentes (y probablemente por Eclipse / IntelliJ inspecciones de tiempo de compilación), por lo que el compilador de Java al encontrarlo no agrega tanta seguridad adicional.

Sin embargo:

1. El hecho de que ==nunca tira NPE en mi mente es una desventaja de ==. Casi nunca debería existir la necesidad de enumque nullexistan tipos , ya que cualquier estado adicional que desee expresar a través de él nullpuede agregarse enumcomo una instancia adicional. Si es inesperado null, prefiero tener un NPE que ==evaluar en silencio a falso. Por lo tanto, no estoy de acuerdo con la opinión más segura en tiempo de ejecución ; es mejor acostumbrarse a nunca dejar que los enumvalores sean @Nullable.
2. El argumento que ==es más rápido también es falso. En la mayoría de los casos se le llama .equals()en una variable cuyo tipo de tiempo de compilación es la clase de enumeración, y en esos casos el compilador puede saber que esto es lo mismo que ==(debido a una enum's equals()método no puede ser anulado) y se puede optimizar la función de llamada lejos. No estoy seguro de si el compilador actualmente hace esto, pero si no lo hace, y resulta ser un problema de rendimiento en Java en general, prefiero arreglar el compilador antes de que 100,000 programadores de Java cambien su estilo de programación para adaptarse características de rendimiento de una versión de compilador particular.
3. enumsson objetos Para todos los demás tipos de Objetos, la comparación estándar es .equals(), no ==. Creo que es peligroso hacer una excepción enumsporque podría terminar comparando accidentalmente objetos con en ==lugar de equals(), especialmente si refactoriza una enumclase que no es enum. En caso de tal refactorización, el punto Funciona desde arriba es incorrecto. Para convencerse de que el uso de ==es correcto, debe verificar si el valor en cuestión es enumprimitivo o no; si no fuera de enumclase, sería incorrecto pero fácil de perder porque el código aún se compilaría. El único caso cuando un uso de.equals()estaría mal si los valores en cuestión fueran primitivos; en ese caso, el código no se compilaría, por lo que es mucho más difícil pasarlo por alto. Por lo tanto, .equals()es mucho más fácil de identificar como correcto y es más seguro contra futuras refactorizaciones.

De hecho, creo que el lenguaje Java debería haber definido == en Objetos para llamar a .equals () en el valor de la izquierda e introducir un operador separado para la identidad del objeto, pero no es así como se definió Java.

En resumen, sigo pensando que los argumentos están a favor del uso .equals()de enumtipos.

Prefiero usar en ==lugar de equals:

Otra razón, además de las otras ya discutidas aquí, es que podría introducir un error sin darse cuenta. Supongamos que tiene estas enumeraciones que son exactamente iguales pero en paquetes separados (no es común, pero podría suceder):

Primera enumeración :

package first.pckg

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

Segunda enumeración:

package second.pckg

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

Luego, suponga que usa los iguales como next en el item.categoryque está first.pckg.Categorypero importa el segundo enum ( second.pckg.Category) en lugar del primero sin darse cuenta:

import second.pckg.Category;
...

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

Así que siempre obtendrás falseuna enumeración diferente, aunque esperas cierto porqueitem.getCategory() es así JAZZ. Y podría ser un poco difícil de ver.

Entonces, si en su lugar usa el operador == , tendrá un error de compilación:

El operador == no se puede aplicar a "second.pckg.Category", "first.pckg.Category"

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Aquí hay una prueba cruda de tiempo para comparar los dos:

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

}

Comente los IF uno por uno. Aquí están las dos comparaciones de arriba en código de byte desmontado:

 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

El primero (igual) realiza una llamada virtual y prueba el valor booleano de retorno de la pila. El segundo (==) compara las direcciones de los objetos directamente desde la pila. En el primer caso hay más actividad.

Ejecuté esta prueba varias veces con ambos IF uno a la vez. El "==" es un poco más rápido.

¡En caso de enumeración, ambos son correctos y correctos!

tl; dr

Otra opción es el Objects.equalsmétodo de utilidad.

Objects.equals( thisEnum , thatEnum )

Objects.equals para seguridad nula

operador igual == en lugar de .equals ()

¿Qué operador es el que debería usar?

Una tercera opción es el equalsmétodo estático que se encuentra en la Objectsclase de utilidad agregada a Java 7 y versiones posteriores.

Ejemplo

Aquí hay un ejemplo usando la Monthenumeración.

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

Beneficios

Encuentro un par de beneficios para este método:

• Seguridad nula
  • Ambos nulos ➙ true
  • O nulo ➙ false
  • No hay riesgo de tirar NullPointerException
• Compacto, legible

Cómo funciona

¿Cuál es la lógica utilizada por Objects.equals?

Véalo usted mismo, del código fuente de Java 10 de OpenJDK :

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

Usar cualquier otra cosa que no sea ==comparar constantes enum no tiene sentido. Es como comparar classobjetos conequals , ¡no lo hagas!

Sin embargo, hubo un error desagradable (BugId 6277781 ) en Sun JDK 6u10 y anteriores que podría ser interesante por razones históricas. Este error evitó el uso adecuado de las ==enumeraciones deserializadas, aunque esto podría decirse que es un caso de esquina.

Las enumeraciones son clases que devuelven una instancia (como singletons) para cada constante de enumeración declarada por public static final field(inmutable) para que el ==operador pueda usarse para verificar su igualdad en lugar de usar el equals()método

La razón por la que las enumeraciones funcionan fácilmente con == es porque cada instancia definida también es un singleton. Entonces la comparación de identidad usando == siempre funcionará.

Pero usar == porque funciona con enumeraciones significa que todo su código está estrechamente relacionado con el uso de esa enumeración.

Por ejemplo: las enumeraciones pueden implementar una interfaz. Suponga que actualmente está utilizando una enumeración que implementa Interface1. Si más adelante, alguien lo cambia o introduce una nueva clase Impl1 como implementación de la misma interfaz. Luego, si comienza a usar instancias de Impl1, tendrá mucho código para cambiar y probar debido al uso previo de ==.

Por lo tanto, es mejor seguir lo que se considera una buena práctica a menos que haya una ganancia justificable.

Una de las reglas de Sonar es Enum values should be compared with "==". Las razones son las siguientes:

Probar la igualdad de un valor de enumeración con equals()es perfectamente válido porque una enumeración es un Objeto y todo desarrollador Java sabe ==que no debe usarse para comparar el contenido de un Objeto. Al mismo tiempo, usando ==en enumeraciones:

• proporciona la misma comparación esperada (contenido) que equals()

• es más nulo seguro que equals()

• proporciona comprobación en tiempo de compilación (estática) en lugar de comprobación en tiempo de ejecución

Por estas razones, el uso de == debe preferir el uso de equals().

Por último, pero no menos importante, las ==enumeraciones on son posiblemente más legibles (menos detalladas) que equals().

En resumen, ambos tienen pros y contras.

Por un lado, tiene ventajas para usar == , como se describe en las otras respuestas.

Por otro lado, si por alguna razón reemplaza las enumeraciones con un enfoque diferente (instancias de clase normales), habiendo usado ==picaduras. (BTDT.)

Quiero complementar la respuesta de polygenelubricants:

Personalmente prefiero igual (). Pero tiene el control de compatibilidad de tipos. Lo cual creo que es una limitación importante.

Para comprobar la compatibilidad de tipos en el momento de la compilación, declare y use una función personalizada en su enumeración.

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

Con esto, tiene todas las ventajas de ambas soluciones: protección NPE, código fácil de leer y verificación de compatibilidad de tipos en el momento de la compilación.

También recomiendo agregar un valor INDEFINIDO para enum.