JEP proposed to target JDK 18: 400: UTF-8 by Default

[Alex Buckley]

Some nits:

- "especially [a word is missing here] the property is set after"

- Re: "... change the specification of Charset.defaultCharset() to say 
that the default charset is UTF-8 ***unless configured otherwise by an 
implementation-specific means***" -- is the starred text alluding to 
this: "we will revise the treatment of the file.encoding property so 
that _setting it on the command line is a supported means of configuring 
the default charset_" ? If there's a connection, please acknowledge it 
via something like "... an implementation-specific means. (The JDK 
supports configuring the default charset once, at startup, by setting a 
system property on the command line; see below.)"

- If `native.encoding` is new in 17, then it's a surprise to see the 
following text which suggests `native.encoding` is something that people 
have long relied upon: "native.encoding is public and ***there is no 
change in its behavior***"  Also, "is public" should be "is standard".

- Re: "This is, essentialy [spelling error], equivalent to file.encoding 
unless it is overridden on the command line." -- what is "it" ? A reader 
can easily think "it" means native.encoding. (Such a reader will be 
confused because System::getProperties apparently prohibits "overriding" 
native.encoding via "Setting this system property has no effect.") I 
believe the message here is that native.encoding is equivalent to 
file.encoding unless file.encoding is (new!) set on the command line. I 
think you would be better off unpicking native.encoding from the story: 
drop its bullet; don't mention "i.e., to the value of native.encoding" 
in the file.encoding=COMPAT bullet; and say after the final 
file.encoding bullet that "We introduce native.encoding as a standard 
way to detect the charset chosen by the JDK's algorithm, regardless of 
whether the default charset is actually configured to be that charset. 
If file.encoding is set to COMPAT on the command line, then the run-time 
value of file.encoding will be the same as the run-time value of 
native.encoding; if file.encoding is set to UTF-8 on the command line, 
then the run-time of file.encoding may differ from the run-time value of 
native.encoding."

Alex

On 8/18/2021 2:21 PM, Naoto Sato wrote:
> Thanks, Alex.
> 
> Yes, distancing from FileReader/Writer would make the removed sentence 
> stand. And the next sentence reads better with the developer focus. 
> Modified as suggested.
> 
> Naoto
> 
> On 8/18/21 1:47 PM, Alex Buckley wrote:
>> On 8/18/2021 12:48 PM, Naoto Sato wrote:
>>> On 8/18/21 10:03 AM, Remi Forax wrote:
>>>> A minor comment, there is a sentence in the JEP that is weird.
>>>>
>>>> "However, having to pass an argument prevents these methods from 
>>>> being used via method references (::) in stream pipelines."
>>>>
>>>> You can not use these methods in a Stream anyway because they are 
>>>> declared with "throws IOException", so this argument does not hold.
>>>> I think this sentence should be removed.
>>>
>>> Thanks. Removed the sentence.
>>
>> There is now a dangling paragraph -- "Developers familiar with such 
>> hazards can use methods that take a charset argument explicitly." -- 
>> whose words undermine the case for having a default charset at all.
>>
>> I recommend preserving the complaint about having to pass an argument, 
>> but rephrasing it to be less connected to the specific 
>> FileWriter/FileReader APIs in the prior paragraph (after all, there 
>> are ctors in Formatter and Scanner which use the default charset and 
>> don't throw IOException) :
>>
>> -----
>> Developers familiar with such hazards can use methods and constructors 
>> that take a charset argument explicitly. However, having to pass an 
>> argument prevents methods and constructors from being used via method 
>> references (::) in stream pipelines.
>>
>> [Swapped first two words, to continue the Developer theme] Developers 
>> sometimes attempt to set the default charset via ...
>> -----
>>
>> Alex