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

[Roger Riggs]

On Thu, 29 Apr 2021 13:06:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I suspect that if setProperty("native.encoding", "foo") succeeds, then it will return "foo".   I also believe that a later invocation of getProperty("native.encoding") will also return "foo".  If that's the case, then I don't think that the "read-only" alternative phrasing is correct.  To me, the alternative suggests that an error will be return if there is an attempt to set it or that the potential new value will be ignored.  The "no effect" phrasing avoids this problem.   I also suspect that the "no effect" phrasing was selected to align with the apiNote in lines 719-721.
>
> Thanks, Joe and Iris. I agree with Iris and that's the reason I chose the description. System properties are inherently mutable. There are some "protected" ones, by that I mean a private copy is made just after initialization for VM use, which is not affected by later setProperty() calls. But I don't think this new property should be treated as such.

The value of native.encoding should be a static property; that is, read once at startup and later modification
does not change the behavior of the Java runtime.

Whereas the value of native.encoding is derived from the value of native variables and those native
values do not change while Java is running, I think the behavior of the Java runtime should stay the same.
Unless it is static, the Java runtime will need to read the property every time it is needed and behavior can
change from call to call and actions in one thread can affect other threads.
Is there a use case where the application needs to change the encoding for every use in the Java runtime
independently of the native values.
Such an application should be explicit about its charset requirements and use APIs to select them explicitly.

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

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