[OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API
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...)
> 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.
Best regards, Sergey.
More information about the 2d-dev