Dlaczego powinno mnie obchodzić, że Java nie ma reified generics?

Pojawiło się jako pytanie, które zadałem niedawno w wywiadzie, jako coś, co kandydat chciał, aby zostało dodane do języka Java. Powszechnie uważa się, że problem z tym, że Java nie ma zreifikowanych typów generycznych, ale gdy został popchnięty, kandydat nie mógł mi powiedzieć, jakie rzeczy mógłby osiągnąć, gdyby tam byli.

Oczywiście, ponieważ surowe typy są dozwolone w Javie (i niebezpieczne testy), możliwe jest obalenie typów generycznych i otrzymanie List<Integer>tego (na przykład) faktycznie zawiera Strings. Oczywiście mogłoby to być niemożliwe, gdyby informacje o typie zostały zreifikowane; ale musi być coś więcej !

Czy ludzie mogliby publikować przykłady rzeczy, które naprawdę chcieliby zrobić , gdyby dostępne były reifikowane leki generyczne? To znaczy, oczywiście możesz uzyskać typ a Listw czasie wykonywania - ale co byś z tym zrobił?

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

EDYCJA : Szybka aktualizacja, ponieważ odpowiedzi wydają się być głównie zaniepokojone potrzebą przekazania a Classjako parametru (na przykład EnumSet.noneOf(TimeUnit.class)). Szukałem czegoś podobnego do tego, gdzie to po prostu nie jest możliwe . Na przykład:

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?

Od kilku razy, kiedy natrafiłem na tę „potrzebę”, ostatecznie sprowadza się ona do tej konstrukcji:

public class Foo<T> {

    private T t;

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

}

To działa w C # przy założeniu, że Tma domyślnego konstruktora. Możesz nawet pobrać typ środowiska wykonawczego typeof(T)i konstruktory przez Type.GetConstructor().

Typowym rozwiązaniem w Javie byłoby przekazanie Class<T>argumentu as.

public class Foo<T> {

    private T t;

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

}

(nie musi być koniecznie przekazywany jako argument konstruktora, ponieważ argument metody jest również w porządku, powyższe jest tylko przykładem, również try-catchjest pomijane dla zwięzłości)

W przypadku wszystkich innych konstrukcji typu ogólnego rzeczywisty typ można łatwo rozwiązać przy niewielkiej pomocy refleksji. Poniższe pytania i odpowiedzi ilustrują przypadki użycia i możliwości:

• Uzyskaj ogólny typ java.util.List
• Jak uzyskać typ ogólny w czasie wykonywania?
• Pobierz rzeczywisty typ argumentu typu ogólnego w abstrakcyjnej nadklasie

To, co najczęściej mnie gryzie, to niemożność skorzystania z wielokrotnych wysyłek w wielu typach ogólnych. Poniższe nie są możliwe i istnieje wiele przypadków, w których byłoby to najlepsze rozwiązanie:

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

Przychodzi mi na myśl bezpieczeństwo typów . Downcasting do sparametryzowanego typu zawsze będzie niebezpieczny bez 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!? 

Ponadto abstrakcje wyciekałyby mniej - przynajmniej te, które mogą być zainteresowane informacjami w czasie wykonywania o ich parametrach typu. Dziś, jeśli potrzebujesz jakichkolwiek informacji o typie jednego z parametrów ogólnych, musisz je również przekazać Class. W ten sposób twój zewnętrzny interfejs zależy od twojej implementacji (czy używasz RTTI do swoich parametrów, czy nie).

Byłbyś w stanie tworzyć ogólne tablice w swoim kodzie.

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

To jest stare pytanie, jest mnóstwo odpowiedzi, ale myślę, że istniejące odpowiedzi są chybione.

„zreifikowany” oznacza po prostu prawdziwy i zwykle oznacza po prostu przeciwieństwo wymazania typu.

Duży problem związany z generykami Java:

