On Sat, 19 Aug 2023 09:05:47 GMT, Glavo <[email protected]> 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
