duoduobingbing commented on PR #4321:
URL: https://github.com/apache/netbeans/pull/4321#issuecomment-1179761900
As I am basically left in the rain; let's wrap this up.
Where would a proper and open-minded discussion lead eventually?
First of all:
* What is the problem?
The Problem is that the Netbeans encoding does not reflect the console's
encoding in certain cases.
* Why does the problem occur?
Because Netbeans uses `native.encoding` now, which does not necessarily
reflect the console's encoding.
* What was my solution?
Let the user set the Output encoding manually via a custom property.
* Why is this not the most desirable solution?
Because such a custom property would have a very low discoverability for
affected users.
* What did JEP400 do and why did
[PR#3836](https://github.com/apache/netbeans/pull/3836) help with that?
JEP400 set the default encoding that is reported via
`Charset.defaultEncoding()` and `file.encoding` to `UTF-8`. But this is not the
only change. Previously the output encoding matched `file.encoding` but as of
JDK18+ it matches `sun.stdout.encoding`. Before PR#3836 Netbeans used
`Charset.defaultEncoding()` implicitly to determine the output encoding. This
of course failed with JDK18 when `sun.stdout.encoding` and `file.encoding`
mismatched.
* What would be the proper checking order for the output encoding?
Quoting from [JEP400](https://openjdk.org/jeps/400):
> 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).
So `native.encoding` is in fact not the right property to check for output
encoding. The order thus should have been: `Console.charset()` →
`sun.stdout.encoding` → `native.encoding` → `Charset.defaultEncoding()`
* Is this a Windows only problem? Actually it is not. It occurs as soon as
the platform default encoding (`native.encoding`) does not match the
console's/terminal's encoding. Here is an
[example](https://github.com/elastic/elasticsearch/issues/82939), albeit not a
Netbeans one. I really do not get the insistence that the "default console
encoding" is of any importance. To output to the console the console's
*current* encoding instead of its default encoding should be used.
[This link](https://bugs.eclipse.org/bugs/show_bug.cgi?id=579383) shows how
it has been handled by the Eclipse IDE.
But despite my findings that `Console.charset()`/`sun.stdout.encoding`
should be used instead of `native.encoding` to match the behavior introduced by
JEP400, I will close this PR, as I think nobody really cares that
`native.encoding` only works most of the time but not for all cases as it is in
fact the wrong property to infer the output encoding from.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