• To okropne wymaganie dotyczące boksu i rozłączenie między typami pierwotnymi i referencyjnymi. Nie jest to bezpośrednio związane z reifikacją ani usuwaniem typów. C # / Scala napraw to.
• Żadnych typów jaźni. Z tego powodu JavaFX 8 musiał usunąć „budowniczych”. Absolutnie nie ma to nic wspólnego z usuwaniem czcionek. Scala rozwiązuje ten problem, nie jestem pewien co do C #.
• Brak wariancji typu po stronie deklaracji. C # 4.0 / Scala mają to. Absolutnie nie ma to nic wspólnego z usuwaniem typów.
• Nie można przeciążać void method(List<A> l)i method(List<B> l). Wynika to z wymazywania czcionek, ale jest bardzo drobiazgowe.
• Brak obsługi odbicia typu środowiska uruchomieniowego. To jest sedno usuwania czcionek. Jeśli lubisz super zaawansowane kompilatory, które weryfikują i udowadniają jak najwięcej logiki programu w czasie kompilacji, powinieneś używać refleksji tak mało, jak to możliwe, a tego typu wymazywanie nie powinno Ci przeszkadzać. Jeśli lubisz bardziej niejednolite, skryptowe, dynamiczne programowanie typów i nie przejmujesz się zbytnio kompilatorem, który udowadnia, że ​​twoja logika jest poprawna w jak największym stopniu, to chcesz mieć lepszą refleksję i naprawienie wymazywania typów jest ważne.

Serializacja byłaby prostsza w przypadku reifikacji. To, czego chcielibyśmy, to

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

Musimy zrobić

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

wygląda brzydko i działa dziwnie.

Są też przypadki, w których naprawdę pomocne byłoby powiedzenie czegoś takiego

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

Te rzeczy nie gryzą często, ale gryzą, gdy się zdarzają.

Moje narażenie na Java Geneircs jest dość ograniczone i poza punktami, o których wspomniały już inne odpowiedzi, istnieje scenariusz wyjaśniony w książce Java Generics and Collections , autorstwa Maurice'a Naftalina i Philipa Waldera, w której użyteczne są reifikowane typy generyczne.

Ponieważ typów nie można reifable, nie można mieć sparametryzowanych wyjątków.

Na przykład deklaracja poniższego formularza jest nieważna.

class ParametericException<T> extends Exception // compile error

Dzieje się tak, ponieważ klauzula catch sprawdza, czy zgłoszony wyjątek pasuje do danego typu. To sprawdzenie jest takie samo jak sprawdzenie przeprowadzane przez test instancji, a ponieważ typu nie można ponowić, powyższa forma instrukcji jest nieprawidłowa.

Gdyby powyższy kod był prawidłowy, obsługa wyjątków w poniższy sposób byłaby możliwa:

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

W książce wspomniano również, że jeśli typy generyczne języka Java są zdefiniowane podobnie do sposobu definiowania szablonów C ++ (rozszerzenie), może to prowadzić do wydajniejszej implementacji, ponieważ oferuje to więcej możliwości optymalizacji. Ale nie oferuje więcej wyjaśnień, więc wszelkie wyjaśnienia (wskazówki) od znających się na rzeczy ludzi byłyby pomocne.

Tablice prawdopodobnie działałyby znacznie lepiej z rodzajami, gdyby były reifikowane.

Mam opakowanie, które przedstawia zestaw wyników jdbc jako iterator (oznacza to, że mogę dużo łatwiej testować jednostkowe operacje pochodzące z bazy danych dzięki iniekcji zależności).

Wygląda na to API Iterator<T> jest typem, który można skonstruować przy użyciu tylko ciągów znaków w konstruktorze. Następnie Iterator sprawdza ciągi zwracane przez zapytanie sql, a następnie próbuje dopasować je do konstruktora typu T.

