RFR: 8265989: System property for the native character encoding name

Maurizio Cimadamore mcimadamore at openjdk.java.net
Thu Apr 29 14:15:54 UTC 2021

On Thu, 29 Apr 2021 14:08:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Naive question: any reason as to why we're not providing a new static API method in Charset to return the platform encoder? This initially will return same thing as Charset.defaultEncoder - but as JEP 400 is delivered the two will diverge. Any reason as to why we don't want to expose the platform encoder in the API?

Ok, I see this is addressed in the CSR:

We converged on a system property out of concern that an API method for the native encoding would be confusing for many developers.

The problem with this approach is that I think clients that need the platform encoder will have to stash it somewhere in a static field (to prevent reading property and parsing value over and over). It might also be harder for javadoc (I'm thinking of some of the Panama API) to express a dependency on it.


PR: https://git.openjdk.java.net/jdk/pull/3777

More information about the core-libs-dev mailing list