On Wed, Jul 29, 2015 at 5:53 PM, Xueming Shen <xueming.s...@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.s...@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.bate...@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. >>> >>> >
