Here is an updated fix that instead of removing the sun.nio dependency
instead removes
the jdk.charsets static dependency. From the internal API point of view
its sun.nio.cs.ext
that is the issue, not sun.nio
http://cr.openjdk.java.net/~prr/8035302.1/
-phil.
On 2/21/15 1:02 AM, Alan Bateman wrote:
On 20/02/2015 22:30, Phil Race wrote:
On 2/20/2015 1:48 PM, Alan Bateman wrote:
:
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.
They aren't standard. And are (mostly) for X11 only. And if they did
then as I understand
then we'd still have a dependency on the jdk.charsets module which is
one of the motivations
for this, is it not ?
If the X11 charsets were into jdk.charsets then I assume the font code
could access them via the charsets API. Would that work or does the
font code need access beyond what the API provides? I'm mostly just
trying to see whether this option has been explored or not.
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?
Of course I considered this but I don't see the need. They are
perfectly stable
for our needs, and they aren't all completely identical -so I'd
need new code to generate
them and the work to get this done is already quite sufficient
without creating more
that isn't needed.
I don't think we should be checking these into the src tree. If the
solution involves a copy of these charsets then you need to look at
the charset generation so that a copy is generated with a package name
that you want.
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.
Yes, I just learned of this but it doesn't make any difference to
this patch
since its not moved to a public location.
The issue that we are trying to address here is the direct dependency
on a service provider module (jdk.charsets). The sun.nio.cs is in the
java.base module and it should be okay to continue with the qualified
export (as is already in place).
-Alan.
