Как можно улучшить Java, чтобы он больше не нуждался в стирании типов?


16

Официальный Java учебник по дженериков объясняет тип стиранию и почему он был добавлен в компиляторе:

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

Скорее всего, это был прагматичный подход или, возможно, наименее болезненный. Однако теперь, когда дженерики широко поддерживаются в отрасли, что можно сделать, чтобы нам не требовалось стирание типов? Это возможно без необходимости обратной совместимости или, если это возможно, практично?

Последнее утверждение в приведенной выше цитате стало ссылаться на себя? То есть: «стирание типов позволяет приложениям Java, использующим универсальные средства, поддерживать двоичную совместимость с библиотеками Java и приложениями, которые были созданы с версиями Java, которые выполняют стирание типов».


1
Солнце 1.4 было EOL'ed. IBM все еще поддерживает 1.4 на своих платформах.

@ ThorbjørnRavnAndersen: И по крайней мере для платформы, которая находится в подвале моего отца, нет 1,5.
Йорг Миттаг

@ ThorbjørnRavnAndersen Мало того, что можно также приобрести расширенную поддержку для более ранних версий JVM. Последнее, что я слышал, хотя это довольно дорого.
maple_shaft

1
Ни у кого из нас нет хрустального шара, поэтому он не несет ответственности. Возможно, его можно будет вновь открыть, если перефразировать вопрос из вопроса «Будет ли когда-нибудь ...» в вопрос «Что необходимо сделать, чтобы
стирание

@ JörgWMittag - будет ли эта платформа фактически использоваться для производства в 2012 году?

Ответы:


7

Окончание срока службы относится к Java Development Toolkit и Java Runtime Environment. И только версии Oracle (Sun). Но это не относится к приложениям, написанным третьими лицами. Намерение состоит в том, чтобы никогда не нарушать код, который когда-либо выполнялся на JVM, поэтому вряд ли Java когда-либо перестанет выполнять стирание типов.

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


6
Команда OpenJDK снова обсудила вопрос о пересмотре родовых обобщений, сроки? Скорее всего, будет серьезно рассматриваться в течение периода Java 9 и, если это технически осуществимо, доставлено в период Java 10. Но это серьезно, с моей стороны.
Мартейн Вербург

Стирание типа выполняется компилятором, а не JVM. Для внедрения улучшенных обобщений потребуется новый компилятор и новая JVM, но, вероятно, они все равно будут работать со старым кодом.
Гейб

@Gabe: Очевидно, они будут представлены в новом выпуске, так что будет новый компилятор и новая JVM. Но это также требует дублирования значительной части стандартной библиотеки, поскольку для этого потребуются универсальные версии для нового кода и неуниверсальные версии для обратной совместимости. .NET сделал именно это в версии 2.0, Java избежал этого с помощью erasure. .NET имеет типы значений (struct), и первоклассная поддержка для них исключает стирание типов. Java этого не делает, поэтому нагрузка на усовершенствованные дженерики намного меньше.
Ян Худек

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

@Gabe: мы не согласны с этим. Я просто хотел отметить главный недостаток.
Ян Худек
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.