Чому я повинен дбати про те, щоб у Java не було оновлених дженериків?

Це виникло як питання, яке я нещодавно задав в інтерв'ю, як щось, що хотів бачити кандидат, додане до мови Java. Зазвичай це ідентифікується як біль, що Java не переробляє дженерики, але, натиснувши, кандидат насправді не міг сказати мені того, чого він міг би досягти, якби вони були.

Очевидно, через те, що необмежені типи дозволені в Java (і небезпечні перевірки), можна підривати генеричні дані і в кінцевому підсумку мати List<Integer>те, що (наприклад) насправді містить Strings. Це, очевидно, могло б бути неможливим, якщо інформація про тип був перероблений; але повинно бути більше, ніж це !

Чи могли б люди розміщувати приклади речей, які вони дійсно хотіли б зробити , чи були вдосконалені загальні дженерики? Я маю на увазі, очевидно, що ти можеш отримати тип Listпід час виконання - але що б ти з цим робив?

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

EDIT : Швидке оновлення цього питання, оскільки відповіді, як видається, в основному викликає занепокоєння щодо необхідності передачі в Classякості параметра (наприклад EnumSet.noneOf(TimeUnit.class)). Я шукав більше чогось там, де це просто неможливо . Наприклад:

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?

З кількох разів, коли я стикався з цією "потребою", вона в кінцевому підсумку зводиться до цієї конструкції:

public class Foo<T> {

    private T t;

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

}

Це працює в C #, якщо Tмати конструктор за замовчуванням . Ви навіть можете отримати тип виконання typeof(T)та отримати конструктори Type.GetConstructor().

Загальним рішенням Java було б передавати Class<T>як аргумент.

public class Foo<T> {

    private T t;

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

}

