[OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API

[Phil Race]

I have an approved CCC sitting waiting for a 2nd reviewer on the code change

-phil.

On 03/25/2016 11:31 AM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 25.03.16 20:56, Phil Race wrote:
>> After a hallway conversation I have decided to change it to NPE.
>> Not that I think it matters greatly either way since I don't think
>> developers will be passing null to this method anyway :-)
>>
>> The test is changed to match ..
>>
>> http://cr.openjdk.java.net/~prr/8146324.1
>>
>> -phil.
>>
>> On 03/24/2016 03:59 PM, Sergey Bylokhov wrote:
>>> On 25.03.16 1:22, Phil Race wrote:
>>>> That is true .. although I think I have previously been convinced
>>>> that IAE
>>>> is generally the better choice for such a case, I found only 
>>>> deriveFont
>>>> that throws IAE for null in this file.
>>>
>>> deriveFont were changed(NPE to IAE) in 2001, but other methods and the
>>> new code still use NPE. I think that in the most cases the null is not
>>> taken into account and the specification is updated later(like the new
>>> createFonts()).
>>>
>>>> So the question is whether to be consistent or to start picking the
>>>> better option.
>>>> So if there were no existing IAEs or NPEs in this file, which would 
>>>> you
>>>> choose now ?
>>>
>>> Personally I always use NPE for null(via Objects.requireNonNull(...)).
>>> and IAE for other incorrect arguments/types. or if the file(or the
>>> same method) uses IAE already for null. As an example I use
>>> System.getProperty(String).
>>>
>>> But in Font.java we specify NPE for a few methods already, some other
>>> methods throw NPE but w/o specification(except deriveFont...)
>>>
>>>>
>>>> -phil.
>>>>
>>>> On 03/24/2016 02:37 PM, Sergey Bylokhov wrote:
>>>>> Hi, Phil.
>>>>> Should this new method throw IAE? It seems that NPE can be thrown
>>>>> instead, At least other methods in Font.java including the newly 
>>>>> added
>>>>> createFonts() throw NPE.
>>>>>
>>>>> On 25.03.16 0:16, Phil Race wrote:
>>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8146324
>>>>>> fix : http://cr.openjdk.java.net/~prr/8146324/
>>>>>>
>>>>>> Developers have used an internal API to detect when TextLayout or
>>>>>> GlyphVector.layoutGlyphVectorwill be needed since that is a slower
>>>>>> path.
>>>>>>
>>>>>> This provides a public equivalent capability.
>>>>>>
>>>>>> I have included a test which checks the assertions of the API.
>>>>>>
>>>>>> A CCC will be filed.
>>>>>>
>>>>>> -phil.
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>