Is it better to use import scala.reflect.io.File or java.io.File in Scala?

Question

I see the scala.reflect.io.File class, is this supposed to help with file operations? Am I supposed to prefer to use this rather than java.io.File? What is the purpose of this class?

Mixed

The package scala.reflect.io is not even in the ScalaDoc pages, so I suspect it's for internal use only. – Abner

How about java.nio.file.Files.write? – Mixed

Answer 1

Neither, you're supposed to use java.nio.file, of course.

If you want to "enhance" that API with fancy operators, use extension methods. The author of that code has said as much on the mailing list. Being stuck on Java 6 is considered unfortunate.

The package you're pointing to was pulled into the scala-reflect.jar to support reflection, but warnings are everywhere about its unsupported status.

The AbstractFile abstraction is used by Position, which has a source file. The "file" you get from that is a java.io.File, but AbstractFile has factory methods that take the reflect.io.Path abstraction (with File and Directory subtypes). So all that code remains packaged together.

I have to stop and think every time AbstractFile and File cross my path (pun alert). I used to have a purple "AbstractFile is, like, totally different from File" t-shirt, but it wore out with multiple washings.

On the back it said, "Position has nothing to do with io.Position."

Here is the warning as it touches api.Position, where of course it is user-facing in the scaladoc; notice it says it is a "Java file":

  /** Java file corresponding to the source file of this position.
   *
   *  The return type is `scala.reflect.io.AbstractFile`, which belongs to an experimental part of Scala reflection.
   *  It should not be used unless you know what you are doing. In subsequent releases, this API will be refined
   *  and exposed as a part of scala.reflect.api.
   *
   *  @group Common
   */
  def source: scala.reflect.internal.util.SourceFile

To answer your first question, I think it's safe to say, Yes, it was supposed to help.

Potion

Answer 2

You shouldn't use scala.reflect.io package for two reasons:

• it's intended for internal use of reflection code (e.g. is hidden from scala doc)
• This is library is considered experimental and should not be used unless you know what you are doing.

Here's the standard api provided for file access: scala.io.Source (companion Object, not Class)

import scala.io.Source

val source = Source.fromFile(fileNameString)("UTF-8")
// returns collection.Iterator[String]:
val lines = source.getLines()
// Now do something with lines ...
source.close()

java.nio features Channels and ByteBuffers: reads/writes occur via active background threads which are implicitly managed by the JVM. It's used for high performance (often high-volume) non-blocking I/O, not simple I/O. It reads in in chunks from a channel into buffers and requires the buffer to be parsed and processed.

java.io features Readers and Writers for reading/writing characters with internal encoding/decoding from text files and other sources. These provide some operations beyond Scala's Source object - hence, use these directly if you wish to do advanced operations not supported by Source. It also features InputStreams and OutputStreams for reading/writing raw data bytes from data files, sockets and other data sources.

Eagre

But that does not close the file, does it? – Axiom

No. Thanks for the hint, have added the close :) – Eagre

What if I need to represent a directory? Or move a file? I think Source is useful only when reading a file. – Lycian

Yes. That's what I'm showing above. scala.io is VERY barebones - vast majority of usage should be via java classes - and scala.reflect.io should never be used. – Eagre

Answer 3

java.io.File is what you should use in general.

scala.reflect.io.File can be used for file operations. Code using it idiomatic for scala than using Java's File class. This is because it uses other scala classes such as scala.io.Codec and scala.Option and utilizes scala features such as implicit parameter. However, it is not (and may never be) considered ready for general use.

According to the source for scala.reflect.io.File (github):

/**
* ''Note: This library is considered experimental \
     and should not be used unless you know what you are doing.''
*/

If you know what you are doing or are just wanting to experiment (and do not care if things don't work or break in the future) then you may decide to use scala.reflect.io.File. If you do decide to use it, the source code looks well documented with ScalaDoc comments.

Brandiebrandise