Mandy pointed to me to this review thread, I'm not otherwise on 2d-dev.
First, just to put more context on this. The API for charsets is
java.nio.charsets. It has a service provider interface and the module
jdk.charsets is intended to be a service provider module with the
double byte / extended charsets. Nothing should be directly linking to
or accessing the classes in this module. So it's good to see the font
code being re-examined as this is a dependency that needs to be fixed.
I skimmed over the webrev and have a few questions:
1. For the record, can you explain why the X11 charsets can't move to
jdk.charsets? I have a vague recollection that they aren't standard but
I can't recall any details.
2. sun.nio.cs.ext.EUC_TWMapping is generated in the build and it doesn't
look right to me to check in a copy. Same comment on EUC_KR and EUC_CN
as it looks like they have been copied into X11KSC5601 and X11GB2312.
Have to look at generating these in the build instead?
3. There is also a copy of sun.nio.cs.DoubleByte in the webrev. This
used to be in sun.nio.cs.ext (and hence jdk.charsets) so maybe this
patch started out before Sherman pushed the changes for JDK-8073152.
4. SurrogateParser also looks familiar, is this a copy of
sun.nio.cs.Surrogate.Parser?
5. I see HKSCS is being removed, can you say a bit more about that?
I don't have any other comments at this time, I think the main thing to
understand here is why it is necessary to check in copies of generated
charsets and to see if we can avoid having copies of DoubleByte and
Surrogate.Parser.
-Alan
