On Tue, 1 Feb 2022 19:50:47 GMT, Sergey Bylokhov <s...@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. > > src/java.desktop/share/classes/java/awt/Font.java line 464: > >> 462: * should be copied to derived fonts. >> 463: */ >> 464: private transient boolean withFallback; > > I wonder how it will work if the Font was read from the system, then > serialized/deserialized and then used? Not sure I fully understand the question. `Font` object cannot have both `createdFont` and `withFallback` fields set, at least in the current implementation. If we're talking about 'created' fonts (created from a file), the fix doesn't change anything with regard to their behavior - after serialization/deserialization the font might not work, I guess, if it's not registered using `GraphicsEnvironment.registerFont`. In any case, it will lose it's 'created' status, and will change behavior correspondingly. If we're talking about 'fonts with fallback' (like the ones `JEditorPane` creates under the hood), they will lose their fallback components after serialization/deserialization. But that's also how it worked before the proposed change. I'm not going to address that problem in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7313
