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

[Xueming Shen]

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.

>
> 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.
>>