RFR: 8317246: Cleanup java.net.URLEncoder and URLDecoder use of file.encoding property

[Claes Redestad]

On Sat, 19 Aug 2023 09:05:47 GMT, Glavo <duke at openjdk.org> wrote:

> `DEFAULT_ENCODING_NAME ` in `URLEncoder` and `URLDecoder` can be replaced with `Charset.defaultCharset()`, which removes unnecessary static fields and avoid looking up charset when calling `URLDecoder.decode(String)` and `URLEncoder.encode(String)`.
> 
> This PR is trivial, since `Charset.defaultCharset()` is also initialized with `StaticProperty.fileEncoding()`, this causes no change in behavior. 
> 
> Moreover, the javadoc of `URLDecoder.decode(String)` and `URLEncoder.encode(String)` say that they use the default charset, so this change is semantically consistent with the documentation.

I'm not sure this is advisable. The `StaticProperty.fileEncoding()` value is fixed during startup to the platform native encoding and can't be overridden like `defaultCharset()` so I think this will have subtle compatibility implications. What gain - if any - do you see from this?

There are mysterious interactions with `-Dfile.encoding=COMPAT` and `native.encoding` that I don't fully understand, but it does seem odd that `URLDecoder/-Encoder` rely directly on the `StaticProperty.fileEncoding()` string. I'll have to defer to @RogerRiggs and @AlanBateman if changing to `Charset.defaultCharset()` is appropriate or not.

Right, this only affects deprecated methods, so it's unclear who'd benefit. A little less code and a couple of constants less is nice, I guess.

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

PR Comment: https://git.openjdk.org/jdk/pull/15353#issuecomment-1725729616
PR Comment: https://git.openjdk.org/jdk/pull/15353#issuecomment-1729204137
PR Comment: https://git.openjdk.org/jdk/pull/15353#issuecomment-1729267531