[OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on sun.nio.cs from AWT and Motif code
philip.race at oracle.com
Thu Mar 19 18:26:07 UTC 2015
Any comments ?
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
> 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
>>> 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).
More information about the 2d-dev