On Thu, 10 Oct 2024 16:32:48 GMT, Naoto Sato <na...@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
