RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

Volker Simonis volker.simonis at gmail.com
Tue Jul 28 16:51:38 UTC 2015

Hi Jonathan, Alan,

this is a known problem and we've already discussed it intensively.

Please have a look at:

8081674: EmptyStackException at startup if running with extended or
unsupported charset


8087161: Fails to start up initialize system class loader running on
unsupported charset

8081674 has a long discussion and also detailed description on how
this can be reproduced.
@Jonathan: the problem with your test case is that it is not enough to
only set the appropriate locale, you also have to make sure that the
locale is installed (see bug discussion for more details). 8081674
finally only fixed a part of the problem and left the rest for

The mailing list thread about this issue can be found here:


As your bug is an exact copy of 8087161 I've closed it as duplicate.


On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 28/07/2015 10:50, 陆传胜(传胜) wrote:
>> Hello,
>> The issue
>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>> default,
>> a simple
>> patch was made to fix it, may I have it reviewed ?
>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
> I hope Sherman will have time to look at this and say whether GB18030 is
> supposed java.base and so be listed in
> jdk/make/data/charsetmapping/stdcs-linux.
> My concern with this change is that it's bringing back code that was
> deliberately removed as part of JDK-8038310. We want clean separation of the
> java.base and jdk.charsets modules so that charsets that are needed for
> startup in supported locales to be in java.base. Anything that is not needed
> in java.base goes to jdk.charsets and is loaded via the extended charset
> provider.
> -Alan.

More information about the core-libs-dev mailing list