> The point being the fonts end up being registered by the canonical path > and that then is the basis for comparison used when we come back here ? That's right - code fails to identify fonts as coming from the same source, as in one case font path is canonicalized.
This code is in testing since April 2016, and in production since August 2016, I'm not aware of any issues caused by it. We also do run JDK regression tests (jtreg) on our codebase - no regressions there either. Best regards, Dmitry Batrak On Wed, Feb 8, 2017 at 3:34 AM, Philip Race <philip.r...@oracle.com> wrote: > The point being the fonts end up being registered by the canonical path > and that then is the basis for comparison used when we come back here ? > I think this will be OK. May I assume you tested this thoroughly. > I don't mean a new regression test - which is not easy. > I mean to make sure it didn't break anything else. > This means existing reg. tests, some other verification there is > no change in anything reported for other families not directly affected by > this bug. > > +1 if you can confirm that .. > > -phil. > > On 1/30/17, 4:36 AM, dmitry markov wrote: > >> Hello Dmitry, >> >> The fix looks good to me, but I am not a reviewer. >> >> I will sponsor the integration of the fix once the review is completed. >> >> Thanks, >> Dmitry >> On 30/01/2017 11:53, Dmitry Batrak wrote: >> >>> Hello, >>> >>> I'd like to propose a fix for JDK-8170950. >>> bug: https://bugs.openjdk.java.net/browse/JDK-8170950 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8170950/webrev.00/ < >>> http://cr.openjdk.java.net/%7Edmarkov/8170950/webrev.00/> >>> >>> I have only a Contributor status, so I'll require a sponsor. >>> >>> The issue is a special case of JDK-8012351 (fixed previously) - when >>> font files >>> are located in symlinked folders. Physical components of logical fonts >>> are >>> registered 'directly', but other fonts are registered with resolving of >>> symbolic >>> links (see registerFontsOnPath invocation in SunFontManager.loadFonts()). >>> So paths comparison in FontFamily.isFromSameSource doesn't always work >>> currently. The proposal is to add symlink resolution to >>> FontFamily.isFromSameSource before path comparison. There are probably >>> other >>> ways to fix the issue - by changing the way fonts are registered, but >>> this one >>> seems to be safer in terms of possible regressions. >>> >>> Best regards, >>> Dmitry Batrak >>> >> >>