Re: JEP proposed to target JDK 18: 400: UTF-8 by Default
On 19/08/2021 07:40, Alan Bateman wrote: Yes, if there is code that really wants to use the native encoding and run of wide range of JDK releases without the using COMPAT then it can read the value of native.encoding and use Charset.defaultCharset if the property is not set. -Alan. Thanks for this suggestion. This should work for my situation. Simon
Re: JEP proposed to target JDK 18: 400: UTF-8 by Default
On 18/08/2021 22:44, Naoto Sato wrote: On 8/18/21 2:03 PM, Simon Nash wrote: I am the developer of a fairly large application that uses file I/O extensively. In most cases, the charset should be UTF-8 and I have used an explicit charset parameter on all method invocations where this applies. In some cases, the charset needs to be the platform default charset to produce output that is readable by other programs or by a user (for example, Windows-1252 on some versions of Windows). In the cases that need the platform default charset, I have omitted the charset (intentionally, not carelessly or accidentally). If the behaviour changes in these cases, it will produce unexpected results for users. In preparation for JEP 400, we have provided a new system property that retrieves the native encoding name in JDK17: https://bugs.openjdk.java.net/browse/JDK-8265989 Apps that have luxury to make code base change can use the property to retrieve the native encoding, then use it to replace no-arg I/O constructors to the explicit equivalent ones. Yes, if there is code that really wants to use the native encoding and run of wide range of JDK releases without the using COMPAT then it can read the value of native.encoding and use Charset.defaultCharset if the property is not set. -Alan.
Re: JEP proposed to target JDK 18: 400: UTF-8 by Default
On 8/18/21 2:03 PM, Simon Nash wrote: I am the developer of a fairly large application that uses file I/O extensively. In most cases, the charset should be UTF-8 and I have used an explicit charset parameter on all method invocations where this applies. In some cases, the charset needs to be the platform default charset to produce output that is readable by other programs or by a user (for example, Windows-1252 on some versions of Windows). In the cases that need the platform default charset, I have omitted the charset (intentionally, not carelessly or accidentally). If the behaviour changes in these cases, it will produce unexpected results for users. In preparation for JEP 400, we have provided a new system property that retrieves the native encoding name in JDK17: https://bugs.openjdk.java.net/browse/JDK-8265989 Apps that have luxury to make code base change can use the property to retrieve the native encoding, then use it to replace no-arg I/O constructors to the explicit equivalent ones. I could try to find all the method invocations that currently use the implicit default charset, although I have no idea how to do this other than reading every line of code. The problems with this are 1) that I would almost certainly miss some invocations that need to be changed and 2) more seriously, from what I have seen in the JEP I don't think there is a way to update these method invocations that works exactly as at present on all versions of Java back to JDK 8 and provides the same behaviour on JDK 18. This is because (as far as I can tell) there is no API call that returns the "old-style" platform default charset and can be used on all JDK versions from JDK 8 to JDK 18. Adding a -D option when the application is started isn't possible in some contexts such as launching the application from a Windows executable jar file association. If I could make a single API call when the application is first started to force backward-compatible behaviour in all cases, this would solve the problem. This feels very much like a "hack" and I would much prefer a clean solution but it would be better than nothing. I am reluctant to provide such a single API call which has the same effect as `COMPAT`, as it will become less meaningful when UTF-8 as default sinks in. Naoto
Re: JEP proposed to target JDK 18: 400: UTF-8 by Default
On 18/08/2021 20:49, Naoto Sato wrote: Hi Simon, Please post your comments at core-libs-dev mailing list, where the discussion should take place. Naoto My apologies that I am late into the discussion of this JEP. I am the developer of a fairly large application that uses file I/O extensively. In most cases, the charset should be UTF-8 and I have used an explicit charset parameter on all method invocations where this applies. In some cases, the charset needs to be the platform default charset to produce output that is readable by other programs or by a user (for example, Windows-1252 on some versions of Windows). In the cases that need the platform default charset, I have omitted the charset (intentionally, not carelessly or accidentally). If the behaviour changes in these cases, it will produce unexpected results for users. I could try to find all the method invocations that currently use the implicit default charset, although I have no idea how to do this other than reading every line of code. The problems with this are 1) that I would almost certainly miss some invocations that need to be changed and 2) more seriously, from what I have seen in the JEP I don't think there is a way to update these method invocations that works exactly as at present on all versions of Java back to JDK 8 and provides the same behaviour on JDK 18. This is because (as far as I can tell) there is no API call that returns the "old-style" platform default charset and can be used on all JDK versions from JDK 8 to JDK 18. Adding a -D option when the application is started isn't possible in some contexts such as launching the application from a Windows executable jar file association. If I could make a single API call when the application is first started to force backward-compatible behaviour in all cases, this would solve the problem. This feels very much like a "hack" and I would much prefer a clean solution but it would be better than nothing. Does this JEP provide some way to do what I need? Simon
