RFR: 8185261: Font fallback sometimes doesn't work in Swing text components [v2]

[Phil Race]

On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> The proposed fix makes fonts with and without fallback components distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This is achieved by adding a new boolean field
>> to `Font` class, specifically denoting fonts with fallback components. The latter ones don't need to pretend to be
>> 'created' fonts anymore, to preserve their `Font2D` handle.
>> It's not possible to use the existing `createdFont` field in `equals` implementation, as JCK requires a 'real' created
>> font (the one obtained using `Font.createFont` method) to be equal to the same font after serialization and
>> deserialization.
>
> Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove 'headful' requirement from test case

src/java.desktop/share/classes/java/awt/Font.java line 1861:

> 1859:                 pointSize == font.pointSize &&
> 1860:                 withFallback == font.withFallback &&
> 1861:                 name.equals(font.name)) {

I don't know how much of the fix falls apart if this is changed, but I am not sure about adding this invisible attribute to equals(). I suppose font2DHandle would have the same issue .. but I didn't think that could be used in equals because it is assigned lazily so it would present even more problem.
I do see that it would be tricky to have some private extra equality testing in the code that finds the right fall back but I'd still like to see if that approach might work. Can you add in to the bug a more detailed explanation of where exactly you see the problem occur ? 

I need some convincing and really would like to see if there is an alternative solution that I might prefer but that is something I can't switch on to right now since nothing is coming to me which means it is likely to take some time.

I didn't get the JCK comment createdFont is transient .. and nothing serializes the font data.
Serialization of Font objects is just serializing the fields liek name and style and size but there's no guarantee that it will behave the same .. I mean if I serialize Segoe UI on WIndows and try to deserialize it on Linux nothing in the world can fix the issue that Linux doesn't have that font.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7313