pre-RFR (s): 8049847: Enhance PrintWriter line.separator handling

Claes Redestad claes.redestad at oracle.com
Mon Jan 5 15:26:12 UTC 2015


On 2015-01-05 10:51, Alan Bateman wrote:
> On 04/01/2015 20:29, Claes Redestad wrote:
>> For the record I would be very happy to update the implementation to use
>> System.lineSeparator() in PrintWriter/BufferedWriter rather than reading
>> line.separator, thus removing the unspecified behavior to be able to 
>> hack the
>> current implementation via manipulating system properties. This might 
>> break
>> some applications, but, as you imply, any such use case might already be
>> better accommodated by overriding the PrintWriter#println/printf/format
>> methods.
>>
>> How about closing this bug as WNF and filing a new RFE to remove the
>> PrintWriter/BufferedWriter constructor dependencies on line.separator?
>>
> I don't think it make sense to change the line.seperator property in 
> the main method or on the fly. The right thing it is to override the 
> newLine method as Sherman suggested. So if these constructors are 
> changed to use System.lineSeperator() and we document this behavior 
> change in release notes then it seems reasonable for a major release 
> (not for 8uX of course).

Sounds good to me.

>
> For printf/format/Formatter then having %n result in a call to 
> newLine() has some appeal. It's doable in Formatter but would require 
> a spec change.

If we do this (do we have to?), where do we expose the newLine? 
Currently Appendable is the only thing Formatter knows about, but I 
guess having it there has been declared distasteful. :-)

Having it in Writer and doing some checks and casts could work, I guess, 
just need to be careful not to impact performance much for non-Writer cases.

/Claes

>
> -Alan
>




More information about the core-libs-dev mailing list