Як можна вдосконалити Java, щоб більше не потрібно виконувати стирання типу?

В офіційному навчальному посібнику Java щодо дженерики пояснюється стирання типу та чому його додано до компілятора:

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

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

Чи стало останнє твердження у цитаті вище, яке було самореференційним? Тобто: "стирання типу дозволяє програмам Java, які використовують дженерики, підтримувати бінарну сумісність з бібліотеками Java та програмами, створеними з версіями Java, які виконують стирання типу."

java jvm

— аузер
джерело

Сонце 1.4 було EOL'ed. IBM все ще підтримує 1,4 на своїх платформах.

@ ThorbjørnRavnAndersen: І принаймні для платформи, яка сидить у підвалі мого батька, немає 1,5.

— Йорг W Міттаг

@ ThorbjørnRavnAndersen Мало того, але можна придбати розширену підтримку і для набагато більш ранніх версій JVM. Останній я чув, хоча це досить дорого.

— maple_shaft

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

— maple_shaft

@ JörgWMittag це була б платформа, яка фактично використовувалася для виробництва у 2012 році?

Кінець життя застосовується до інструментарію Java Development Toolkit та Java Runtime Environment. І лише версії Oracle (Sun). Але це не стосується заявок, написаних третіми сторонами. Наміром є ніколи не порушувати код, який коли-небудь запускався на JVM, тому навряд чи Java колись перестане робити стирання типу.

Звичайно, C # також представив дженерики в пізнішій версії у зворотно сумісний спосіб, не роблячи стирання типів, але це в основному означало дублювання всіх класів колекції. Я думаю, це те, що дизайнери Java не хочуть робити, і тому вони обрали в першу чергу тип стирання. Без типів значень перевага дженериків, що не стираються, не така вже й велика.

— Ян Худець
джерело

Команда OpenJDK знову обговорила перегляд реіфікованих Generics, часові рамки? Швидше за все, це буде серйозно розглянуто протягом часового періоду Java 9, і якщо це технічно можливо, доставляється в часовий період Java 10. Але це серйозне віщування з мого боку.

— Martijn Verburg

Стирання типу робиться компілятором, а не JVM. Для введення оновлених дженериків знадобиться новий компілятор та новий JVM, але, мабуть, вони все ще працюватимуть зі старим кодом.

— Гейб

@Gabe: Очевидно, вони будуть представлені в новому випуску, тож з'явиться новий компілятор і новий JVM. Але воно також вимагає дублювання значної частини стандартної бібліотеки, оскільки для зворотної сумісності їй потрібні будуть загальні версії для нового коду та негенеричні версії. .NET зробив саме це у версії 2.0, Java уникала цього стирання. .NET має типи значень (struct), і підтримка першого класу для них виключає стирання типу. Java цього не робить, тому тиск на перероблені генерики значно менший.

— Ян Худек

Ян: Я просто коментував той факт, що повторне використання генеричних файлів не означає автоматично, що старий код порушений. Я також додаю, що a List<int>, мабуть, зробить, безумовно, навантаження набагато ефективнішими, ніж поточні List<Integer>.

— Гейб

@Gabe: Ми не погоджуємось з цим. Я просто хотів відзначити головний недолік.

— Ян Худек