Is setting -Dsun.jnu.encoding from the command line supposed to work?

[Volker Simonis]

It seems like you haven't complained loud enough :)


On Fri, Dec 11, 2015 at 6:00 PM, Martin Buchholz <martinrb at 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.simonis at 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