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

[Alan Bateman]

On 19/08/2021 05:27, Alex Buckley wrote:
> :
>
> - 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."

native.encoding is an important part of the story for applications that 
do interop with native applications. It can also plays a key role for 
applications that want to target a very wide range of JDK releases. So I 
think the JEP does need to describe it. The sentence "That is, 
essentially, ..." can be dropped. The paragraph that follows the list of 
properties can focus on file.encoding. We can introduce a new paragraph 
to show native.encoding can be used.

-Alan