Saya tahu bahwa enum Java dikompilasi ke kelas dengan konstruktor pribadi dan sekelompok anggota statis publik. Ketika membandingkan dua anggota enum yang diberikan, saya selalu menggunakan .equals(), misalnya

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

Namun, saya baru saja menemukan beberapa kode yang menggunakan operator sama dengan ==.equals ():

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

Operator mana yang harus saya gunakan?

Keduanya secara teknis benar. Jika Anda melihat kode sumbernya .equals(), itu hanya berlaku untuk ==.

Saya menggunakan ==, bagaimanapun, karena itu akan menjadi nol aman.

Apakah ==bisa digunakan enum?

Ya: enum memiliki kontrol instans ketat yang memungkinkan Anda gunakan ==untuk membandingkan instance. Inilah jaminan yang diberikan oleh spesifikasi bahasa (penekanan oleh saya):

JLS 8.9 Enum

Tipe enum tidak memiliki instance selain yang didefinisikan oleh konstanta enumnya.

Ini adalah kesalahan waktu kompilasi untuk mencoba secara eksplisit instantiate tipe enum. The final clonemetode dalam Enummemastikan bahwa enumkonstanta tidak pernah bisa dikloning, dan perlakuan khusus oleh memastikan mekanisme serialisasi yang duplikat contoh yang tidak pernah dibuat sebagai hasil dari deserialization. Instansiasi reflektif dari tipe enum dilarang. Bersama-sama, keempat hal ini memastikan bahwa tidak ada contoh enumjenis ada di luar yang ditentukan olehenum konstanta.

Karena hanya ada satu instance dari setiap enumkonstanta, diperbolehkan untuk menggunakan ==operator sebagai pengganti equalsmetode ketika membandingkan dua referensi objek jika diketahui bahwa setidaknya satu dari mereka mengacu pada enumkonstanta . ( equalsMetode dalam Enumadalah finalmetode yang hanya meminta super.equalsargumennya dan mengembalikan hasilnya, sehingga melakukan perbandingan identitas.)

Jaminan ini cukup kuat yang direkomendasikan Josh Bloch, bahwa jika Anda bersikeras menggunakan pola tunggal, cara terbaik untuk mengimplementasikannya adalah dengan menggunakan elemen tunggal enum(lihat: Java Efektif Edisi 2, Butir 3: Terapkan properti singleton dengan konstruktor pribadi atau tipe enum ; juga keamanan Thread di Singleton )

Apa perbedaan antara ==danequals ?

Sebagai pengingat, perlu dikatakan bahwa secara umum, ==BUKAN merupakan alternatif untuk equals. Ketika itu, bagaimanapun (seperti denganenum ), ada dua perbedaan penting yang perlu dipertimbangkan:

== tidak pernah melempar NullPointerException

enum Color { BLACK, WHITE };

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

== harus mengetik pemeriksaan kompatibilitas pada waktu kompilasi

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!

Sebaiknya == digunakan saat berlaku?

Bloch secara khusus menyebutkan bahwa kelas yang tidak dapat diubah yang memiliki kontrol yang tepat atas instance mereka dapat menjamin klien mereka ==dapat digunakan. enumsecara khusus disebutkan untuk dicontohkan.

Butir 1: Pertimbangkan metode pabrik statis daripada konstruktor

[...] ini memungkinkan kelas yang tidak dapat diubah untuk membuat jaminan bahwa tidak ada dua instance yang sama ada: a.equals(b)jika dan hanya jika a==b. Jika suatu kelas membuat jaminan ini, maka kliennya dapat menggunakan ==operator alih-alih equals(Object)metode, yang dapat menghasilkan peningkatan kinerja. Jenis Enum memberikan jaminan ini.

Untuk meringkas, argumen untuk digunakan ==pada enumadalah:

• Berhasil.
• Lebih cepat.
• Lebih aman saat dijalankan.
• Lebih aman saat kompilasi.

Menggunakan == untuk membandingkan dua nilai enum bekerja, karena hanya ada satu objek untuk setiap konstanta enum.

Di samping catatan, sebenarnya tidak perlu menggunakan ==untuk menulis kode null-safe, jika Anda menulis equals()seperti ini:

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

Ini adalah praktik terbaik yang dikenal sebagai Bandingkan Konstanta Dari Kiri yang harus Anda ikuti.

Seperti yang orang lain katakan, keduanya ==dan.equals() bekerja dalam kebanyakan kasus. Kepastian waktu kompilasi bahwa Anda tidak membandingkan jenis Objek yang sama sekali berbeda yang orang lain tunjukkan adalah valid dan bermanfaat, namun jenis bug tertentu membandingkan objek dari dua jenis waktu kompilasi yang berbeda juga akan ditemukan oleh FindBugs (dan mungkin oleh Eclipse / IntelliJ mengkompilasi waktu inspeksi), sehingga Java compiler menemukannya tidak menambah banyak keamanan ekstra.

