¿Por qué Scala Source no cierra el InputStream subyacente?

file-io

Question

Estoy usando Scala Source.fromFile sin embargo, parece que no puedo encontrar una buena manera de lograr que close el InputStream subyacente una vez que se haya leído el archivo.

Aquí está mi código que fallará con AssertionError porque el archivo no se puede eliminar.

  def main(args : Array[String]) : Unit = {

    val myFile = new File("c:/tmp/doodah.txt")
    var src = Source.fromFile(myFile)
    src.getLines.foreach(l => print(l))

    val deleted: Boolean = myFile.delete

    assert (deleted , "File was not deleted - maybe the stream hasn''t been closed in Source")

  }

La fuente tiene un método llamado reset sin embargo, todo lo que hace es recrear la fuente del archivo.

Internally Source crea un BufferedSource subyacente que tiene un método de close . Sin embargo, esto no está expuesto desde la Fuente.

Espero que Source libere el identificador de archivo una vez que se haya leído el contenido del archivo, pero parece que no lo hace.

La mejor solución que he visto hasta ahora es esencialmente convertir la Source en una Source BufferedSource y llamar al close .

try {
  src.getLines.foreach(l => print(l))
}
finally src match { case b: scala.io.BufferedSource => b.close }

Alternativamente, podría crear una Source desde un InputStream y administrar el cierre por mí mismo.

Sin embargo esto parece algo sucio . ¿Cómo se supone que debes liberar el identificador de archivo cuando usas Source ?

Answer 1

Funciona en Scala 2.8.x con una pequeña modificación. "getLines" -> "getLines ()"

...
src.getLines().foreach(l => print(l))
...

scala.io.Source en 2.8.x está mejor pensado que su contraparte en 2.7.x y cierra el InputStream correctamente.

Answer 2

Por lo que puedo decir, io.Source aún no funciona en 2.8 (las conexiones se filtran, etc.), por lo que se debe disuadir a la gente de que lo use.

Como David sugirió anteriormente, hasta que se fusione la biblioteca de reemplazo http://github.com/scala-incubator/scala-io (probablemente después de 2.8), la mejor opción es retransmitir bibliotecas de java puro como apache commons-io, etc.

Answer 3

Scala.io._ es un hack de barebones creado con el único propósito de admitir la biblioteca XML y el compilador. Está mal diseñado y sufre de muchos problemas. Scala 2.8 significará una versión mejorada de él, aunque casi nada para destacar.

Hay un esfuerzo continuo de terceros por parte de las partes interesadas para desarrollar una biblioteca de Scala I / O. Su objetivo es llevar a casa las lecciones aprendidas por el rediseño de E / S de JDK7, mientras proporciona una API de Scala-ish.

Mientras tanto ... use las bibliotecas de Java siempre que su aplicación tropiece con los problemas de diseño de la biblioteca actual.