On Sun, 6 Feb 2022 19:53:45 GMT, Phil Race <p...@openjdk.org> wrote:
>> Dmitry Batrak has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove 'headful' requirement from test case
>
>> As you say, one could possibly also try to compare font2DHandle-s instead,
> > but that would require forcing the population of that field in equals
> method,
>> which seems to have larger potential for side effects.
>
> Yes, I noted this would present even more problems.
>
>> Of course, there's an alternative method to fix this - make font metrics
>> cache distinguish such fonts explicitly,
>> .... I believe, would just mean waiting for other trouble in future.
>
> I was getting at this with my comment
>
>> 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 it wasn't (isn't) clear to me without tracking this down if some piece of
> the implementation is making
> some assumptions it perhaps shouldn't. But yes, very likely not going to work
> exactly like that.
>
>
> Taking a look I think the problem starts with getCompositeFontUIResource()
>
> So another approach is to define a subclass of FontUIResource in which it
> over-rides hashCode() and equals()
> and does the extra comparison needed.
>
> It would only be equal to another CompositeFontUIResource with the same base
> font
>
> sun.font.CompositeFontUIResource extends FontUIResource { ...
>
> public void boolean equals(Object o) {
> return (o instanceof CompositeFontUIResource && super.equals(o);
> }
>
> Then in sun.font.FontUtilities we add
> if (compFont == null) {
> compFont = new CompositeFont(physicalFont, dialog2D);
> compMap.put(physicalFont, compFont);
> }
> + fuir = new CompositeFontUIResource(font);
> FontAccess.getFontAccess().setFont2D(fuir, compFont.handle);
>
> Ah but this won't work if we are mixing Font and this sub-class since equals
> then won't be symmetric ..
>
> The explanation about JCK indicates that JCK could also obtain a font from
> Swing that has fallbacks,
> serialize it and on deserialization currently it would be equal but after
> this fix it would not.
> So I don't see the difference except that there (presumably) happens not to
> be a JCK test for this scenario ...
> However since JCK isn't part of OpenJDK I don't think we can discuss it any
> further here.
@prrace Any chance of looking at this?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7313
