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

[Volker Simonis]

On Wed, Jul 29, 2015 at 5:53 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> On 7/29/15 2:23 AM, Volker Simonis wrote:
>>
>> On Tue, Jul 28, 2015 at 11:11 PM, Xueming Shen <xueming.shen at oracle.com>
>> wrote:
>>>
>>> Volker,
>>>
>>> If fine with you I will re-open  the gb18080 specific bug and fix it by
>>> adding the gb18030 into
>>> stdcs-solaris/linux and aix (does aix have a gb18030 locale?).
>>
>> In general I'm fine with your proposal. But I don't understand how you
>> could add gb18030 to stdcs-solaris/linux. As far as I understand that
>> only works for charsets created from a map/template but gb18030 is
>> provided in source at
>> src/jdk.charsets/share/classes/sun/nio/cs/ext/GB18030.java and is
>> explicitly in the sun.nio.cs.ext package. Maybe I'm missing something?
>> I'm not really a charset expert :)
>
>
> Nothing is impossible :-)  only need to change that GB18030.java to a
> "source template"
> with .template, and then generate the real source code during build/compile
> time with
> appropriate package name. We do this for couple charsets already.
>

That's simple enough :)
Thanks for the explanation.

>>
>> Another point is that I thought that you (i.e. Oracle) wanted to keep
>> the base image small. If we now add every charset for which people
>> complain that it is not in the standard set to the base image, where
>> will be the limit? For me that's no problem (I'm doing server VM's :)
>> but maybe somebody else could comment?
>
>
> The "image size" is really not a "concern" on unix/linux platform. But it
> would be preferred
> if we can keep the size small, the reason I'm considering the iconv
> approach.
>
> Thanks,
> Sherman
>
>>
>>
>>
>>> And keep the
>>> 8087171 open
>>> for a more general solution, such as using iconv for a "IconvCharset"
>>>
>>> -Sherman
>>>
>>>
>>> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>>>>
>>>> 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
>>>> https://bugs.openjdk.java.net/browse/JDK-8081674
>>>>
>>>> and:
>>>>
>>>> 8087161: Fails to start up initialize system class loader running on
>>>> unsupported charset
>>>> https://bugs.openjdk.java.net/browse/JDK-8087161
>>>>
>>>> 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
>>>> 8087161.
>>>>
>>>> The mailing list thread about this issue can be found here:
>>>>
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>>>>
>>>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> 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.
>>>
>>>
>