W obecnym sposobie implementacji typów generycznych muszę również przekazać klasę obiektów, które będę tworzyć z mojego zestawu wyników. Jeśli dobrze rozumiem, gdyby typy generyczne zostały zreifikowane, mógłbym po prostu wywołać funkcję T.getClass (), aby uzyskać jej konstruktory, a następnie nie musieć rzutować wyniku Class.newInstance (), co byłoby znacznie bardziej estetyczne.

Zasadniczo uważam, że ułatwia pisanie interfejsów API (w przeciwieństwie do zwykłego pisania aplikacji), ponieważ z obiektów można wywnioskować znacznie więcej, a tym samym mniej konfiguracji będzie potrzebnych ... Nie doceniałem implikacji adnotacji, dopóki nie widziałem ich użycie w rzeczach takich jak spring lub xstream zamiast ryz w config.

Jedną z fajnych rzeczy byłoby unikanie boksu dla typów pierwotnych (wartościowych). Jest to w pewnym stopniu związane z zarzutem dotyczącym tablicy, który podnieśli inni, aw przypadkach, gdy użycie pamięci jest ograniczone, może to faktycznie spowodować znaczącą różnicę.

Istnieje również kilka typów problemów podczas pisania frameworka, w których ważna jest możliwość odzwierciedlenia sparametryzowanego typu. Oczywiście można to obejść, przekazując obiekt klasy w czasie wykonywania, ale to przesłania API i nakłada dodatkowe obciążenie na użytkownika frameworka.

Nie chodzi o to, że osiągniesz coś niezwykłego. Po prostu łatwiej będzie to zrozumieć. Wymazywanie typów wydaje się być trudnym czasem dla początkujących i ostatecznie wymaga zrozumienia sposobu działania kompilatora.

Uważam, że generyczne są po prostu dodatkami, które oszczędzają wiele zbędnych rzutów.

Coś, czego pominęły wszystkie odpowiedzi tutaj, a co jest dla mnie nieustannie bólem głowy, jest takie, że ponieważ typy są usuwane, nie można dwukrotnie dziedziczyć ogólnego interfejsu. Może to stanowić problem, gdy chcesz tworzyć precyzyjne interfejsy.

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

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

Oto jeden, który mnie dzisiaj złapał: bez reifikacji, jeśli napiszesz metodę, która akceptuje listę elementów ogólnych typu varargs ... wywołujący mogą MYŚLIĆ, że są bezpieczni dla typów, ale przypadkowo przekazują jakąkolwiek starą crud i wysadzają twoją metodę.

Wydaje się mało prawdopodobne, że tak się stanie? ... Jasne, dopóki ... nie użyjesz Class jako swojego typu danych. W tym momencie dzwoniący z radością wyśle ​​Ci wiele obiektów Class, ale prosta literówka wyśle ​​Ci obiekty Class, które nie są zgodne z T, i zdarzy się katastrofa.

(Uwaga: być może popełniłem tutaj błąd, ale przeglądając w Google „warargi generyczne”, powyższe wydaje się być właśnie tym, czego można się spodziewać. Rzeczą, która sprawia, że ​​jest to praktyczny problem, jest, jak sądzę, korzystanie z Class - wydaje się, że rozmówcy być mniej ostrożnym :()

Na przykład używam paradygmatu, który używa obiektów klasy jako klucza w mapach (jest bardziej złożony niż prosta mapa - ale koncepcyjnie tak właśnie się dzieje).

np. to działa świetnie w Java Generics (trywialny przykład):

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

np. bez reifikacji w Java Generics, ten akceptuje KAŻDY obiekt "Class". A to tylko malutkie rozszerzenie poprzedniego kodu:

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

Powyższe metody muszą być zapisywane tysiące razy w indywidualnym projekcie - więc prawdopodobieństwo błędu ludzkiego staje się wysokie. Błędy w debugowaniu okazują się „niefajne”. Obecnie próbuję znaleźć alternatywę, ale nie mam nadziei.