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