[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on sun.nio.cs from AWT and Motif code
From:       Alan Bateman <Alan.Bateman () oracle ! com>
Date:       2015-02-21 9:02:23
Message-ID: 54E8499F.7060706 () oracle ! com
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]