On Wed, 25 Jan 2023 18:58:40 GMT, Alan Bateman <al...@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
