RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Joe Wang" <huizhe.wang at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "nio-dev" <nio-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 27 Avril 2018 21:21:01
> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

> Hi Rémi, Alan,

Hi Joe,

> 
> I'm not sure we'd want to replace system dependent line separators with
> '\n'. There are cases as you described where the replacement makes
> sense. However,  there are other cases too. For example, the purpose is
> to read, edit a text file and then write it back. If this is on Windows,
> and if line separators are replaced with '\n', that would cause the
> resulting file not formatted properly in for example Notepad. There are
> cases where users write text files on Windows using Java, and only found
> the lines were not separated in Notepad.

I agree that why the counterpart of readString() that write the string should inserts the platform's line separator.
BTW, i just found that those methods are not named writeString, or writeCharSequence, i think they should.

> 
> Files.write(Path, Iterable) is also specified to terminate each line
> with the platform's line separator. If readString does the replacement,
> it would be inconsistent.


Anyway, if we look for consistency the methods writeCharSequence should transform the \n in the CharSequence to the platform's line separator.

Files.write(Path, Iterable) is is not a counterpart of readString(), it's consistent with Files.lines() or Files.readLines() (or BufferedReader.readLine()) that all suppress the line separators. Anyway, Files.write(path, readString(path)::line) will be consistent if you replace the line separators or not because String.line() suppresses the line separators.

> 
> I would think readString behaves like readAllBytes, that would simply read all content faithfully.

readString does an interpolation due to the Charset so it's not the real content, again, the idea is that developers should not have to care about the platform's line separators (they have more important things to think).

The other solution is to just not introduce those new methods, after all Files.lines().collect(Collectors.joining("\n")) already does the job, no ?

> 
> Best,
> Joe

regards,
Rémi

> 
> On 4/27/2018 4:43 AM, forax at univ-mlv.fr wrote:
>> Hi Alan,
>>
>> People do not read the documentation.
>> So adding something in the documentation about when a method should be used or
>> not is never a solution.
>>
>> Here the user want a String and provides a charset so you have no way but to
>> decode the content to substitute the line separator.
>>
>> cheers,
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Alan Bateman" <Alan.Bateman at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>, "Joe Wang" <huizhe.wang at oracle.com>
>>> Cc: "nio-dev" <nio-dev at openjdk.java.net>, "core-libs-dev"
>>> <core-libs-dev at openjdk.java.net>
>>> Envoyé: Vendredi 27 Avril 2018 13:34:12
>>> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for
>>> reading/writing a string from/to a file
>>> On 27/04/2018 12:29, Remi Forax wrote:
>>>> I think that having a readString that includes OS dependent line separators is a
>>>> mistake,
>>>> Java does a great job to try to shield the developer from the kind of things
>>>> that makes programs behave differently on different platforms.
>>>>
>>>> readString should subtitute (\r)?\n to \n otherwise either people will do a call
>>>> replace() which is less efficient or will learn the lesson the hard way.
>>>>
>>>> raw string literal does the same substitution for the same reason.
>>>>
>>> Yes, there are several discussion points around this and somewhat timely
>>> with multi-string support.
>>>
>>> One thing that I think Joe will need in this API is some note to make it
>>> clearer what the intended usage is (as I think the intention is simple
>>> cases with mostly single lines of text).
>>>
> >> -Alan.