(це не обов'язково потрібно передавати як аргумент конструктора, оскільки аргумент методу також чудовий, наведене вище - лише приклад, також try-catchкороткості опущено)

Для всіх інших конструкцій загального типу фактичний тип легко можна вирішити за допомогою трохи рефлексії. Нижче наведені запитання ілюструють випадки використання та можливості використання:

• Отримайте загальний тип java.util.List
• Як отримати загальний тип під час виконання?
• Отримайте фактичний аргумент загального типу на абстрактному суперкласі

Що найчастіше мене кусає - це неможливість скористатись багаторазовою розсилкою в декількох родових типах. Наступне неможливо, і є багато випадків, коли це було б найкращим рішенням:

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

Безпека типу приходить на думку. Перехід на параметризований тип завжди буде небезпечним без перероблених дженериків:

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!? 

Крім того, абстракції будуть менше просочуватися - принаймні ті, які можуть бути зацікавлені в інформації про виконання параметрів типу. Сьогодні, якщо вам потрібна будь-яка інформація про час виконання типу одного з загальних параметрів, ви також повинні передавати його Class. Таким чином, ваш зовнішній інтерфейс залежить від вашої реалізації (ви використовуєте RTTI щодо своїх параметрів чи ні).

Ви зможете створити загальні масиви у своєму коді.

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

Це давнє запитання, є багато відповідей, але я думаю, що відповіді вже не знаходяться.

"reified" просто означає реальне і зазвичай просто означає протилежне стирання типу.

Велика проблема, пов’язана з Java Generics:

• Ця жахлива вимога до боксу та відключення між примітивами та референтними типами. Це не пов’язано безпосередньо з переробкою чи стиранням типу. C # / Scala виправити це.
• Немає власних типів. З цієї причини JavaFX 8 довелося видалити "будівельників". Абсолютно нічого спільного з стиранням типу. Скала це виправляє, не впевнений у C #.
• Немає дисперсії на стороні декларації. C # 4.0 / Scala мають це. Абсолютно нічого спільного з стиранням типу.
• Неможливо перевантажити void method(List<A> l)і method(List<B> l). Це відбувається через стирання типу, але надзвичайно дрібне.
• Немає підтримки для відображення типу виконання. Це серце стирання типу. Якщо вам подобаються супер просунуті компілятори, які перевіряють і доводять більшу частину логіки вашої програми під час компіляції, вам слід використовувати рефлексію якомога менше, і такий тип стирання типу не повинен вас турбувати. Якщо вам більше подобається нескінченне, сценарійне, динамічне програмування типу, і ви не так переймаєтесь компілятором, який підтверджує як можна більшу частину вашої логіки, тоді ви бажаєте кращого відображення та виправлення стирання типу.

Серіалізація була б простішою з переробкою. Чого б ми хотіли, так і є

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

Що ми маємо зробити - це

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

виглядає некрасиво і працює чудово.

Також є випадки, коли було б дуже корисно сказати щось подібне

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

Ці речі не кусаються часто, але кусаються, коли вони трапляються.

Моє вплив на Java Geneircs є досить обмеженим, окрім пунктів, про які вже згадували інші відповіді, є сценарій, пояснений у книзі Java Generics and Collections , Моріса Нафталіна та Філіпа Уолдера, де корисні редактичні дженерики корисні.

Оскільки типи не підлягають повторенню, не можна мати параметризовані винятки.

Наприклад, декларація нижче наведеної форми не є дійсною.

class ParametericException<T> extends Exception // compile error

Це тому, що улов пункті перевіряється, чи відповідає викинутий виняток даному типу. Ця перевірка є такою ж, як перевірка, виконана тестом екземпляра, і оскільки тип не може повторно повторюватися, наведена вище форма оператора недійсна.

Якщо вищевказаний код був дійсним, тоді обробка виключень у наступному порядку була б можливою:

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

У книзі також зазначається, що якщо Java generics буде визначена аналогічно тому, як визначено шаблони C ++ (розширення), це може призвести до більш ефективної реалізації, оскільки це надає більше можливостей для оптимізації. Але не пропонує пояснення більше, ніж це, тому будь-яке пояснення (покажчики) від знаючих людей було б корисним.

Масиви, мабуть, гратимуть набагато приємніше з генериками, якби їх реіфікували.

У мене є обгортка, яка представляє набір результатів jdbc як ітератор (це означає, що я можу значно легше підключати тестові операції, засновані на базі даних, через введення залежності).

API виглядає так Iterator<T> T - якийсь тип, який можна побудувати, використовуючи лише рядки в конструкторі. Потім ітератор переглядає, що рядки повертаються з запиту sql, а потім намагаються зіставити його з конструктором типу T.

У поточному способі, що реалізується в загальній формі, я також повинен передавати в клас об'єктів, які я буду створювати з мого набору результатів. Якщо я правильно розумію, якби дженерики були реіфіковані, я міг би просто зателефонувати T.getClass () отримати його конструктори, а потім не доведеться відкидати результат Class.newInstance (), який був би далеко охайнішим.

В основному, я думаю, що це спрощує написання API (на відміну від просто написання програми), тому що ви можете зробити набагато більше об'єктів, і, таким чином, буде потрібно менше конфігурації ... Я не оцінив наслідки анотацій, поки я не бачив, як вони використовуються в таких речах, як spring або xstream замість патрубок config.

Одна приємна річ - уникати боксу для примітивних (ціннісних) типів. Це дещо пов’язане зі скаргою на масив, яку викликали інші, і у випадках, коли використання пам’яті обмежено, це фактично може суттєво змінитись.

Існує також кілька типів проблем при написанні фреймворку, коли важлива можливість відобразити параметризований тип. Звичайно, це можна вирішити, передаючи об'єкт класу навколо часу виконання, але це затьмарює API і додає додаткове навантаження на користувача фреймворку.

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

На мою думку, що дженерики - це просто зайве, що економить багато зайвих кастингів.

Щось, на що всі відповіді тут пропущено, що для мене постійно болить голова - це те, що типи стираються, ви не можете успадкувати загальний інтерфейс двічі. Це може бути проблемою, коли ви хочете зробити дрібнозернисті інтерфейси.

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

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

Ось один, який мене сьогодні зачепив: без внесення змін, якщо ви пишете метод, який приймає список варагрів із загальних предметів ... абоненти можуть думати, що вони безпечні, але випадково переходять у будь-яку стару грубість і підірвуть ваш метод.

Здається, малоймовірно, що це станеться? ... Звичайно, поки ви не використовуєте Class як свій тип даних. У цей момент ваш абонент із задоволенням надішле вам багато об’єктів Class, але простий друк надішле вам об’єкти класу, які не дотримуються T, та катастрофи.

(NB: Я, можливо, тут помилився, але гугляючи навколо "generics varargs", вище, здається, саме те, що ви очікували. Те, що робить це практичною проблемою, - це використання класу, я думаю - абонентів здається бути менш обережним :()

Наприклад, я використовую парадигму, яка використовує об’єкти Class як ключ у картах (це складніше, ніж проста карта - але концептуально це відбувається).

наприклад, це чудово працює в Java Generics (тривіальний приклад):

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

наприклад, без переробки в Java Generics, цей приймає будь-який об’єкт "Class". І це лише невелике розширення попереднього коду:

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

Вищезазначені методи повинні бути виписані тисячі разів в індивідуальному проекті - так можливість людської помилки стає високою. Налагодження помилок виявляється "не весело". Наразі я намагаюся знайти альтернативу, але не сподіваюся на те,