Ya sabes, como lo hace CLR. ¿Alguien admite que la falta de información genérica de tiempo de ejecución es un problema y está trabajando para resolverlo?¿Hay algún plan para que la JVM admita los genéricos en tiempo de ejecución?
Los diseñadores de Java optaron por esta solución para mantener la compatibilidad con versiones anteriores (en el nivel de bytecode). Desde entonces, hay aún más código de Java, por lo que romper la compatibilidad con versiones anteriores tendría peores consecuencias. Así que dudo que cambien de opinión sobre esto.
Han mencionado que les gustaría hacer esto en el futuro si es posible, y aioobe menciona que puede haber una forma de hacerlo sin romper la compatibilidad con versiones anteriores, así que ... No creo que pueda descartarse. – ColinD
@ColinD, no se puede descartar nada por supuesto :-) Tenga en cuenta que la cita de @ aioobe propone la reificación de tipo como una característica _opcional_ (supuestamente para el nuevo código solamente). –
@Peter the CLR no sufrió ningún problema de compatibilidad con versiones anteriores cuando se implementaron genéricos en .NET 2.0 ... ¿qué hace que la JVM sea más problemática en este sentido? –
¿Por qué es esto un problema (a partir de los comentarios a su pregunta)
Bueno, tenga en cuenta, por ejemplo, que no se puede sobrecargar un método como este:
void foo(List<String> strings) { ... }
void foo(List<Integer> ints) { ... }
incluso aunque tiene sentido permitir esto. (La razón principal de por qué esto no funciona hoy en día, es porque sería, cuando se compila a código de bytes, se parecen a foo(List strings) y foo(List ints).)
¿Hay algún plan para la JVM para apoyar a los genéricos en tiempo de ejecución?
Según this page que está al menos no en la línea de tubería para Java 7:
Actualmente, los genéricos se implementan utilizando el borrado, lo que significa
cosificada Genéricos que la información de tipo genérico no está disponible en tiempo de ejecución, lo que hace que algún tipo de código sea difícil de escribir. Los genéricos se implementaron de esta manera para respaldar la compatibilidad con versiones anteriores con códigos no genéricos más antiguos. Los genéricos reificados pondrían a disposición la información de tipo genérico en tiempo de ejecución, lo que rompería el código heredado no genérico. Sin embargo, Neal Gafter ha propuesto que los tipos sean reificables solo si se especifican, para no romper la compatibilidad con versiones anteriores.
Enlaces
Creo que alguien (posiblemente Marcos Reinhold) dijo en JavaOne de este año que se pueden tratar de materializar los genéricos en Java en el futuro. Sin embargo, esto no sería antes que Java 9, y sería un gran cambio con muchos problemas potenciales por resolver.
El problema puede ser parcialmente resolverse sin JVM cambia: En Scala (que funciona tan bien en la JVM) puede agregar llamada Manifests que contienen información de tipo en tiempo de ejecución para los parámetros genéricos. Creo que esta solución podría adaptarse para Java sin demasiados problemas. No es perfecto, pero probablemente sea mucho más fácil de implementar como "lo real".
¿por qué es un problema? – hvgotcodes
@hvgotcodes: no se puede usar con elementos primitivos, sin eficacia mejorada, no se puede usar con reflexión, seguridad de tipo inferior y muchos casos de esquina. –
@hvgotcodes: Normalmente no es un gran problema en el desarrollo diario, pero ciertamente dificulta las cosas para ciertos tipos de bibliotecas, y eso realmente necesita poder obtener dicha información en tiempo de ejecución. Tomemos Guice, por ejemplo, que necesita solucionar la falta de información de tipo con cosas como 'TypeLiteral' y sus trucos de subtipificación. Hay otros tipos de bibliotecas que se beneficiarían de manera similar. – ColinD