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