Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
On 07/30/2015 03:01 PM, David Holmes wrote: On 31/07/2015 1:41 AM, Xueming Shen wrote: On 07/30/2015 01:37 AM, Volker Simonis wrote: On Thu, Jul 30, 2015 at 9:51 AM, Alan Batemanalan.bate...@oracle.com wrote: On 30/07/2015 06:21, Xueming Shen wrote: : Each platform has a list of supported locale/encoding. All these encodings/charsets need to be in base module for that particular platform, to support the jvm to start (in a particular locale/encoding) under module system. The charsets in our repository can be categorized into different groups, solaris/ linux specific, windows specific and IBM specific and couple that are shared by different platforms). The idea here is to build all those platform-specific charsets into the base module for that platform. Right, and furthermore, we should be able to build a compact1 image or just an image with the java.base module and it should be able to start on platforms when running with a supported locale/encoding. I think the main issue we've had is establishing that list, hence it had to be extended a few times. The change looks fine. But what about the 'supported locale/encoding' list. Is there a published 'official' version of this list for Oracle/OpenJDK and how is it maintained. I meant to say all the supported/native locale+encoding of the platform/OS. If we have those charsets in our repository, they all need go into the base module. Now I'm confused again. Do the platforms we officially support have set lists of such locales/encodings? If so getting our list correct seems trivial. If not, then how can we support an unknown target?? it's a known target. we know the list of the locale/encoding solais /linux supports and the list of charsets Java supports. -sherman
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
Hello, I doubt you can compile a list of all charsets supported by the various (national) linux distributions and versions (and installed runtime packages). Especially not for OpenJDK which can be much less restrictive in picking supported (non enterprise) distributions. And I also wonder why it is needed, if a locale is not known just fall back to a sane default. The OpenJDK should define a reasonable list (especially for compact profiles) and not declare to support all platforms fully. Gruss Bernd Xueming Shen xueming.s...@oracle.com schrieb am Fr., 31. Juli 2015 00:35: On 07/30/2015 03:01 PM, David Holmes wrote: On 31/07/2015 1:41 AM, Xueming Shen wrote: On 07/30/2015 01:37 AM, Volker Simonis wrote: On Thu, Jul 30, 2015 at 9:51 AM, Alan Batemanalan.bate...@oracle.com wrote: On 30/07/2015 06:21, Xueming Shen wrote: : Each platform has a list of supported locale/encoding. All these encodings/charsets need to be in base module for that particular platform, to support the jvm to start (in a particular locale/encoding) under module system. The charsets in our repository can be categorized into different groups, solaris/ linux specific, windows specific and IBM specific and couple that are shared by different platforms). The idea here is to build all those platform-specific charsets into the base module for that platform. Right, and furthermore, we should be able to build a compact1 image or just an image with the java.base module and it should be able to start on platforms when running with a supported locale/encoding. I think the main issue we've had is establishing that list, hence it had to be extended a few times. The change looks fine. But what about the 'supported locale/encoding' list. Is there a published 'official' version of this list for Oracle/OpenJDK and how is it maintained. I meant to say all the supported/native locale+encoding of the platform/OS. If we have those charsets in our repository, they all need go into the base module. Now I'm confused again. Do the platforms we officially support have set lists of such locales/encodings? If so getting our list correct seems trivial. If not, then how can we support an unknown target?? it's a known target. we know the list of the locale/encoding solais /linux supports and the list of charsets Java supports. -sherman
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
On 31/07/2015 1:41 AM, Xueming Shen wrote: On 07/30/2015 01:37 AM, Volker Simonis wrote: On Thu, Jul 30, 2015 at 9:51 AM, Alan Batemanalan.bate...@oracle.com wrote: On 30/07/2015 06:21, Xueming Shen wrote: : Each platform has a list of supported locale/encoding. All these encodings/charsets need to be in base module for that particular platform, to support the jvm to start (in a particular locale/encoding) under module system. The charsets in our repository can be categorized into different groups, solaris/ linux specific, windows specific and IBM specific and couple that are shared by different platforms). The idea here is to build all those platform-specific charsets into the base module for that platform. Right, and furthermore, we should be able to build a compact1 image or just an image with the java.base module and it should be able to start on platforms when running with a supported locale/encoding. I think the main issue we've had is establishing that list, hence it had to be extended a few times. The change looks fine. But what about the 'supported locale/encoding' list. Is there a published 'official' version of this list for Oracle/OpenJDK and how is it maintained. I meant to say all the supported/native locale+encoding of the platform/OS. If we have those charsets in our repository, they all need go into the base module. Now I'm confused again. Do the platforms we officially support have set lists of such locales/encodings? If so getting our list correct seems trivial. If not, then how can we support an unknown target?? Thanks, David We do have a jdk supported locale and encoding list, but they are for the supported java locale and encoding. -Sherman Regards, Volker -Alan.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
On 7/30/15 4:55 PM, Bernd wrote: Hello, I doubt you can compile a list of all charsets supported by the various (national) linux distributions and versions (and installed runtime packages). Especially not for OpenJDK which can be much less restrictive in picking supported (non enterprise) distributions. And I also wonder why it is needed, if a locale is not known just fall back to a sane default. The OpenJDK should define a reasonable list (especially for compact profiles) and not declare to support all platforms fully. Bernd, it's the other way around. Instead of addding all charsets supported by the various linux distributions/versions into the base module, we are selecting/building all charsets from our existing repository (originally in jdk's standard charsets and extended charsets) that might be used for a particular platform (linux, solaris, macos, windows) into the base module for that platform. The configuration is pretty straightforward, you can easily define a reasonable list of charsets and build the OpenJDK for your specified platform/profile. As discussed in other email, we are working on the best approach for the use scenario that a charset is unsupported from our repository. -sherman Xueming Shen xueming.s...@oracle.com mailto:xueming.s...@oracle.com schrieb am Fr., 31. Juli 2015 00:35: On 07/30/2015 03:01 PM, David Holmes wrote: On 31/07/2015 1:41 AM, Xueming Shen wrote: On 07/30/2015 01:37 AM, Volker Simonis wrote: On Thu, Jul 30, 2015 at 9:51 AM, Alan Batemanalan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote: On 30/07/2015 06:21, Xueming Shen wrote: : Each platform has a list of supported locale/encoding. All these encodings/charsets need to be in base module for that particular platform, to support the jvm to start (in a particular locale/encoding) under module system. The charsets in our repository can be categorized into different groups, solaris/ linux specific, windows specific and IBM specific and couple that are shared by different platforms). The idea here is to build all those platform-specific charsets into the base module for that platform. Right, and furthermore, we should be able to build a compact1 image or just an image with the java.base module and it should be able to start on platforms when running with a supported locale/encoding. I think the main issue we've had is establishing that list, hence it had to be extended a few times. The change looks fine. But what about the 'supported locale/encoding' list. Is there a published 'official' version of this list for Oracle/OpenJDK and how is it maintained. I meant to say all the supported/native locale+encoding of the platform/OS. If we have those charsets in our repository, they all need go into the base module. Now I'm confused again. Do the platforms we officially support have set lists of such locales/encodings? If so getting our list correct seems trivial. If not, then how can we support an unknown target?? it's a known target. we know the list of the locale/encoding solais /linux supports and the list of charsets Java supports. -sherman
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
On 30/07/2015 04:54, Xueming Shen wrote: Here is the webrev to add those missing charsets. The assumption back then was that the linux platform has successfully migrated to the utf-8 default world. http://cr.openjdk.java.net/~sherman/8132459/ This looks okay to me. -Alan
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
On 30/07/2015 06:21, Xueming Shen wrote: : Each platform has a list of supported locale/encoding. All these encodings/charsets need to be in base module for that particular platform, to support the jvm to start (in a particular locale/encoding) under module system. The charsets in our repository can be categorized into different groups, solaris/ linux specific, windows specific and IBM specific and couple that are shared by different platforms). The idea here is to build all those platform-specific charsets into the base module for that platform. Right, and furthermore, we should be able to build a compact1 image or just an image with the java.base module and it should be able to start on platforms when running with a supported locale/encoding. I think the main issue we've had is establishing that list, hence it had to be extended a few times. -Alan.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
On Thu, Jul 30, 2015 at 9:51 AM, Alan Bateman alan.bate...@oracle.com wrote: On 30/07/2015 06:21, Xueming Shen wrote: : Each platform has a list of supported locale/encoding. All these encodings/charsets need to be in base module for that particular platform, to support the jvm to start (in a particular locale/encoding) under module system. The charsets in our repository can be categorized into different groups, solaris/ linux specific, windows specific and IBM specific and couple that are shared by different platforms). The idea here is to build all those platform-specific charsets into the base module for that platform. Right, and furthermore, we should be able to build a compact1 image or just an image with the java.base module and it should be able to start on platforms when running with a supported locale/encoding. I think the main issue we've had is establishing that list, hence it had to be extended a few times. The change looks fine. But what about the 'supported locale/encoding' list. Is there a published 'official' version of this list for Oracle/OpenJDK and how is it maintained. Regards, Volker -Alan.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
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. 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 Batemanalan.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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
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 Batemanalan.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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
Here is the webrev to add those missing charsets. The assumption back then was that the linux platform has successfully migrated to the utf-8 default world. http://cr.openjdk.java.net/~sherman/8132459/ thanks, Sherman On 7/28/15 8:22 PM, Jonathan Lu wrote: Hi Alan, Sherman, Thanks for taking a look! I understand and totally agree with improving module separation. Another quick test was just done on my Linux box for all available locales, and found several more which will cause ExceptionInInitializerError on JDK9, but worked with JDK8. ar_AE ar_AE.iso88596 ar_BH ar_BH.iso88596 ar_DZ ar_DZ.iso88596 ar_EG ar_EG.iso88596 ar_IQ ar_IQ.iso88596 ar_JO ar_JO.iso88596 ar_KW ar_KW.iso88596 ar_LB ar_LB.iso88596 ar_LY ar_LY.iso88596 ar_MA ar_MA.iso88596 ar_OM ar_OM.iso88596 ar_QA ar_QA.iso88596 ar_SA ar_SA.iso88596 ar_SD ar_SD.iso88596 ar_SY ar_SY.iso88596 ar_TN ar_TN.iso88596 ar_YE ar_YE.iso88596 hebrew he_IL he_IL.iso88598 iw_IL iw_IL.iso88598 mt_MT mt_MT.iso88593 thai th_TH th_TH.tis620 yi_US yi_US.cp1255 zh_CN.gb18030 zh_TW.euctw @Sherman, so other locales (except gb18030, like euctw) are all supposed to wait for the general solution, right ? As I read from the scripts, it sounds to be implementation specific decision. Thanks Jonathan On Jul 29, 2015, at 4:56 AM, Xueming Shen xueming.s...@oracle.com wrote: yes, gb18030 needs to be in linux/unix std-solaris/unix as well. -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 Batemanalan.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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
Hi Sherman, On 30/07/2015 1:54 PM, Xueming Shen wrote: Here is the webrev to add those missing charsets. The assumption back then was that the linux platform has successfully migrated to the utf-8 default world. This process seems somewhat ad-hoc, what are we using to determine which charsets are core and which are not? Thanks, David http://cr.openjdk.java.net/~sherman/8132459/ thanks, Sherman On 7/28/15 8:22 PM, Jonathan Lu wrote: Hi Alan, Sherman, Thanks for taking a look! I understand and totally agree with improving module separation. Another quick test was just done on my Linux box for all available locales, and found several more which will cause ExceptionInInitializerError on JDK9, but worked with JDK8. ar_AE ar_AE.iso88596 ar_BH ar_BH.iso88596 ar_DZ ar_DZ.iso88596 ar_EG ar_EG.iso88596 ar_IQ ar_IQ.iso88596 ar_JO ar_JO.iso88596 ar_KW ar_KW.iso88596 ar_LB ar_LB.iso88596 ar_LY ar_LY.iso88596 ar_MA ar_MA.iso88596 ar_OM ar_OM.iso88596 ar_QA ar_QA.iso88596 ar_SA ar_SA.iso88596 ar_SD ar_SD.iso88596 ar_SY ar_SY.iso88596 ar_TN ar_TN.iso88596 ar_YE ar_YE.iso88596 hebrew he_IL he_IL.iso88598 iw_IL iw_IL.iso88598 mt_MT mt_MT.iso88593 thai th_TH th_TH.tis620 yi_US yi_US.cp1255 zh_CN.gb18030 zh_TW.euctw @Sherman, so other locales (except gb18030, like euctw) are all supposed to wait for the general solution, right ? As I read from the scripts, it sounds to be implementation specific decision. Thanks Jonathan On Jul 29, 2015, at 4:56 AM, Xueming Shen xueming.s...@oracle.com wrote: yes, gb18030 needs to be in linux/unix std-solaris/unix as well. -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 Batemanalan.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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
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 :) 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? Thanks, Volker 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 Batemanalan.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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
On 7/29/15 9:53 PM, David Holmes wrote: Hi Sherman, On 30/07/2015 1:54 PM, Xueming Shen wrote: Here is the webrev to add those missing charsets. The assumption back then was that the linux platform has successfully migrated to the utf-8 default world. This process seems somewhat ad-hoc, what are we using to determine which charsets are core and which are not? Hi David, Each platform has a list of supported locale/encoding. All these encodings/charsets need to be in base module for that particular platform, to support the jvm to start (in a particular locale/encoding) under module system. The charsets in our repository can be categorized into different groups, solaris/ linux specific, windows specific and IBM specific and couple that are shared by different platforms). The idea here is to build all those platform-specific charsets into the base module for that platform. To use the native platform de/encoding implementation/mechanism, for example iconv, for startup only might be a better solution. Until we have that (and the consensus that we go with that approach), the current approach appears to be the only reasonablesimple choice. Thanks, -Sherman Thanks, David http://cr.openjdk.java.net/~sherman/8132459/ thanks, Sherman On 7/28/15 8:22 PM, Jonathan Lu wrote: Hi Alan, Sherman, Thanks for taking a look! I understand and totally agree with improving module separation. Another quick test was just done on my Linux box for all available locales, and found several more which will cause ExceptionInInitializerError on JDK9, but worked with JDK8. ar_AE ar_AE.iso88596 ar_BH ar_BH.iso88596 ar_DZ ar_DZ.iso88596 ar_EG ar_EG.iso88596 ar_IQ ar_IQ.iso88596 ar_JO ar_JO.iso88596 ar_KW ar_KW.iso88596 ar_LB ar_LB.iso88596 ar_LY ar_LY.iso88596 ar_MA ar_MA.iso88596 ar_OM ar_OM.iso88596 ar_QA ar_QA.iso88596 ar_SA ar_SA.iso88596 ar_SD ar_SD.iso88596 ar_SY ar_SY.iso88596 ar_TN ar_TN.iso88596 ar_YE ar_YE.iso88596 hebrew he_IL he_IL.iso88598 iw_IL iw_IL.iso88598 mt_MT mt_MT.iso88593 thai th_TH th_TH.tis620 yi_US yi_US.cp1255 zh_CN.gb18030 zh_TW.euctw @Sherman, so other locales (except gb18030, like euctw) are all supposed to wait for the general solution, right ? As I read from the scripts, it sounds to be implementation specific decision. Thanks Jonathan On Jul 29, 2015, at 4:56 AM, Xueming Shen xueming.s...@oracle.com wrote: yes, gb18030 needs to be in linux/unix std-solaris/unix as well. -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 Batemanalan.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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
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?). 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 Batemanalan.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.
Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale
yes, gb18030 needs to be in linux/unix std-solaris/unix as well. -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 Batemanalan.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.
