It seems like you haven't complained loud enough :)
On Fri, Dec 11, 2015 at 6:00 PM, Martin Buchholz <marti...@google.com> wrote: > IIRC I complained about sun.jnu.encoding "not working right" 10 years ago ... > > On Fri, Dec 11, 2015 at 8:53 AM, Volker Simonis > <volker.simo...@gmail.com> wrote: >> Hi, >> >> is setting -Dsun.jnu.encoding from the command line supposed to work >> (i.e. if it should have any impact)? >> >> I'm just asking, because currently it doesn't make any difference. >> While the command line arguments get parsed very early during VM >> startup in Arguments::parse_each_vm_init_arg() they are only added to >> the actual list of system properties later when >> Java_java_lang_System_initProperties() (at System.c:398) calls >> JVM_InitProperties(): >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V [libjvm.so+0xe50cfc] set_property(Handle, char const*, char >> const*, Thread*)+0x30 >> V [libjvm.so+0xe510ec] JVM_InitProperties+0xff4cd404 >> C [libjava.so+0x25860] >> Java_java_lang_System_initProperties+0xfffc3d50 (System.c:398) >> j >> java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 >> j java.lang.System.initializeSystemClass()V+13 >> v ~StubRoutines::call_stub >> V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x628 >> V [libjvm.so+0x11500d0] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 >> V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*)+0xb4 >> V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c >> V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x7c >> V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 >> V [libjvm.so+0x13656a4] >> Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 >> V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 >> V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, >> void*)+0x100 >> V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c >> C [libjli.so+0x108e4] InitializeJVM+0x1b4 >> C [libjli.so+0xda54] JavaMain+0xcc >> >> Unfortunately that's a little too late, because the "sun.jnu.encoding" >> property is already set just at the beginning of >> Java_java_lang_System_initProperties() (in System.c:189) by calling >> GetJavaProperties() which in turn sets the property to the value >> detected by ParseLocale(). This finally is either the result of >> setlocale(LC_CTYPE, NULL) on Unix or "UTF-8 on MacOS X. >> >> C [libjava.so+0x2d734] ParseLocale+0x34 >> C [libjava.so+0x2e070] GetJavaProperties+0x220 >> C [libjava.so+0x211d8] >> Java_java_lang_System_initProperties+0xfffbf6c8 (System.c:189) >> j >> java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 >> j java.lang.System.initializeSystemClass()V+13 >> v ~StubRoutines::call_stub >> V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x628 >> V [libjvm.so+0x11500d0] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 >> V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*)+0xb4 >> V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c >> V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x7c >> V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 >> V [libjvm.so+0x13656a4] >> Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 >> V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 >> V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, >> void*)+0x100 >> V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c >> C [libjli.so+0x108e4] InitializeJVM+0x1b4 >> C [libjli.so+0xda54] JavaMain+0xcc >> >> But between the calls to GetJavaProperties() and JVM_InitProperties() >> the jdk already initializes the platform encoding ('fastEncoding' or >> 'jnuEncoding' in jni_util.c) when it first calls >> JNU_NewStringPlatform(): >> >> #0 initializeEncoding () at jni_util.c:626 >> #1 JNU_NewStringPlatform () at jni_util.c:727 >> #2 GetStringPlatform () at java_props_md.c:601 >> #3 Java_java_lang_System_initProperties () at System.c:371 >> >> There it evaluates the value of the "sun.jnu.encoding" property (which >> was taken from the the result of setlocale(LC_CTYPE, NULL) in >> ParseLocale()). These values aren't changed any more after the value >> of "sun.jnu.encoding" will be changed trough the call of >> JVM_InitProperties() to the value set from the command line. >> >> Is this the way how it is supposed to work? >> >> I personally think it would be useful to be able to change >> "sun.jnu.encoding" from the command line (even if this would be only >> used for testing). But that would probably mean that we would have to >> already handle -Dsun.jnu.encoding specially in the launcher. What do >> you think? >> >> Regards, >> Volker