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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Thu Mar 24 22:59:50 UTC 2016

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 

> 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 

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.

More information about the 2d-dev mailing list