JEP proposed to target JDK 18: 400: UTF-8 by Default
alex.buckley at oracle.com
Thu Aug 19 04:27:58 UTC 2021
- "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
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.
> 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 ...
More information about the jdk-dev