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

[Phil Race]

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.
>