On Wed, 16 Feb 2022 07:44:27 GMT, Prasanta Sadhukhan <psadhuk...@openjdk.org> wrote:
> When invalid unicode codepoints 0xFFFF and 0x10000 are added to an empty > javax.swing.JTextComponent (JTextArea or JTextField), the view cannot be > updated due to a NullPointerException in TextLayout.getBaselineFromGraphic() > owing to the fact GraphicAttribute is null for these invalid codepoints. > > TextLayout.getBaselineFromGraphic() is called from > [TextLayout.standardInit](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/java/awt/font/TextLayout.java#L647) > and > [TextMeasurer.initAll](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/java/awt/font/TextMeasurer.java#L249) > where it relies on CHAR_REPLACEMENT TextAttribute > and its spec says "The default value is null, indicating that the standard > glyphs provided by the font should be used. " so if invalid codepoints is > used, the default value is not changed so we need to be ready for null value > too. > > Since TextAttribute_CHAR_REPLACEMENT says "It is required for correct > positioning of 'inline' components within a line when bidirectional > reordering is performed. Each character (Unicode code point) will be rendered > using the provided GraphicAttribute." so > Fixed by checking if GraphicAttribute is null, then keep the baseline to > default value (which is 0) by returning default baseline (which is > ROMAN_BASELINE) > > Existing jtreg,jck tests are green. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7490
