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
