<i18n dev> RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8

[Jason Mehrens]

On Thu, 10 Oct 2024 16:32:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)
>
>> @naotoj does it make sense?
> 
> Sorry, but I still don't believe that making "ISO-8859-8-I" as an alias to "ISO-8859-8" is the right solution, per the IANA character sets definition (https://www.iana.org/assignments/character-sets/character-sets.xhtml). The current PR would make "ISO-8859-8-I" charset appear in `Charset.forName("ISO-8859-8").aliases()`, but not in `Charset.availableCharsets()` which is deemed incorrect to me.
> 
> That said, I just wonder if this issue can better be addressed exploiting the Charset SPI. This way mail servers can install "ISO-8859-8-I" charset by themselves. This means that mail servers do not need to rely on the underlying JDK which may or may not have that charset.

> That would seem to be what @naotoj stated would make the API contract (concerning IANA identity) correct.

Correct. I gathered that point. What I was trying to convey is that the contribution of the intellectual property is from OpenJDK itself so there is proven track record of quality of the code. 

Alias route is dead, done, rejected. Rejecting a PR on that route that is a 'clone of another charset' is either compatiblely concern or a unwillingness to accept the new charset.

Just trying to find a path forward on this.  Thus my intent is to figure out why charset approach would be rejected on the grounds that ISO-8859-8-I is "obsolete", does not have "sufficient demand", or is not "important" enough.  These are reject words sprinked in thread.

Contributors are here to help out work on this. Working on obsolete, unpopular, unimportant stuff is what we do sometimes.  We just need direction.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2407697259