[OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on sun.nio.cs from AWT and Motif code

[Phil Race]

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.