Jak można ulepszyć Javę, aby nie musiała już przeprowadzać kasowania typu?


16

Oficjalny poradnik Java na generycznych wyjaśnia typu skasowaniu i dlatego dodano do kompilatora:

Po utworzeniu instancji typu ogólnego kompilator tłumaczy te typy za pomocą techniki zwanej kasowanie typu - proces, w którym kompilator usuwa wszystkie informacje związane z parametrami typu i argumentami typu w klasie lub metodzie. Usuwanie typu umożliwia aplikacjom Java korzystającym z generycznych zachowanie binarnej zgodności z bibliotekami Java i aplikacjami, które zostały utworzone przed generycznymi.

To najprawdopodobniej było podejście pragmatyczne, a może najmniej bolesne. Jednak teraz, gdy leki generyczne są szeroko obsługiwane w branży, co można zrobić, abyśmy nie potrzebowali kasowania czcionek? Czy jest to wykonalne bez konieczności łamania wstecznej kompatybilności, czy jeśli jest wykonalne, czy jest to praktyczne?

Czy ostatnie stwierdzenie w powyższym cytacie stało się samodzielne? To znaczy: „wymazanie typu umożliwia aplikacjom Java korzystającym z generycznych zachowanie binarnej zgodności z bibliotekami Java i aplikacjami, które zostały utworzone za pomocą wersji Java wykonujących wymazywanie”.


1
Sun 1.4 został EOL'ed. IBM nadal obsługuje 1.4 na swoich platformach.

@ ThorbjørnRavnAndersen: A przynajmniej dla platformy, która znajduje się w piwnicy mojego taty, nie ma 1,5.
Jörg W Mittag

@ ThorbjørnRavnAndersen Nie tylko to, ale można też kupić rozszerzoną obsługę znacznie wcześniejszych wersji JVM. Ostatnio słyszałem, choć jest dość drogi.
wałek klonowy

1
Nikt z nas tutaj nie ma kryształowej kuli, więc nie można na nią odpowiedzieć. Być może można je ponownie otworzyć, jeśli przeformułujesz pytanie z pytania „Czy kiedykolwiek będzie ...” na „Co należy zrobić, aby usunąć typ w następnej wersji Javy”
maple_shaft

@ JörgWMittag czy byłaby to platforma faktycznie używana do produkcji w 2012 roku?

Odpowiedzi:


7

Koniec cyklu życia dotyczy oprogramowania Java Development Toolkit i środowiska Java Runtime Environment. I tylko wersje Oracle (Sun). Nie dotyczy to jednak aplikacji napisanych przez osoby trzecie. Intencją jest, aby nigdy nie łamać kodu, który kiedykolwiek działał na JVM, dlatego jest mało prawdopodobne, że Java kiedykolwiek przestanie wymazywać.

Oczywiście C # wprowadził również generyczne w późniejszej wersji w sposób zgodny z poprzednimi wersjami bez usuwania typu, ale w zasadzie oznaczało to powielenie wszystkich klas kolekcji. Wydaje mi się, że tego nie chcą projektanci Java i dlatego wybrali przede wszystkim wymazanie typu. Bez typów wartości przewaga generycznych nieskasowanych typów nie jest aż tak duża.


6
Zespół OpenJDK omówił ponowne spojrzenie na zreifikowane Generics, ramy czasowe? Najprawdopodobniej zostanie poważnie potraktowany w czasie Java 9 i jeśli jest to technicznie wykonalne, dostarczone w czasie Java 10. Ale to z mojej strony poważne uspokojenie.
Martijn Verburg

Usuwanie typu jest wykonywane przez kompilator, a nie przez JVM. Wprowadzenie poprawionych generics wymagałoby nowego kompilatora i nowej JVM, ale prawdopodobnie nadal będą działać ze starym kodem.
Gabe,

@Gabe: Oczywiście zostaną one wprowadzone w nowej wersji, więc pojawiłby się nowy kompilator i nowa JVM. Wymaga to jednak także powielenia znacznej części standardowej biblioteki, ponieważ potrzebne byłyby ogólne wersje nowego kodu i wersje inne niż ogólne dla kompatybilności wstecznej. .NET właśnie to zrobił w wersji 2.0, Java uniknęła go poprzez usunięcie. .NET ma typy wartości (struct), a obsługa ich pierwszej klasy wyklucza kasowanie typu. Java nie, więc presja na zmienione generyczne jest znacznie mniejsza.
Jan Hudec

Jan: Właśnie komentowałem fakt, że modyfikowanie generycznych nie oznacza automatycznie, że cały stary kod jest zepsuty. Dodałbym również, List<int>że prawdopodobnie spowodowałoby, że obciążenia znacznie bardziej byłyby wydajniejsze niż obecne List<Integer>.
Gabe,

@Gabe: Nie zgadzamy się w tym. Chciałem tylko zwrócić uwagę na główną wadę.
Jan Hudec
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.