¿Cómo evito cerrar un InputStream pasado a mi método que envuelvo en las transmisiones de Reader?

Question

Estoy creando un método Java que acepta un único InputStream como argumento. Para la comodidad de trabajar con una corriente basada en caracteres, envuelvo el InputStream proporcionado en el inicio de la implementación del método de la siguiente manera:

public void doStuff(InputStream inStream) { 
    BufferedReader reader = new BufferedReader(new InputStreamReader(inStream)); 
    ... 
} 

Desde el InputStream (inStream) se pasa a mi método, no lo creo quiero cerrarlo ... ya que creo que esa debería ser la responsabilidad del cliente que llama a mi método (¿es correcta esta suposición?). Sin embargo, creo que debería cerrar el BufferedReader que creé; pero al hacerlo, creo que cerrará automáticamente todas las otras secuencias compuestas, incluido el inStream.

¿Alguien ve una manera de cerrar el BufferedReader y el InputStreamReader que creé sin cerrar el InputStream pasado a mi método? Tal vez hay una manera de hacer una copia de la proporcionada InputStream antes de envolverlo? Gracias

Answer 1

Lo que iba a tratar serían reemplazando el método close:

BufferedReader reader = new BufferedReader(new InputStreamReader(inStream)){ 
    public void close() throws IOException { 
     synchronized (lock) { 
      if (in == null) 
       return; 
     } 
    } 
}; 
// rest of your code 

un poco loco, pero debería funcionar. Sin embargo, no estoy seguro de que este sea el mejor enfoque.

Creo que esta es una pregunta interesante, por lo que espero que alguien experto dé su opinión.

Answer 2

Personalmente me gustaría simplemente evitar el problema cambiando la firma de su método para requerir que un BufferedReader (o lector) pueden pasar en.

Answer 3

No es necesario cerrar un BufferedReader o InputStreamReader o probablemente la mayoría de las implementaciones de los lectores , cuando no desea cerrar el lector subyacente.

Estos lectores no ser titular de los recursos que una llamada a close() haría libre y el que el recolector de basura no tendría libre de todos modos (por ejemplo, recursos o valores de las variables estáticas nativos) cuando se le cae la referencia para el lector al final de tu método.

Las secuencias de entrada subyacentes que se comunican con recursos nativos, p. FileInputStream o secuencias obtenidas de URL, se deben cerrar para liberar esos recursos nativos.

Para Writer, hay una diferencia en que close() generalmente llama a flush(). Pero luego, puede llamar al flush() directamente.