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

[Dmitry Batrak]

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

That's true - after the fix, a font with fallback components will not be equal to the original one after serialization/deserialization. In my opinion, that's OK, as after that it will behave not in the way original font does - that's already the case now. Are you saying that is still a no-go? Then we either need to change the serialization format for `Font` by including a new non-transient field (btw, what's the procedure for that? is that possible? does it require CSR?) so that after deserialization it could 'restore' its fallback components. Or still make that 'more precise' font comparison elsewhere - in font metrics cache and other places.

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

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