Namun:

1. Fakta bahwa ==tidak pernah melempar NPE dalam pikiran saya adalah kelemahan dari ==. Seharusnya hampir tidak pernah ada kebutuhan untuk enumjenis null, karena setiap keadaan tambahan yang Anda mungkin ingin ungkapkan via nullhanya dapat ditambahkan enumsebagai contoh tambahan. Jika tidak terduga null, saya lebih suka memiliki NPE daripada ==diam - diam mengevaluasi ke false. Oleh karena itu saya tidak setuju dengan itu lebih aman di opini run-time ; lebih baik untuk membiasakan diri untuk tidak membiarkan enumnilai-nilai itu terjadi @Nullable.
2. Argumen bahwa ==adalah lebih cepat juga palsu. Dalam kebanyakan kasus, Anda akan menelepon .equals()pada variabel yang tipe waktu kompilasi adalah kelas enum, dan dalam kasus-kasus compiler dapat tahu bahwa ini adalah sama dengan ==(karena seorang enum's equals()metode tidak bisa ditimpa) dan dapat mengoptimalkan fungsi panggilan jauh. Saya tidak yakin apakah kompiler saat ini melakukan ini, tetapi jika tidak, dan ternyata menjadi masalah kinerja di Jawa secara keseluruhan, maka saya lebih suka memperbaiki kompiler daripada memiliki 100.000 programmer Java mengubah gaya pemrograman mereka sesuai karakteristik kinerja versi kompiler tertentu.
3. enumsadalah Objects. Untuk semua jenis Objek lainnya, perbandingan standarnya adalah .equals(), bukan ==. Saya pikir itu berbahaya untuk membuat pengecualian enumskarena Anda mungkin akhirnya secara tidak sengaja membandingkan Objek dengan, ==bukan equals(), terutama jika Anda mereformasi suatu enumke dalam kelas non-enum. Dalam hal refactoring seperti itu, titik kerjanya dari atas salah. Untuk meyakinkan diri sendiri bahwa penggunaan kata ==benar, Anda perlu memeriksa apakah nilai yang dipermasalahkan adalah enumprimitif; jika itu bukan enumkelas, itu akan salah tetapi mudah dilewatkan karena kode masih akan dikompilasi. Satu-satunya kasus ketika penggunaan.equals()yang salah adalah jika nilai-nilai tersebut primitif; dalam hal ini, kode tidak akan dikompilasi sehingga lebih sulit untuk dilewatkan. Oleh karena itu, .equals()lebih mudah untuk mengidentifikasi sebagai yang benar, dan lebih aman terhadap refactoring di masa depan.

Saya benar-benar berpikir bahwa bahasa Jawa seharusnya telah mendefinisikan == pada Objek untuk memanggil .equals () pada nilai sebelah kiri, dan memperkenalkan operator terpisah untuk identitas objek, tetapi bukan itu yang didefinisikan Java.

Singkatnya, saya masih berpikir argumennya mendukung penggunaan .equals()untuk enumtipe.

Saya lebih suka menggunakan ==daripada equals:

Alasan lain, selain yang sudah dibahas di sini, adalah Anda bisa memperkenalkan bug tanpa menyadarinya. Misalkan Anda memiliki enum ini yang persis sama tetapi dalam pacakges terpisah (itu tidak umum, tetapi itu bisa terjadi):

Enum pertama :

package first.pckg

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

Enum kedua:

package second.pckg

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

Kemudian misalkan Anda menggunakan equals seperti berikutnya dalam item.categoryyang first.pckg.Categorytetapi Anda mengimpor enum kedua ( second.pckg.Category) bukan yang pertama tanpa menyadarinya:

import second.pckg.Category;
...

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

Jadi Anda akan mendapatkan allways falsekarena merupakan enum berbeda walaupun Anda harapkan karena benar item.getCategory()adalah JAZZ. Dan itu bisa agak sulit dilihat.

Jadi, jika Anda menggunakan operator, ==Anda akan memiliki kesalahan kompilasi:

operator == tidak dapat diterapkan ke "second.pckg.Category", "first.pckg.Category"

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Berikut ini adalah tes waktu kasar untuk membandingkan keduanya:

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

}

Komentari IFs satu per satu. Berikut adalah dua perbandingan dari atas dalam byte-code yang dibongkar:

 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

Yang pertama (sama dengan) melakukan panggilan virtual dan menguji boolean kembali dari tumpukan. Yang kedua (==) membandingkan alamat objek secara langsung dari tumpukan. Dalam kasus pertama ada lebih banyak aktivitas.

