java.nio.charset.UnsupportedCharsetException: cp0 on windows

[spyrkob]

I run into a following error when SSH'ing into WIndows and trying to run an app using picocli:

Exception in thread "main" java.nio.charset.UnsupportedCharsetException: cp0
        at java.nio.charset.Charset.forName(Charset.java:531)
        at picocli.CommandLine.charsetForName(CommandLine.java:15018)
        at picocli.CommandLine.getStderrEncoding(CommandLine.java:15013)
        at picocli.CommandLine.getErr(CommandLine.java:1310)
        at picocli.CommandLine.handleUnhandled(CommandLine.java:2189)
        at picocli.CommandLine.execute(CommandLine.java:2175)
        at CheckSum.main(CheckSum.java:33)

It seems that happens when code page is set to "0". The error can be reproduced when using a windows nonoserver docker image, e.g. using following Dockerfile:

FROM eclipse-temurin:8-nanoserver-1809
COPY demo.jar .
ENTRYPOINT java -jar demo.jar

I'm not sure if that should be treated in special way like cp65001 (#1474)?

[remkop]

I run into a following error when SSH'ing into WIndows and trying to run an app using picocli:

Exception in thread "main" java.nio.charset.UnsupportedCharsetException: cp0
        at java.nio.charset.Charset.forName(Charset.java:531)
        at picocli.CommandLine.charsetForName(CommandLine.java:15018)
        at picocli.CommandLine.getStderrEncoding(CommandLine.java:15013)
        at picocli.CommandLine.getErr(CommandLine.java:1310)
        at picocli.CommandLine.handleUnhandled(CommandLine.java:2189)
        at picocli.CommandLine.execute(CommandLine.java:2175)
        at CheckSum.main(CheckSum.java:33)

It seems that happens when code page is set to "0". The error can be reproduced when using a windows nonoserver docker image, e.g. using following Dockerfile:

FROM eclipse-temurin:8-nanoserver-1809
COPY demo.jar .
ENTRYPOINT java -jar demo.jar

I'm not sure if that should be treated in special way like cp65001 (#1474)?

@spyrkob Thank you for raising this!

Looking back at #1474, I can see that cp65001 is equivalent to UTF-8 on Windows, but Java does not recognize it as such. Hence, it is safe to use UTF-8 when picocli detects that system property sun.stderr.encoding has value cp65001.

What about cp0 though? What is the Java-equivalent charset for that code page?

In fact, is it valid for this windows nanoserver docker image to use CP0? Is this not a bug or misconfiguration in the windows nanoserver docker image? I am not convinced that picocli should introduce special code to work around this...

(I cannot find CP0 in the Windows code page entry. In the general code page Wikipedia entry I see it is "reserved", unsure that that means... I cannot find anything on Microsoft's web site. I have my doubts that this is a valid value.)

[spyrkob]

From what I was able to find, it seems code page 0 means the code page was not set at all - but I'm really not very familiar with Windows :). In case of nanoserver, it's not even possible to set them as chcp is removed. I think that should be treated in the same way as if sun.stdout.encoding was null.

As a side note - I first run into the same issue on a full Windows machine when SSH'ing into it but I was not able to come up with reliable reproducer.

[remkop]

From what I was able to find, it seems code page 0 means the code page was not set at all - but I'm really not very familiar with Windows :).

Oh interesting! Can you provide links to what you found?

In case of nanoserver, it's not even possible to set them as chcp is removed.

Does that mean that any java application in nanoservers will have code page zero? (If that is true, that sounds like a bug in nanoserver...)
Have you considered raising this issue to the nanoserver maintainers?

I think that should be treated in the same way as if sun.stdout.encoding was null.

How should a command line program behave when sun.stdout.encoding is null? That sounds rather fatal! :-)

[spyrkob]

After some more digging I have to say I'm getting increasingly confused by the code page 0 :). According to https://learn.microsoft.com/en-us/windows/console/getconsolecp 0 is an error, but looking at error details it seems that the operation was successfull. I asked a question on Microsoft Q&A hopefully there'll be some clarification

How should a command line program behave when sun.stdout.encoding is null? That sounds rather fatal! :-)

Just to clarify - by null I meant the property being not set. That seems to be a case OSX and Picocli already handles it.

jshell> System.out.println(System.getProperty("sun.stdout.encoding"))
null

jshell> System.out.println(System.getProperty("stdout.encoding"));
null

Let me ask a different question - why is the output charset handled differently in Picocli then in JVM?
When JVM is starting up the Console, if the charset requested by OS is invalid, it falls back to Charset.defaultEncoding() (Console.java). I would assume Picocli should behave in the same way. Or is there's a reason for the different treatment?

[remkop]

That’s a good suggestion (doing something similar to the Console example).

Makes sense to modify picocli to behave similarly, maybe with some added Trace logging at INFO level if the sun.stdout.encoding results in an exception, before falling back to the default charset.

Will you be able to provide a pull request for this?

[spyrkob]

Will you be able to provide a pull request for this?

Sure. Thanks for your feedback!