Mengapa saya harus peduli bahwa Java tidak memiliki obat generik yang direifikasi?

Ini muncul sebagai pertanyaan yang saya ajukan dalam sebuah wawancara baru-baru ini karena kandidat ingin melihat ditambahkan ke bahasa Jawa. Ini biasanya diidentifikasi sebagai masalah bahwa Java tidak memiliki obat generik , tetapi ketika didorong, kandidat tidak dapat benar-benar memberi tahu saya hal-hal yang dapat dia capai jika mereka ada di sana.

Jelas karena tipe mentah diperbolehkan di Java (dan pemeriksaan tidak aman), adalah mungkin untuk menumbangkan obat generik dan berakhir dengan List<Integer>yang (misalnya) sebenarnya berisi Strings. Ini jelas bisa dibuat mustahil jika informasi jenis direifikasi; tapi pasti ada lebih dari ini !

Dapatkah orang memposting contoh hal-hal yang benar-benar ingin mereka lakukan , apakah obat generik reified tersedia? Maksud saya, jelas Anda bisa mendapatkan tipe a Listsaat runtime - tetapi apa yang akan Anda lakukan dengannya?

public <T> void foo(List<T> l) {
   if (l.getGenericType() == Integer.class) {
       //yeah baby! err, what now?

EDIT : Pembaruan cepat untuk ini karena jawabannya tampaknya terutama berkaitan dengan kebutuhan untuk memasukkan a Classsebagai parameter (misalnya EnumSet.noneOf(TimeUnit.class)). Saya mencari lebih banyak hal di sepanjang garis di mana hal ini tidak mungkin . Sebagai contoh:

List<?> l1 = api.gimmeAList();
List<?> l2 = api.gimmeAnotherList();

if (l1.getGenericType().isAssignableFrom(l2.getGenericType())) {
    l1.addAll(l2); //why on earth would I be doing this anyway?

Dari beberapa kali saya menemukan "kebutuhan" ini, akhirnya bermuara pada konstruksi ini:

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

Ini berfungsi di C # dengan asumsi bahwa Tmemiliki konstruktor default . Anda bahkan bisa mendapatkan jenis runtime typeof(T)dan mendapatkan konstruktornya Type.GetConstructor().

Solusi umum Java adalah meneruskan Class<T>argumen as.

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}

(itu tidak perlu dilewatkan sebagai argumen konstruktor, karena argumen metode juga baik-baik saja, di atas hanyalah sebuah contoh, juga try-catchdihilangkan agar singkatnya)

Untuk semua konstruksi tipe umum lainnya, tipe sebenarnya dapat dengan mudah diselesaikan dengan sedikit bantuan refleksi. T&J di bawah mengilustrasikan kasus dan kemungkinan penggunaan:

• Dapatkan tipe umum java.util.List
• Bagaimana cara mendapatkan tipe generik saat runtime?
• Dapatkan tipe sebenarnya dari argumen tipe umum pada superclass abstrak

Hal yang paling sering mengganggu saya adalah ketidakmampuan untuk memanfaatkan beberapa pengiriman di beberapa jenis generik. Hal berikut ini tidak mungkin dan ada banyak kasus di mana itu akan menjadi solusi terbaik:

public void my_method(List<String> input) { ... }
public void my_method(List<Integer> input) { ... }

Keamanan jenis muncul dalam pikiran. Downcasting ke tipe parametrized akan selalu tidak aman tanpa reified generics:

List<String> myFriends = new ArrayList();
myFriends.add("Alice");
getSession().put("friends", myFriends);
// later, elsewhere
List<Friend> myFriends = (List<Friend>) getSession().get("friends");
myFriends.add(new Friend("Bob")); // works like a charm!
// and so...
List<String> myFriends = (List<String>) getSession().get("friends");
for (String friend : myFriends) print(friend); // ClassCastException, wtf!? 

Selain itu, abstraksi akan lebih sedikit bocor - setidaknya abstraksi yang mungkin tertarik dengan informasi runtime tentang parameter tipenya. Saat ini, jika Anda memerlukan informasi runtime jenis apa pun tentang jenis salah satu parameter umum, Anda juga harus meneruskannya Class. Dengan begitu, antarmuka eksternal Anda bergantung pada implementasi Anda (apakah Anda menggunakan RTTI tentang parameter Anda atau tidak).

Anda akan dapat membuat array umum dalam kode Anda.

public <T> static void DoStuff() {
    T[] myArray = new T[42]; // No can do
}

Ini adalah pertanyaan lama, ada banyak sekali jawaban, tetapi saya pikir jawaban yang ada melenceng.

"reified" hanya berarti nyata dan biasanya hanya berarti kebalikan dari penghapusan tipe.

Masalah besar terkait dengan Java Generics:

• Persyaratan tinju yang mengerikan ini dan memutuskan hubungan antara jenis primitif dan referensi. Ini tidak terkait langsung dengan reifikasi atau penghapusan tipe. C # / Scala perbaiki ini.
• Tidak ada tipe diri. JavaFX 8 harus menghapus "pembangun" karena alasan ini. Sama sekali tidak ada hubungannya dengan penghapusan tipe. Scala memperbaiki ini, tidak yakin tentang C #.
• Tidak ada varian tipe sisi deklarasi. C # 4.0 / Scala memiliki ini. Sama sekali tidak ada hubungannya dengan penghapusan tipe.
• Tidak bisa membebani void method(List<A> l)dan method(List<B> l). Hal ini karena penghapusan tipe tetapi sangat kecil.
• Tidak ada dukungan untuk refleksi jenis runtime. Ini adalah inti dari penghapusan tipe. Jika Anda menyukai kompiler super canggih yang memverifikasi dan membuktikan sebanyak mungkin logika program Anda pada waktu kompilasi, Anda harus menggunakan refleksi sesedikit mungkin dan jenis penghapusan jenis ini tidak akan mengganggu Anda. Jika Anda menyukai lebih banyak patchy, scripty, pemrograman tipe dinamis dan tidak terlalu peduli tentang kompiler yang membuktikan sebanyak mungkin logika Anda benar, maka Anda menginginkan refleksi yang lebih baik dan memperbaiki penghapusan tipe itu penting.

Serialisasi akan lebih mudah dengan reifikasi. Yang kami inginkan adalah

deserialize(thingy, List<Integer>.class);

Yang harus kita lakukan adalah

deserialize(thing, new TypeReference<List<Integer>>(){});

terlihat jelek dan bekerja dengan funky.

Ada juga kasus di mana akan sangat membantu untuk mengatakan sesuatu seperti

public <T> void doThings(List<T> thingy) {
    if (T instanceof Q)
      doCrazyness();
  }

Hal-hal ini tidak sering menggigit, tetapi akan menggigit saat terjadi.

Paparan saya tentang Java Geneircs sangat terbatas, dan terlepas dari poin-poin yang telah disebutkan oleh jawaban lain, terdapat skenario yang dijelaskan dalam buku Java Generics and Collections , oleh Maurice Naftalin dan Philip Walder, di mana obat generik yang direifikasi berguna.

Karena jenis tidak dapat diubah, tidak mungkin memiliki pengecualian berparameter.

Misalnya pernyataan formulir di bawah ini tidak valid.

class ParametericException<T> extends Exception // compile error

Ini karena klausa catch memeriksa apakah pengecualian yang ditampilkan cocok dengan tipe yang diberikan. Pemeriksaan ini sama dengan pemeriksaan yang dilakukan oleh uji contoh dan karena jenisnya tidak dapat diubah, bentuk pernyataan di atas tidak valid.

Jika kode di atas valid maka penanganan pengecualian dengan cara di bawah ini akan dimungkinkan:

try {
     throw new ParametericException<Integer>(42);
} catch (ParametericException<Integer> e) { // compile error
  ...
}

Buku tersebut juga menyebutkan bahwa jika generik Java didefinisikan mirip dengan cara kerangka C ++ didefinisikan (perluasan), hal itu dapat mengarah pada penerapan yang lebih efisien karena ini menawarkan lebih banyak peluang untuk pengoptimalan. Tetapi tidak menawarkan penjelasan lebih dari ini, jadi penjelasan (petunjuk) dari orang-orang yang berpengetahuan akan sangat membantu.

Array mungkin akan bermain jauh lebih baik dengan obat generik jika mereka direifikasi.

Saya memiliki pembungkus yang menyajikan jdbc resultet sebagai iterator, (itu berarti saya dapat menguji unit operasi yang berasal dari database jauh lebih mudah melalui injeksi ketergantungan).

API terlihat seperti di Iterator<T>mana T adalah beberapa tipe yang dapat dibangun hanya dengan menggunakan string dalam konstruktor. Iterator kemudian melihat string yang dikembalikan dari kueri sql dan kemudian mencoba mencocokkannya dengan konstruktor tipe T.

Dengan cara generik saat ini diimplementasikan, saya juga harus meneruskan kelas objek yang akan saya buat dari resultet saya. Jika saya mengerti dengan benar, jika obat generik direifikasi, saya bisa memanggil T.getClass () mendapatkan konstruktornya, dan kemudian tidak perlu menampilkan hasil Class.newInstance (), yang akan jauh lebih rapi.

Pada dasarnya, saya pikir itu membuat penulisan API (daripada hanya menulis aplikasi) lebih mudah, karena Anda dapat menyimpulkan lebih banyak dari objek, dan dengan demikian lebih sedikit konfigurasi yang diperlukan ... Saya tidak menghargai implikasi anotasi sampai saya melihat mereka digunakan dalam hal-hal seperti spring atau xstream sebagai ganti rim config.

Satu hal yang menyenangkan adalah menghindari tinju untuk tipe primitif (nilai). Ini agak terkait dengan keluhan larik yang diajukan orang lain, dan dalam kasus di mana penggunaan memori dibatasi, hal itu sebenarnya dapat membuat perbedaan yang signifikan.

Ada juga beberapa jenis masalah saat menulis kerangka di mana kemampuan untuk merefleksikan tipe berparameter itu penting. Tentu saja ini bisa diatasi dengan melewatkan objek kelas pada saat runtime, tapi ini mengaburkan API dan menempatkan beban tambahan pada pengguna framework.

Bukan berarti Anda akan mencapai sesuatu yang luar biasa. Ini hanya akan lebih sederhana untuk dipahami. Penghapusan jenis sepertinya merupakan waktu yang sulit bagi pemula, dan pada akhirnya membutuhkan pemahaman seseorang tentang cara kerja compiler.

Pendapat saya adalah, bahwa obat generik hanyalah tambahan yang menghemat banyak pengecoran yang berlebihan.

Sesuatu yang terlewatkan oleh semua jawaban di sini yang selalu memusingkan saya adalah karena jenisnya dihapus, Anda tidak dapat mewarisi antarmuka generik dua kali. Ini bisa menjadi masalah saat Anda ingin membuat antarmuka yang halus.

    public interface Service<KEY,VALUE> {
           VALUE get(KEY key);
    }

    public class PersonService implements Service<Long, Person>,
        Service<String, Person> //Can not do!!

Inilah salah satu yang menarik perhatian saya hari ini: tanpa reifikasi, jika Anda menulis metode yang menerima daftar vararg dari item umum ... penelepon dapat BERPIKIR bahwa mereka aman untuk mengetik, tetapi secara tidak sengaja memasukkan bahan mentah lama, dan meledakkan metode Anda.

Sepertinya tidak mungkin itu akan terjadi? ... Tentu, sampai ... Anda menggunakan Kelas sebagai tipe data Anda. Pada titik ini, pemanggil Anda dengan senang hati akan mengirimi Anda banyak objek Kelas, tetapi kesalahan ketik sederhana akan mengirimi Anda objek Kelas yang tidak sesuai dengan T, dan bencana melanda.

(NB: Saya mungkin telah membuat kesalahan di sini, tapi mencari-cari di sekitar "varargs generik", di atas tampaknya hanya apa yang Anda harapkan. Hal yang membuat masalah ini praktis adalah penggunaan Kelas, saya pikir - penelepon tampaknya kurang hati-hati :()

Misalnya, saya menggunakan paradigma yang menggunakan objek Kelas sebagai kunci dalam peta (ini lebih kompleks daripada peta sederhana - tetapi secara konseptual itulah yang terjadi).

misalnya ini berfungsi dengan baik di Java Generics (contoh sepele):

public <T extends Component> Set<UUID> getEntitiesPossessingComponent( Class<T> componentType)
    {
        // find the entities that are mapped (somehow) from that class. Very type-safe
    }

misalnya tanpa reifikasi di Java Generics, yang ini menerima objek "Kelas" APA PUN. Dan itu hanya sebagian kecil dari kode sebelumnya:

public <T extends Component> Set<UUID> getEntitiesPossessingComponents( Class<T>... componentType )
    {
        // find the entities that are mapped (somehow) to ALL of those classes
    }

Metode di atas harus ditulis ribuan kali dalam satu proyek - sehingga kemungkinan terjadinya kesalahan manusia menjadi tinggi. Kesalahan debugging terbukti "tidak menyenangkan". Saat ini saya mencoba mencari alternatif, tapi jangan berharap banyak.