Any comments ?
-phil.
On 03/16/2015 02:32 PM, Phil Race wrote:
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.
