On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak <dbat...@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
