Hello everyone, Neil referred me to this list.
I raised Issue [#4261](https://github.com/apache/netbeans/issues/4261). What is the core problem? The Netbeans output encoding does not always reflect the encoding of System.out resulting in garbled output. There are case where the value of native.encoding does not reflect the console's encoding/System.out. Why does this matter, especially with JDK18? Quote from JEP400 > We will update the specifications of all standard Java APIs that use the > default charset to cross-reference Charset.defaultCharset(). Those APIs > include the ones listed above, but not System.out and System.err, whose > charset will be as specified by > [Console.charset()](https://bugs.openjdk.java.net/browse/JDK-8264208). JEP400 changes the place where the encoding of System.out is derived from. In JDK17 and lower it used file.encoding/Charset.defaultEncoding() but since JEP400 Console.charset()/sun.stdout.encoding is used. [PR#3836](https://github.com/apache/netbeans/pull/3836) partially fixed this problem by using native.encoding for the Netbeans output. This worked because native.encoding matches Console.charset()/sun.stdout.encoding most of the time. However there are cases where this not the case. If one is affected by such a case there is no way to change the Netbeans output encoding as native.encoding is not settable from the commandline. My initial idea was to introduce a custom property that affected users could set to get the desired output encoding. However I realized that this may not be the best solution as such a property would provide a low discoverbility for affected users. My next idea was to change the order by which the encoding is inferred to the behavior introduced by JEP400. This would result in first checking Console.charset()/sun.stdout.encoding thennative.charset and as a fallback for JDK16 and lower Charset.defaultEncoding()/file.encoding Neil said that best place to discuss a fix to Issue #4261 would be this mailing list, hence this mail. Thanks, Bing
