Platform: Windows Server 2012 R2 with Simplified Chinese.
Java: JDK14
openjdk version "14-ea" 2020-03-17
OpenJDK Runtime Environment (build 14-ea+11-371)
OpenJDK 64-Bit Server VM (build 14-ea+11-371, mixed mode, sharing)

On Command Prompt window,
I used following test program and set EURO SIGN character for argument.

====== ArgTest.java ======
import java.util.Arrays;
import java.nio.charset.Charset;

public class ArgTest {
    public static void main(String[] args) {
        System.out.println("file.encoding="+System.getProperty("file.encoding"));
        System.out.println(Charset.defaultCharset().name());
        System.out.println(Arrays.toString(args));
    }
}
=======

======= Output =======
>jdk-14\bin\java ArgTest €
file.encoding=GBK
GBK
[?]
=======

EURO SIGN can input wiht Alt key with NumPad 0128 on Windows Command Prompt
(Press Alt key and keep it, Type Numpad 0, Type Numpad 1, Type Numpad 2, Type Numpad 8, Release Alt key)

It seems GBK charset cannot handle Euro Sign (0x80), MS936 charset can handle Euro Sign.
======
>jdk-14\bin\jshell
| Welcome to JShell -- Version 14-ea
| For an introduction type: /help intro

jshell> byte[] ba = new byte[]{(byte)0x80};
ba ==> byte[1] { -128 }

jshell> new String(ba,"GBK");
$2 ==> "?"

jshell> new String(ba,"MS936");
$3 ==> "€"

jshell> /exit
| Goodbye
======

Same kind of issue was reported and it said it was already resolved by Java 7.
  euro sign failed to be printed in Console on Localized Windows platform with GBK encoding
  https://bugs.openjdk.java.net/browse/JDK-6299219

Is there any historical reason about above implementation ?