RFR: 8214533 IBM-29626C is required for AIX default charset

[Magnus Ihse Bursie]

On 2018-12-07 21:20, Roger Riggs wrote:
> Hi,
>
> It is a nice feature that charsets are selected at build time using 
> the stdcs-xxx files.
> This change breaks that pattern and embeds os specific information in 
> more than one place.
> That does not seem like an improvement.  Is there any alternative?
I agree. Why is it not enough just to add it to stdcs-aix?

/Magnus
>
> Thanks, Roger
>
>
> On 12/06/2018 12:05 PM, Ichiroh Takiguchi wrote:
>> Hello.
>> (I'm sorry, I made a mistake, I forgot to change Subject)
>>
>> Could you review the fix ?
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8214533
>> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/
>>
>> IBM29626C charset is required for AIX default charset.
>> Java cannot start because of java/lang/ExceptionInInitializerError on 
>> AIX ja_JP locale.
>>
>> To build team,
>> I'd like to change following charsetmapping tool.
>> * make/jdk/src/classes/build/tools/charsetmapping/Main.java
>> * make/jdk/src/classes/build/tools/charsetmapping/SPI.java
>> * make/jdk/src/classes/build/tools/charsetmapping/SRC.java
>>
>> build.tools.charsetmapping,Main supports "os" tag, but it seems it's 
>> not used.
>> Currently, "os" supports "windows" or "unix".
>> I extended "os" tag's feature.
>> If "os aix" is there, this charset is only added into AIX platform.
>> (I assume "type template" should be used)
>> "aix" comes from "stdcs-aix" file name.
>> ======
>> charset x-IBM29626C IBM29626C
>>     package sun.nio.cs.ext
>>     type    template
>>     os      aix       <=====
>>     alias   cp29626C               # JDK historical
>>     alias   ibm29626C
>>     alias   ibm-29626C
>>     alias   29626C
>>     alias   ibm-eucjp
>> ======
>>
>> If cs.os is null,
>> this charset is stored into gensrc directory.
>> Charset name is added into StandardCharsets.java or 
>> ExtendedCharsets.java
>> If cs.os is "false",
>> this charset is NOT stored into gensrc directory.
>> Charset name is NOT added into StandardCharsets.java or 
>> ExtendedCharsets.java
>>
>> "os" tag supports multiple entries by using ",", like "aix,linux"
>> Then we can store new charset into 
>> src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory
>>
>>
>> $ locale charmap
>> IBM-eucJP
>> $ jshell
>> |  JShell      --      12-internal
>> |                    : /help intro
>>
>> jshell> var cs = java.nio.charset.Charset.defaultCharset()
>> cs ==> x-IBM29626C
>>
>> jshell> cs.getClass().getName()
>> $2 ==> "sun.nio.cs.IBM29626C"
>>
>> jshell> System.out.println(String.join("\n", cs.aliases()))
>> cp29626C
>> ibm-29626C
>> ibm-eucjp
>> ibm29626C
>> 29626C
>>
>> jshell> /exit
>> |
>> $
>>
>> I tested Linux and Windows build.
>> ======
>> $ grep 29626 build.log
>> IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template  false
>>
>> $ find support/gensrc/  | grep 29626
>>
>> $ find support/gensrc/  | grep Charsets
>> support/gensrc/java.base/sun/nio/cs/StandardCharsets.java
>> support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java
>>
>> $ find support/gensrc/  | grep Charsets | xargs grep 29626
>>
>> $
>> ======
>>
>> I'd like to obtain a sponsor for this issue.
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>
>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote:
>>> On 2018-11-28 10:36, Alan Bateman wrote:
>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote:
>>>>> I'm quite unsatisfied with the current handling of character sets 
>>>>> in the build in general. :-( I'd really like to modernize it. I 
>>>>> have a, slightly fuzzy, laundry list of things I want to fix from 
>>>>> a build perspective, but I'm not sure of what "external" 
>>>>> requirements are coming from AIX and the general core-libs agenda 
>>>>> regarding character sets in general.
>>>>>
>>>>> I think there is a good opportunity to solve many problems at the 
>>>>> same time here, as long as everyone agrees on what is the 
>>>>> preferred outcome.
>>>> The support in the build to configure the charsets to include in 
>>>> java.base on each platform has been working well. Charsets that 
>>>> aren't in java.base go into the jdk.charsets service provider 
>>>> module and that has been working well too. From the result point of 
>>>> view, perhaps, but definitely not from the build perspective. ;-) 
>>>> But yes, I understand this is functionality that should be kept.
>>>> One thing that we lack is some way to add charsets for specific 
>>>> platforms and this comes up with the IBM patches where they are 
>>>> looking to adding several additional IBM charsets. One starting 
>>>> point that we've touched on in several threads here is dropping the 
>>>> EBCDIC charsets from the main stream builds. Going there will need 
>>>> build support.
>>> So build support for trivially adding specific charsets to specific
>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume,
>>> then?
>>>
>>> Can you expand on the issue of dropping ebcdic? What's the problem
>>> that needs build support?
>>>
>>> /Magnus
>>>>
>>>>
>>>> -Alan
>>
>