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