¿Es seguro no cerrar un escáner Java, siempre que cierre el legible subyacente?

Question

Si tengo un método que toma un lector y quiero operar en el lector con un escáner de este modo:

Scanner scanner = new Scanner(reader); 
while(scanner.hasNext()) { 
    //blah blah blah 
} 

¿Es seguro que no se cierren scanner? La documentación dice que "cierra este escáner" y luego habla sobre el cierre de la lectura subyacente. Supongamos que no quiero cerrar el archivo legible y, en su lugar, quiero que la persona que llama cierre reader cuando esté lista. ¿Es seguro no cerrar scanner aquí?

Answer 1

Depende de lo que desee para estar seguro.

• Si solo está tratando de asegurarse de que la secuencia subyacente está cerrada, entonces cualquier método está bien.

• Si también desea que el Scanner se marque como cerrado (para que todas las operaciones posteriores en el objeto fallen inmediatamente), entonces debe llamar al Scanner.close().

Este es un principio general; es decir, también se aplica a varios tipos de flujos que almacenan en memoria intermedia, de una manera u otra.

Answer 2

Puesto que ya tienen el código fuente abierto :-) ...

Los close() método comprueba si el Readable subyacente también implementa la interfaz Closeable, y si lo hace lo cierra. En su situación, usted está diciendo que esto no es una preocupación porque se cerrará más tarde.

Pero el método close() también establece algunos indicadores internos que indican que el Scanner (y el Readable subyacente) están cerrados. Muchos de los métodos públicos primero comprueban si el Scanner se ha cerrado. Entonces, el peligro aquí sería que tal vez se haya cerrado su Readable subyacente, pero las llamadas posteriores al Scanner no arrojen inmediatamente un IllegalStateException, y en su lugar fallan de alguna otra manera a medida que avanzan.

Si puede asegurarse de que nada más tiene un control para la instancia Scanner en cuestión, y no intentará llamar a ningún otro método, entonces puede estar bien.

El método close() también los nulos a cabo su referencia a la Readable, por lo que si esto no sucede el Scanner no conseguiría basura recogida tan pronto como hubiera tenido que llamó close().

Llamaré Scanner.close() si es posible.

Answer 3

Bueno, si tiene clases de llamador y lector. La persona que llama no debe saber acerca de la implementación de Reader. En el siguiente método del lector:

while scanner has object 
    read them (one object per method's call) 
when objects are done 
    close the reader. 

Este es un tipo de patrón de iterador.

Answer 4

Necesitaba cerrar el Scanner también, y mantener el flujo subyacente abierto para seguir trabajando. Lo que hice fue crear una clase que extienda BufferedInputStream y anule el método close() con un cuerpo vacío.Esta clase alimenté al constructor del Scanner. De esta forma, puede llamar al scanner.close() sin cerrar la transmisión. Sin embargo, debe mantener una referencia al BufferedInputStream original, pero eso es obvio.