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

[Sergey Bylokhov]

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


-- 
Best regards, Sergey.