Esperaba encontrar XMLStreamReader
en AutoCloseable
en Java 7. Sin embargo, ese no es el caso. ¿Existe alguna razón técnica por la que las interfaces StAX lector/grabador no se hayan (o no se hayan) adaptado para implementar AutoCloseable
? Ya tienen métodos cercanos, cuya intención no es diferente del método de cierre de AutoCloseable
.Por qué las clases StAX no fueron adaptadas para ARM en Java 7
Respuesta
Si se mira de cerca a la close()
method of AutoCloseable
:
Cierra este recurso, renunciando a cualquier recurso subyacentes. Este método se invoca automáticamente en objetos administrados por la declaración try-with-resources.
O incluso Closeable
close()
method:
Cierra esta corriente y libera los recursos del sistema asociados a ella. Si la transmisión ya está cerrada, invocar este método no tiene ningún efecto.
Considerando que el close()
method of XMLStreamReader
dice:
Libera todos los recursos asociados con este lector. Este método no cierra la fuente de entrada subyacente.
De hecho, la fuente de entrada es manejado por el Reader
que implementa la interfaz Closeable
. Por lo tanto, es el lector el que puede estar cerca en el try-with-ressource.
Por ejemplo:
XMLInputFactory factory = XMLInputFactory.newInstance();
XMLStreamReader reader = null;
try (FileReader fr = new FileReader("file.xml")) { //Will close the FileReader
reader = factory.createXMLStreamReader(fr);
reader.close();
}
catch (XMLStreamException ex) {
if(reader!=null)try {
reader.close();
} catch (XMLStreamException ex1) {
Logger.getLogger(Test.class.getName()).log(Level.SEVERE, null, ex1);
}
}
No hay ninguna razón técnica por la que no podrían haber hecho estas cosas AutoCloseable
. Me imagino que todo se reduce a la pereza o al tiempo insuficiente buscando métodos llamados close().
- 1. ¿Por qué las clases de tipos fueron difíciles de implementar?
- 2. Cambios en el acceso de las variables para las clases genéricas en Java 7
- 3. StAX formato XML en Java
- 4. ¿Por qué Eclipse no actualiza las clases?
- 5. ¿Cómo serializar las clases que no fueron diseñadas para ser serializadas?
- 6. ¿Por qué Eclipse no genera javadoc para todas las clases?
- 7. ¿Por qué las clases abstractas en Java tienen constructores?
- 8. ¿Por qué no serializar clases abstractas en Java?
- 9. ¿Por qué las clases de Java no heredan las anotaciones de las interfaces implementadas?
- 10. ¿Por qué no habrá propiedades nativas en Java 7?
- 11. API de colecciones de Java: ¿por qué las clases [Lista | Establecer | Mapa] no son modificables?
- 12. ¿Por qué las clases internas no pueden declarar miembros estáticos?
- 13. ¿Por qué las clases no están selladas por defecto?
- 14. ¿Por qué Android prefiere las clases estáticas
- 15. Java: ¿Por qué son necesarias las clases de contenedor?
- 16. ¿Por qué no hay ARM en Scala stdlib?
- 17. Análisis StAX del canal Java NIO
- 18. Cómo especificar qué analizador de stax para usar
- 19. ¿Por qué algunas instrucciones ARM no usan barril de cambio?
- 20. Necesita un evento CDATA notificando el analizador stax para java
- 21. ¿Qué complejidad tienen las operaciones en BigInteger de Java 7?
- 22. ¿Por qué F # no admite clases anidadas?
- 23. modos ARM y ¿por qué hay tantos?
- 24. Java: ¿Por qué las clases PrintWriter o PrintStream no lanzan una excepción?
- 25. ¿Por qué hay clases de contenedor en Java?
- 26. ¿Por qué las anotaciones Java?
- 27. Java: variables finales en las clases abstractas
- 28. ¿Por qué la sobrecarga del operador no está disponible para las clases en Delphi?
- 29. ¿Por qué no hay varianza genérica para las clases en C# 4.0?
- 30. Maven no utiliza Java 7
Personalmente reestructuraría ese código. reader.close() debe estar en un bloque finally en caso de que se produzca una excepción (tu captura solo es para XMLStreamException, pero también podría arrojar una excepción no verificada). También eliminaría la verificación de que el lector es nulo y simplemente jerarquizaría un segundo nivel de try-finally dentro del otro bloque try. – Trejkaz