Saya menjalankan tes ini beberapa kali dengan kedua IF satu per satu. "==" sedikit lebih cepat.

Dalam hal enum keduanya benar dan benar !!

tl; dr

Pilihan lain adalah Objects.equalsmetode utilitas.

Objects.equals( thisEnum , thatEnum )

Objects.equals untuk null-safety

sama dengan operator == bukannya .equals ()

Operator mana yang harus saya gunakan?

Opsi ketiga adalah equalsmetode statis yang ditemukan pada Objectskelas utilitas yang ditambahkan ke Java 7 dan yang lebih baru.

Contoh

Berikut ini contoh menggunakan Monthenum.

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

Manfaat

Saya menemukan beberapa manfaat untuk metode ini:

• Tidak ada keamanan
  • Keduanya nol ➙ true
  • Baik nol ➙ false
  • Tidak ada risiko melempar NullPointerException
• Ringkas, mudah dibaca

Bagaimana itu bekerja

Logika apa yang digunakan Objects.equals?

Lihat sendiri, dari kode sumber Java 10 dari OpenJDK :

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

Menggunakan apa pun selain ==untuk membandingkan konstanta enum adalah omong kosong. Ini seperti membandingkan classobjek denganequals - jangan lakukan itu!

Namun, ada bug jahat (BugID 6277781 ) di Sun JDK 6u10 dan sebelumnya yang mungkin menarik karena alasan historis. Bug ini mencegah penggunaan yang tepat ==pada enum deserialized, meskipun ini bisa dibilang agak sudut kasus.

Enum adalah kelas yang mengembalikan satu instance (seperti lajang) untuk setiap konstanta enumerasi yang dideklarasikan oleh public static final field(immutable) sehingga ==operator dapat digunakan untuk memeriksa kesetaraan mereka daripada menggunakan equals()metode

Alasan enum bekerja dengan mudah dengan == adalah karena setiap instance yang didefinisikan juga merupakan singleton. Jadi perbandingan identitas menggunakan == akan selalu berhasil.

Tetapi menggunakan == karena ini bekerja dengan enums berarti semua kode Anda erat dengan penggunaan enum itu.

Misalnya: Enums dapat mengimplementasikan antarmuka. Misalkan Anda saat ini menggunakan enum yang mengimplementasikan Interface1. Jika nanti, seseorang mengubahnya atau memperkenalkan Impl1 kelas baru sebagai implementasi dari antarmuka yang sama. Kemudian, jika Anda mulai menggunakan instans Impl1, Anda akan memiliki banyak kode untuk diubah dan diuji karena penggunaan == sebelumnya.

Oleh karena itu, yang terbaik adalah mengikuti apa yang dianggap sebagai praktik yang baik kecuali jika ada keuntungan yang dapat dibenarkan.

Salah satu aturan Sonar adalah Enum values should be compared with "==". Alasannya adalah sebagai berikut:

Menguji kesetaraan nilai enum dengan equals()benar-benar valid karena enum adalah Obyek dan setiap pengembang Java tahu ==tidak boleh digunakan untuk membandingkan konten Obyek. Pada saat yang sama, menggunakan ==enum:

• menyediakan perbandingan yang diharapkan (konten) dengan equals()

• lebih aman dari nol equals()

• menyediakan waktu kompilasi (statis) daripada memeriksa runtime

Untuk alasan ini, penggunaan ==harus lebih disukai equals().

Last but not least, ==pada enum bisa dibilang lebih mudah dibaca (kurang verbose) daripada equals().

Singkatnya, keduanya memiliki pro dan kontra.

Di satu sisi, ia memiliki kelebihan untuk digunakan ==, seperti yang dijelaskan dalam jawaban lain.

Di sisi lain, jika Anda dengan alasan apa pun mengganti enum dengan pendekatan yang berbeda (instance kelas normal), setelah menggunakan ==menggigit Anda. (BTDT.)

Saya ingin melengkapi jawaban polygenelubricants:

Saya pribadi lebih suka sama dengan (). Tapi itu memeriksa kompatibilitas jenis. Yang menurut saya merupakan batasan penting.

Untuk melakukan pemeriksaan kompatibilitas jenis pada waktu kompilasi, deklarasikan dan gunakan fungsi kustom di enum Anda.

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

Dengan ini, Anda mendapatkan semua keuntungan dari kedua solusi: perlindungan NPE, kode mudah dibaca dan ketik kompatibilitas kompatibilitas pada waktu kompilasi.

Saya juga merekomendasikan untuk menambahkan nilai UNDEFINED untuk enum.