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

Martin Buchholz martinrb at google.com
Fri Dec 11 17:00:05 UTC 2015


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



More information about the core-libs-dev mailing list