RFR: 8300916: Re-examine the initialization of JNU Charset in StaticProperty [v4]

[Ichiroh Takiguchi]

On Wed, 25 Jan 2023 18:58:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `Charset.defaultCharset()` now uses `standardProvider.charsetForName(<file.encoding>)` charset.
>
>> `Charset.defaultCharset()` now uses `standardProvider.charsetForName(<file.encoding>)` charset.
> 
> I think this is the right thing to do. It can also be changed to use StaticProperty.fileEncoding() and maybe the field can be changed to be a `@Stable` field. 
> 
> It might be that we will need to create a CSR and Release Note for this change.  The scenario is PR 12132 is unfortunate but does not show that some deployments may have been relying on the this from JDK 9 to JDK 17. With the change here, we are doubling now on ensuring that the default charset is loaded from java.base.

Hello @AlanBateman 
You said

> The change to StaticProperty to avoid calling out to Charset.defaultCharset from the initializer is good. However, the other part to that is the scenario in PR 12132 where the default Charset was accidentally located via the provider mechanism in JDK 9-17. If I read the changes correctly, that fragile scenario will come back. We have a couple of ways to avoid that, one being to ensure that defaultCharset is called before the boot layer is set. A simpler, and more reliable, would be to change Charset.defaultCharset to use standardProvider.charsetForName with the value of "file.encoding", and avoid the provider lookup completely.

Could you explain about fragile scenario ?

-------------

PR: https://git.openjdk.org/jdk/pull/12171