Why is threre not a Files.readAllLines(String path) in java 7? [closed]

Question

I'm tryting to learn the nio 2 package in Java 7 and i stumbled upon the Files.readAllLines(Path p, Charset cs) method. I find it very useful, but i'm of the opinion that there should be a version without the cs parameter, just like :

 public static List<String> readAllLines(String path)
    throws IOException
{ return readAllLines(Paths.get(path), Charset.defaultCharset());}

I convinced that most of the time the method will be called with the default Charset anyway, so why no the shorcut. Is there anything i'm missing about charsets that would justify not having this method? I'm quite surprised because Scala has this option:

Source.fromFile("fileName").getLines

so i don't see why Java shouldn't. Any views?

Frodeen

Perhaps they wanted to discourage using the default charset, or they wanted to minimise the number of methods added. – Allergen

Too bad the downvoter didn't comment why – Outstand

Assuming default character sets is what got the universe into character encoding hell to begin with. – Schaerbeek

@OliverStutz, maybe he was one of the nio2 developers :) – Frodeen

News flash: readAllLines(String path) was added in Java SE 8, and the assumed charset is always UTF-8. – Mneme

Answer 1

[...] most of the time the method will be called with the default Charset anyway,

Not really. Most of the time it will be called with the charset that you expect the file to be encoded in. Typically these days it is UTF-8:

Files.readAllLines("fileName", StandardCharsets.UTF_8)

Your application can be executed on several platforms and operating systems, using different default character encoding. You don't want your application to break just because of that.

I think it's a good choice, fixing wrong desing decisions from the past. Many old Java methods use default system encoding, causing inconsistent behaviour or application e.g. between Windows and Linux. Forcing to choose the character encoding simply makes your application more portable and safer.

---

BTW since you are mentioning io.Source class - note that it returns an iterator instead of a List<String> as Files class does. The advantage: file is loaded lazily, not all at once to huge ArrayList<String>. Disadvantage: you must close the source manually (which you can't do in your code snippet).

Yazbak

+1 Really they ought to deprecate String.getBytes() without a charset and the like – Michael

Well, i'd say that the charset i expect the file to be encoded in is my default charset ( which is UTF_8 in my case anyway :) ). And if UTF_8 is in any case the most reasonable options, then they could have used that option as default – Frodeen

@Chirlo: +1, that's a fair assumption. But still I believe it's a good idea to make charset explicit. – Yazbak

let's then say i would wish for a Files.readAllLinesWithDefaultCharset(file) method :) It'd make a difference to me at least. Btw, +1 for the tip on io.Source. – Frodeen

Answer 2

You would have to ask the designers, but very probably they share my view that reading entire files into memory is not something to be encouraged. It does not scale, and it introduces unnecessary time and space costs. Process the file a line at a time.

Thug