saber - ¿Por qué los siguientes tipos son confiables y no confiables en java?
criterios para evaluar la calidad de las fuentes de información en internet (7)
En computación, la reificación ha llegado a significar una representación explícita de un tipo, es decir, información de tipo en tiempo de ejecución.
los tutoriales de oracle dicen,
Un tipo confiable es un tipo cuya información de tipo está completamente disponible en tiempo de ejecución. Esto incluye primitivas, tipos no genéricos, tipos brutos e invocaciones de comodines no vinculados.
Los tipos no verificables son tipos en los que la información se ha eliminado en tiempo de compilación mediante el borrado de tipo: invocaciones de tipos genéricos que no están definidos como comodines ilimitados.
Un tipo es confiable si es uno de los siguientes:
- Un tipo primitivo (como
int) // entendido- Una clase o tipo de interfaz no
Runnable(comoNumber,StringoRunnable) // por qué- Un tipo parametrizado en el que todos los argumentos de tipo son comodines ilimitados (como
List<?>,ArrayList<?>OMap<?, ?>) // por qué- Un tipo sin formato (como
List,ArrayListoMap) // por qué- Una matriz cuyo tipo de componente es confiable (como
int[],Number[],List<?>[],List[]oint[][]) // por qué
Un tipo no es verificable si es uno de los siguientes:
- Una variable de tipo (como
T) // por qué- Un tipo parametrizado con parámetros reales (como
List<Number>,ArrayList<String>oMap<String, Integer>) // por qué- Un tipo parametrizado con un límite (como
List<? extends Number>oComparable<? super String>) // por qué
¿Por qué 2,3,4,5 es reificable y 6,7,8 como no reificable?
Un tipo confiable es un tipo cuya información de tipo está completamente disponible en tiempo de ejecución. Esto incluye primitivas, tipos no genéricos, tipos brutos e invocaciones de comodines no vinculados.
Los tipos no verificables son tipos en los que la información se ha eliminado en tiempo de compilación mediante el borrado de tipo: invocaciones de tipos genéricos que no están definidos como comodines ilimitados. Un tipo no verificable no tiene toda su información disponible en tiempo de ejecución. Ejemplos de tipos no confiables son List <String> y List <Number>; La JVM no puede distinguir la diferencia entre estos tipos en tiempo de ejecución. Como se muestra en Restricciones en genéricos, hay ciertas situaciones en las que no se pueden usar tipos no reificables: en una instancia de expresión, por ejemplo, o como un elemento en una matriz.
Comprende el significado de estos dos términos.
Medios confiables cuyo tipo está completamente disponible en tiempo de ejecución significa que el compilador Java no necesita ningún proceso de borrado de tipo.
No reembolsable significa que el compilador java necesita un proceso de borrado de tipo porque el tipo no está completamente disponible.
Un tipo es confiable si es uno de los siguientes:
1. Un tipo primitivo (como int):
Aquí piense que cuando escribe o usa cualquier int como referencia, ¿cree que el compilador necesita algún proceso de identificación para el tipo de int? no porque int es int .... igual para todos los tipos primitivos
2. Una clase no parametrizada o tipo de interfaz (como Número, Cadena o Ejecutable)
la misma respuesta que dije en la respuesta anterior que el compilador no necesita ningún tipo de borrado para Número, Cadena o Ejecutable.
3. Un tipo parametrizado en el que todos los argumentos de tipo son comodines ilimitados (como List <?>, ArrayList <?> O Map <??>)
Todos los caracteres comodín ilimitados se aceptan como tipo confiable porque ya se menciona en la definición de tipo confiable, ahora depende del desarrollador de la API por qué lo consideran un tipo confiable.
4. Un tipo sin formato (como List, ArrayList o Map) ::
misma respuesta que la primera pregunta
5. Una matriz cuyo tipo de componente es confiable (como int [], Number [], List <?> [], List [] o int [] []) ::
misma respuesta que la primera pregunta
Un tipo no es verificable si es uno de los siguientes:
6. Una variable de tipo (como T):
Debido a que Java no puede identificar el tipo de T, el compilador necesita borrado de tipo para identificar el tipo.
7. Un tipo parametrizado con parámetros reales (como List <Number>, ArrayList <String> o Map <String, Integer>) :
Aquí, todo tipo es un tipo genérico, en el compilador de tiempo de ejecución, ver Lista como Lista ..., por lo que, según la definición de No-refiable, todas estas colecciones se consideran no reificables.
8. Un tipo parametrizado con un límite (como Lista <? Amplía el Número> o Comparable <? Super String>).
misma respuesta que la anterior
Java originalmente implementó la reflexión en la versión 1.1.
Las clases genéricas fueron introducidas en la versión 5.0.
Al introducir los genéricos, se decidió que, por razones de compatibilidad con versiones anteriores, la información del tipo genérico se borrará en el tiempo de ejecución. Esto permitió que el código que se escribió antes de los genéricos operara con código basado en genéricos sin modificación.
Por ejemplo, el compilador traduciría una List[Integer32] a Integer32[] . Todas las comprobaciones de tipo se realizarían en tiempo de compilación, y si se omitiera algo, se generaría un error de tiempo de ejecución.
Este detalle de implementación significó que los genéricos no se reificaron (no hay implementación específica de ellos en la VM) y, por lo tanto, cada vez que se intentaría reflejar el tipo genérico, la información devuelta sería la del tipo subyacente. Otra razón por la que esto sería ventajoso es porque la VM no debería emitir implementaciones para los tipos reificados cuando se usaba una (por ejemplo, en c #, cuando se usa un tipo genérico, la VM genera su implementación real en tiempo de ejecución. junto con los metadatos de reflexión, teniendo así un impacto en el rendimiento cada vez que se necesita generar un nuevo tipo).
No estoy completamente seguro de que entiendo su pregunta, pero podría estar refiriéndose a tipos de objetos en lugar de tipos primitivos. Esa pregunta es aún más importante, ya que los tipos primitivos, como int o double, no se pueden usar como tipos genéricos, por lo tanto, sus clases de ajuste como Integer.
// This won''t work
ArrayList<int> list = new ArrayList<int>();
// But this will
ArrayList<Integer> list = new ArrayList<Integer>();
Para resumir, diría que todos los objetos, y solo los objetos, son verificables. (Y por lo tanto utilizable como creación de tipos genéricos)
Podrías preguntarle a google la misma pregunta:
tipo confiable
Cuando se usan genéricos, la mayor parte del tiempo, la información de tipo de tiempo de compilación se pierde. En el tiempo de ejecución, a menudo todo lo que el programa sabe sobre una referencia es que es una referencia a algún tipo de Objeto. Si toda la información de tipo también se conoce en el tiempo de ejecución, el tipo se llama reificable. Tal vez algún día se rediseñen los genéricos para que todos los tipos sean confiables.
Solo una conjetura, pero sospecho que la clave para entender esto es reconocer que si bien Java es un lenguaje muy tipificado y verifica las referencias de tipo como parte del proceso de compilación, en muchos casos la información de tipo no es realmente necesaria para ejecutar la lógica. En ese caso, el código de bytes generado puede saber que está trabajando con una instancia de un objeto, pero no saber el tipo. Eso tendría mucho sentido, dado que los idiomas que no utilizan la tipificación fuerte se pueden generar como código de bytes de Java. Por lo tanto, si el tipo de objeto se ha eliminado, la instancia no sería verificable.
Sun / Oracle dice que la razón es una combinación de necesidad (la verificación de tipo de tiempo de compilación es suficiente), el tamaño del código (evitar el aumento de código de tipo STL) y el rendimiento (evitar la verificación de tipo en tiempo de ejecución que ya se realizó en la compilación):
El borrado de tipos garantiza que no se creen nuevas clases para tipos parametrizados; en consecuencia, los genéricos no incurren en gastos generales de tiempo de ejecución.
En resumen, 1-6 son confiables porque simplemente siguen siendo los mismos tipos que se especifican en el código, por lo que no se pierde / borra información de tipo, pero 7-9 perderá información de tipo durante la compilación (el contenido entre <>), por lo que puede No se puede acceder en tiempo de ejecución.