java.io.Inputs and java.io.Ouputs

[Rémi Forax]

Alan Bateman a écrit :
> Rémi Forax wrote:
>> Hi alan, hi all,
>> Wow, I think its a very good idea to introduce static methods
>> for reading/writing lines.
>>
> Thanks for noticing. I've been meaning to some utility classes for 
> this for some time as it's an area that many developers get annoyed with.
>
>>
>> - Providing a closeUnchecked is a good idea but i don't see
>>  why readAllBytes*() need use it.
> It doesn't matter too much, but I agree that it would be better to 
> invoke close directly.
>
>> - characters based method readAllLines/writeLines() should have
>>  a variation that takes a Charset  as  parameter.
>>  It will avoid to use Charset.defaultCharset().name() in some 
>> writeLines().
>>  Btw, readAllLines and writeLines is not a coherent naming scheme,
>>  in my opinion, writeLines should be rewritten writeAllLines.
> There is a version of each method, one that takes the charset (as a 
> String), and the other that uses the default charset. I don't have any 
> objection to a third variant that specifies the charset as a Charset 
> (the other obvious one is a variant that specifies the CharsetDecoder 
> but I wouldn't expect the average developer to use it).
I agree.

There is an implementation problem in Inputs because Scanner doesn't 
take a Charset
but a String. I've send a bug file. There is no such problem in Output 
because
InputStreamWriter and Channels.newWriter() takes a Charset
(a CharsetEncoder in case of Channels.newWriter())
>
>>
>> - readAllLines should be lazy, i.e. returns an Iterable<String>,
>>  its iterator should close the stream when hasNext() return false.
>>  I think Python already do something like that.
> I don't think this is feasible here. There is no guarantee that the 
> user will iterate to the end (due to an exception for example). Also, 
> there is no guarantee that the source will remain accessible. For 
> example, somebody might want to read all the lines from a text file 
> and delete the file immediately. Also, if the InputStream is to a 
> network resource (a http connection for example) then I/O would need 
> to be exposed by the iterator.
I suppose we have to wait closures :)
>
>>
>> - writeLines should take an Iterable<? extends CharSequence> instead
>>  of a List<String>,  implwriteLines() should be re-written :
>> for (CharSequence line: lines) {
>>  writer.write(line.toString());
>>  writer.newLine();
>> }
> Making it more general is a good idea.
ok
>
>>
>> A more general question, how about word based read methods ?
> I'm not sure about this because it is locale sensitive. An alternative 
> might be some improvements to the java.text package that could be used 
> in conjunction with the java.io package. This is an area we would need 
> to discuss with the i18n group.
ok, I will do that later.
>
>>
>> I am a commiter on another OpenJDK workspace,
>> so if you want I think I  am able to create a patch,
>> ask for reviews and if it's ok, push the patch.
> Got for it!
>
> -Alan.
Rémi