From james.graham at oracle.com Wed Feb 1 21:20:44 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 1 Feb 2017 13:20:44 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> Message-ID: <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... ...jim On 1/31/17 2:34 PM, Jim Graham wrote: > For an application to run into this same issue they'd have to expect getCompSizes() to return data for components that > don't exist. It's unlikely they would use that data if they really understand the objects. While that would be odd, I > guess I can see someone might be constructing all of their CM's from an array of 4 components regardless of the number > of actual components and we'd be happily remembering the useless extra components and returning an array of 4 from > getCompSizes(). As I said, they shouldn't really be reading and interpreting those extra components for any image > processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and > copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 > values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how > this might happen, but I really have no idea how likely it is... > > ...jim > > On 1/30/17 3:56 PM, Phil Race wrote: >> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >> Although it does indicate that there is at least a chance that application code might also fail due to similar >> assumptions. >> Does #1 not fail with the previous iteration of this change too ? >> >> -phil. >> >> On 01/30/2017 01:40 PM, Jim Graham wrote: >>> Hmmm. Sounds like the test cases were written based on bugs in the implementation. I'm not sure what the best tactic >>> is here for the short term for getting this in, but many of these changes should eventually be considered bugs in the >>> tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>> >>> Notes on specific instances below... >>> >>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>> Hi Phil, >>>> >>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test >>>> case failure: ColorModel2001 >>>> >>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is >>>> false. >>> >>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>> >>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case >>>> failure: ColorModel0004 >>>> >>>> Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are >>>> using identity-as-equals check in ColorModel. >>> >>> How do they accomplish this when the CM class is abstract? Do they create a relatively empty subclass and instantiate >>> that? >>> >>> The documentation for the equals() method does not document the conditions under which it returns true, it uses a >>> vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>> >>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case >>>> failure: ColorModel2006 >>>> >>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>> >>> Same as above, there are no promises documented. >>> >>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: Failed. test cases: 2; passed: 1; >>>> failed: 1; first test case failure: testCase1 >>>> >>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>> >>> Same assessment as #1 above... >>> >>> Again, while these are my recommendations about the correctness of these tests, the question remains whether we want >>> to introduce a change at this point in the release cycle that will essentially invalidate a number of tests that have >>> been working for several releases already. I'll leave that tactic issue to Phil... >>> >>> ...jim >>> >> From prasanta.sadhukhan at oracle.com Fri Feb 3 05:38:03 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 3 Feb 2017 11:08:03 +0530 Subject: [OpenJDK 2D-Dev] [8u] RFR: 8170578: CUPS Printing is broken with Ubuntu 16.10 (CUPS 2.2) Message-ID: <505eafd8-f8e9-0ae5-2d95-81b5ae86509a@oracle.com> Hi All, This is a backport review request to jdk8u for an issue fixed in jdk9 for CUPS printing issue in ubuntu16.10 (mail-thread: http://mail.openjdk.java.net/pipermail/2d-dev/2017-January/008174.html) While backporting, it is found that the build fails citing error: incompatible types: Object cannot be converted to Entry for (Map.Entry entry : responseMap[i].entrySet()) { so the fix is slightly modified to store the "entrySet" to a Set and iterating on that Set. webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/8udev/webrev.00/ With this modification, the build succeeds and test passed. Regards Prasanta From prahalad.kumar.narayanan at oracle.com Tue Feb 7 03:46:58 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 6 Feb 2017 19:46:58 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: [JDK-6852563] ArrayOutOfBoundException when reading RLE8 compressed bitmap Message-ID: Hello Everyone Good day to you. Request your time in reviewing the fix for the bug [JDK-6852563] ArrayOutOfBoundException when reading RLE8 compressed bitmap Root Cause . The issue is similar to JDK-8167278 except for the difference in the Bitmap's compression format. . The issue surfaces when either of the following holds true- . When a malformed RLE8 bitmap image is decoded /or . When a valid RLE8 bitmap image with 'Delta sequence' is decoded. Details on the Fix: . Necessary guard conditions have been put in RLE8 bitmap decoding code. . Handling of Delta encoding (0x00 0x02 xOffset yOffset) in source image has been corrected with appropriate logic. . [Note] No regression test case has been provided with the fix. . The fix will require input RLE8 bitmap as mentioned in the root cause. . When we tried to create one such bitmap using Gimp editor, the resulting image didn't contain corruption /or the delta sequence to trigger the issue. . However, the fix was tested with all RLE8 Bitmap images from bitmap test suite (including corrupt images) and no issues were seen. Other Details: . The fix was run through both Jtreg and JCK test suites. No regressions were noticed. The changes are available for your review under: Link: http://cr.openjdk.java.net/~pnarayanan/6852563/webrev.00/ Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. From philip.race at oracle.com Tue Feb 7 23:20:15 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 07 Feb 2017 15:20:15 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: [JDK-6852563] ArrayOutOfBoundException when reading RLE8 compressed bitmap In-Reply-To: References: Message-ID: <589A562F.5050507@oracle.com> That was deja vu all over again. I wonder if there is some additional sharing that can be done here between RLE4 and RLE8. But not right now .. just something to think about. +1 -phil. On 2/6/17, 7:46 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for the bug > [JDK-6852563] ArrayOutOfBoundException when reading RLE8 compressed bitmap > > Root Cause > . The issue is similar to JDK-8167278 except for the difference in the Bitmap's compression format. > . The issue surfaces when either of the following holds true- > . When a malformed RLE8 bitmap image is decoded /or > . When a valid RLE8 bitmap image with 'Delta sequence' is decoded. > > Details on the Fix: > . Necessary guard conditions have been put in RLE8 bitmap decoding code. > . Handling of Delta encoding (0x00 0x02 xOffset yOffset) in source image has been corrected with appropriate logic. > . [Note] No regression test case has been provided with the fix. > . The fix will require input RLE8 bitmap as mentioned in the root cause. > . When we tried to create one such bitmap using Gimp editor, the resulting image didn't contain corruption /or the delta sequence to trigger the issue. > . However, the fix was tested with all RLE8 Bitmap images from bitmap test suite (including corrupt images) and no issues were seen. > > Other Details: > . The fix was run through both Jtreg and JCK test suites. No regressions were noticed. > > The changes are available for your review under: > Link: http://cr.openjdk.java.net/~pnarayanan/6852563/webrev.00/ > > Kindly review the changes at your convenience and share your feedback. > > Thank you for your time in review > Have a good day > > Prahalad N. From philip.race at oracle.com Wed Feb 8 00:34:22 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 07 Feb 2017 16:34:22 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder In-Reply-To: <588F3344.90008@oracle.com> References: <588F3344.90008@oracle.com> Message-ID: <589A678E.7050607@oracle.com> 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/ >> >> >> 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 > From dmitry.batrak at jetbrains.com Wed Feb 8 08:44:25 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Wed, 8 Feb 2017 11:44:25 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder In-Reply-To: <589A678E.7050607@oracle.com> References: <588F3344.90008@oracle.com> <589A678E.7050607@oracle.com> Message-ID: > 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 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 >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Feb 8 10:11:29 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 8 Feb 2017 02:11:29 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> Message-ID: <496e0881-eb9e-4d51-b655-c15e46a50fc9@default> Hello All, I have updated the webrev to include the following changes. 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, February 02, 2017 2:51 AM To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... ...jim On 1/31/17 2:34 PM, Jim Graham wrote: > For an application to run into this same issue they'd have to expect > getCompSizes() to return data for components that don't exist. It's > unlikely they would use that data if they really understand the > objects. While that would be odd, I guess I can see someone might be > constructing all of their CM's from an array of 4 components > regardless of the number of actual components and we'd be happily > remembering the useless extra components and returning an array of 4 > from getCompSizes(). As I said, they shouldn't really be reading and > interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... > > ...jim > > On 1/30/17 3:56 PM, Phil Race wrote: >> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >> Although it does indicate that there is at least a chance that >> application code might also fail due to similar assumptions. >> Does #1 not fail with the previous iteration of this change too ? >> >> -phil. >> >> On 01/30/2017 01:40 PM, Jim Graham wrote: >>> Hmmm. Sounds like the test cases were written based on bugs in the >>> implementation. I'm not sure what the best tactic is here for the >>> short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>> >>> Notes on specific instances below... >>> >>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>> Hi Phil, >>>> >>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>> ColorModel2001 >>>> >>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>> >>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>> >>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>> cases: 3; passed: 2; failed: 1; first test case >>>> failure: ColorModel0004 >>>> >>>> Here they check for equality between 2 ColorModel objects >>>> having same values, but it fails because now we are using identity-as-equals check in ColorModel. >>> >>> How do they accomplish this when the CM class is abstract? Do they >>> create a relatively empty subclass and instantiate that? >>> >>> The documentation for the equals() method does not document the >>> conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>> >>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>> test cases: 2; passed: 1; failed: 1; first test case >>>> failure: ColorModel2006 >>>> >>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>> >>> Same as above, there are no promises documented. >>> >>>> >>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTest >>>> testCase1: Failed. test cases: 2; passed: 1; >>>> failed: 1; first test case failure: testCase1 >>>> >>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>> >>> Same assessment as #1 above... >>> >>> Again, while these are my recommendations about the correctness of >>> these tests, the question remains whether we want to introduce a >>> change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... >>> >>> ...jim >>> >> From philip.race at oracle.com Wed Feb 8 18:03:54 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 08 Feb 2017 10:03:54 -0800 Subject: [OpenJDK 2D-Dev] [8u] RFR: 8170578: CUPS Printing is broken with Ubuntu 16.10 (CUPS 2.2) In-Reply-To: <505eafd8-f8e9-0ae5-2d95-81b5ae86509a@oracle.com> References: <505eafd8-f8e9-0ae5-2d95-81b5ae86509a@oracle.com> Message-ID: <589B5D8A.9080808@oracle.com> Looks fine. Please send email to 8u-dev asking for approval to push. -phil. On 2/2/17, 9:38 PM, Prasanta Sadhukhan wrote: > Hi All, > > This is a backport review request to jdk8u for an issue fixed in jdk9 > for CUPS printing issue in ubuntu16.10 > (mail-thread: > http://mail.openjdk.java.net/pipermail/2d-dev/2017-January/008174.html) > > While backporting, it is found that the build fails citing > > error: incompatible types: Object cannot be converted to > Entry > for (Map.Entry > entry : responseMap[i].entrySet()) { > so the fix is slightly modified to store the "entrySet" to a Set and > iterating on that Set. > > webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/8udev/webrev.00/ > > With this modification, the build succeeds and test passed. > > Regards > Prasanta > > From jayathirth.d.v at oracle.com Thu Feb 9 07:56:42 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 8 Feb 2017 23:56:42 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <496e0881-eb9e-4d51-b655-c15e46a50fc9@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> <496e0881-eb9e-4d51-b655-c15e46a50fc9@default> Message-ID: Hello All, There was a closed test which was failing because of identity-as-equals approach for ColorModel equals() method. I have modified it and added in the webrev. Along with this we are now using colorspace.hashCode() in hashCode() functions instead of Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in IndexColorModel equals() method because Arrays.copyOf() takes lot of time. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ Ran jtreg test and JCK there are no additional test case failures because of the above change. Only 4 JCK tests are failing as it was happening previously. Just copy pasted my observation regarding JCK failures so that we can trace it easily: 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test case failure: ColorModel2001 This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: testCase1 Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Wednesday, February 08, 2017 3:41 PM To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Hello All, I have updated the webrev to include the following changes. 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, February 02, 2017 2:51 AM To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... ...jim On 1/31/17 2:34 PM, Jim Graham wrote: > For an application to run into this same issue they'd have to expect > getCompSizes() to return data for components that don't exist. It's > unlikely they would use that data if they really understand the > objects. While that would be odd, I guess I can see someone might be > constructing all of their CM's from an array of 4 components > regardless of the number of actual components and we'd be happily > remembering the useless extra components and returning an array of 4 > from getCompSizes(). As I said, they shouldn't really be reading and > interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... > > ...jim > > On 1/30/17 3:56 PM, Phil Race wrote: >> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >> Although it does indicate that there is at least a chance that >> application code might also fail due to similar assumptions. >> Does #1 not fail with the previous iteration of this change too ? >> >> -phil. >> >> On 01/30/2017 01:40 PM, Jim Graham wrote: >>> Hmmm. Sounds like the test cases were written based on bugs in the >>> implementation. I'm not sure what the best tactic is here for the >>> short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>> >>> Notes on specific instances below... >>> >>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>> Hi Phil, >>>> >>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>> ColorModel2001 >>>> >>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>> >>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>> >>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>> cases: 3; passed: 2; failed: 1; first test case >>>> failure: ColorModel0004 >>>> >>>> Here they check for equality between 2 ColorModel objects >>>> having same values, but it fails because now we are using identity-as-equals check in ColorModel. >>> >>> How do they accomplish this when the CM class is abstract? Do they >>> create a relatively empty subclass and instantiate that? >>> >>> The documentation for the equals() method does not document the >>> conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>> >>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>> test cases: 2; passed: 1; failed: 1; first test case >>>> failure: ColorModel2006 >>>> >>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>> >>> Same as above, there are no promises documented. >>> >>>> >>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTest >>>> testCase1: Failed. test cases: 2; passed: 1; >>>> failed: 1; first test case failure: testCase1 >>>> >>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>> >>> Same assessment as #1 above... >>> >>> Again, while these are my recommendations about the correctness of >>> these tests, the question remains whether we want to introduce a >>> change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... >>> >>> ...jim >>> >> From prasanta.sadhukhan at oracle.com Thu Feb 9 09:08:11 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 9 Feb 2017 14:38:11 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: <459b6a81-1ae9-9876-e86a-c567dd4529e8@oracle.com> Hi All, Please review a fix for an issue which causes arabic character "alef" to be not rendered in osx for menlo font in italic style. Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 The issue was actually a regression caused by the fix to JDK-7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode in which we have added cascaded font list to find the real fonts that CFont uses, so that there is no need to use "negative" glyph code for finding the fallback fonts using the "subsititution"/"fallback" mechanism used by osx code. However, the above logic of using cascaded font list in CFont does not take into account of using JRE provided fonts like all those Lucida* ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' character) is intended to be rendered in Menlo font in italic style, osx will not be able to find the glyph in Menlo-Italic font and neither in all the cascaded system fonts provided by CoreText, so it results in empty box. Before 7162125 fix, the fallback code in CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses JRSFontCreateFallbackFontForCharacters() was adding jre/lib/fonts to the fallback list which was causing the glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was rendered. So, the proposed fix is to add jre provided font "Lucida Sans Regular" to the cascaded list so that we get the "alef" glyph. The reason for choosing "Lucida Sans Regular" over "Lucida Bright Regular" is, because it is the largest font file in jre and has all the glyph codepoints that no other font in the jre has, so we will not lose out on any codepoints and will help us in not getting missing glyph. webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Feb 9 19:30:26 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 09 Feb 2017 11:30:26 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8172967: [macosx] Exception while working with layout for text containing unmappable character Message-ID: <589CC352.6040408@oracle.com> http://cr.openjdk.java.net/~prr/8172967/ https://bugs.openjdk.java.net/browse/JDK-8172967 Full evaluation in the bug report. Short summary: avoid AIOB and NPE when Mac glyph mapper returns a negated unicode which is misinterpreted as having composite font slot 255 -phil. From james.graham at oracle.com Thu Feb 9 21:59:37 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 9 Feb 2017 13:59:37 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> <496e0881-eb9e-4d51-b655-c15e46a50fc9@default> Message-ID: From my end this looks good. +1 except for 2 outstanding review issues: - Would like to hear back final comments from Joe Darcy on the new doc changes/CCC request - Phil pointed out that there is an unneeded import in some of the files. I agree that we should make a final webrev to delete them, but I don't need to approve it if that is the only change... ...jim On 2/8/17 11:56 PM, Jayathirth D V wrote: > Hello All, > > There was a closed test which was failing because of identity-as-equals approach for ColorModel equals() method. > I have modified it and added in the webrev. Along with this we are now using colorspace.hashCode() in hashCode() functions instead of Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in IndexColorModel equals() method because Arrays.copyOf() takes lot of time. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ > > Ran jtreg test and JCK there are no additional test case failures because of the above change. Only 4 JCK tests are failing as it was happening previously. > > Just copy pasted my observation regarding JCK failures so that we can trace it easily: > > 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test case failure: ColorModel2001 > > This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. > > 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 > > Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. > > 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 > > Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. > > 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: testCase1 > > Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. > > Thanks, > Jay > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, February 08, 2017 3:41 PM > To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > Hello All, > > I have updated the webrev to include the following changes. > > 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. > 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. > 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. > 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, February 02, 2017 2:51 AM > To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. > I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... > > ...jim > > On 1/31/17 2:34 PM, Jim Graham wrote: >> For an application to run into this same issue they'd have to expect >> getCompSizes() to return data for components that don't exist. It's >> unlikely they would use that data if they really understand the >> objects. While that would be odd, I guess I can see someone might be >> constructing all of their CM's from an array of 4 components >> regardless of the number of actual components and we'd be happily >> remembering the useless extra components and returning an array of 4 >> from getCompSizes(). As I said, they shouldn't really be reading and >> interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... >> >> ...jim >> >> On 1/30/17 3:56 PM, Phil Race wrote: >>> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >>> Although it does indicate that there is at least a chance that >>> application code might also fail due to similar assumptions. >>> Does #1 not fail with the previous iteration of this change too ? >>> >>> -phil. >>> >>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>> Hmmm. Sounds like the test cases were written based on bugs in the >>>> implementation. I'm not sure what the best tactic is here for the >>>> short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>>> >>>> Notes on specific instances below... >>>> >>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>> Hi Phil, >>>>> >>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>> ColorModel2001 >>>>> >>>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>> >>>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>>> >>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>>> cases: 3; passed: 2; failed: 1; first test case >>>>> failure: ColorModel0004 >>>>> >>>>> Here they check for equality between 2 ColorModel objects >>>>> having same values, but it fails because now we are using identity-as-equals check in ColorModel. >>>> >>>> How do they accomplish this when the CM class is abstract? Do they >>>> create a relatively empty subclass and instantiate that? >>>> >>>> The documentation for the equals() method does not document the >>>> conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>>> >>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>> failure: ColorModel2006 >>>>> >>>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>>> >>>> Same as above, there are no promises documented. >>>> >>>>> >>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTest >>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>> failed: 1; first test case failure: testCase1 >>>>> >>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>>> >>>> Same assessment as #1 above... >>>> >>>> Again, while these are my recommendations about the correctness of >>>> these tests, the question remains whether we want to introduce a >>>> change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... >>>> >>>> ...jim >>>> >>> From philip.race at oracle.com Thu Feb 9 22:05:24 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 9 Feb 2017 14:05:24 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> <496e0881-eb9e-4d51-b655-c15e46a50fc9@default> Message-ID: <78dab679-6b22-ea05-5418-67528881b960@oracle.com> Oh .. my reply was to an off-list email. I did not notice that. So I should repeat that here : On 2/9/17 12:38 PM, Phil Race wrote: > 32 import java.util.Objects; > > This is now un-used, isn't it ? Yet all 3 subclasses still have this > import. > > I don't need to "approve" a new webrev containing that but it would > be good to publish one. > > +1 -phil. On 02/09/2017 01:59 PM, Jim Graham wrote: > From my end this looks good. +1 except for 2 outstanding review issues: > > - Would like to hear back final comments from Joe Darcy on the new doc > changes/CCC request > - Phil pointed out that there is an unneeded import in some of the > files. I agree that we should make a final webrev to delete them, but > I don't need to approve it if that is the only change... > > ...jim > > On 2/8/17 11:56 PM, Jayathirth D V wrote: >> Hello All, >> >> There was a closed test which was failing because of >> identity-as-equals approach for ColorModel equals() method. >> I have modified it and added in the webrev. Along with this we are >> now using colorspace.hashCode() in hashCode() functions instead of >> Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in >> IndexColorModel equals() method because Arrays.copyOf() takes lot of >> time. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ >> >> Ran jtreg test and JCK there are no additional test case failures >> because of the above change. Only 4 JCK tests are failing as it was >> happening previously. >> >> Just copy pasted my observation regarding JCK failures so that we can >> trace it easily: >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test >> cases: 4; passed: 3; failed: 1; first test case failure: ColorModel2001 >> >> This test fails because getComponentSize() returned an array with >> length 3 but it expects the length to be 4. In the test case they >> have bits per component array of length 4 like {8, 8, 8, 8}. But >> in the test case wherever they are passing "has Alpha" as "false" we >> omit the alpha component bit. This is because of tighter check >> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >> >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >> cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having >> same values, but it fails because now we are using identity-as-equals >> check in ColorModel. >> >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel >> objects having same values, but it fails since we don't have hashCode >> check in ColorModel and it will be different between 2 Objects. >> >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >> testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >> also happening because of same reason as why the first JCK test is >> failing. We omit alpha bit if hasAlpha is false but JCK test >> tries to call getComponentSize() with index 3 which throws >> ArrayIndexOutOfBoundsException. >> >> Thanks, >> Jay >> -----Original Message----- >> From: Jayathirth D V >> Sent: Wednesday, February 08, 2017 3:41 PM >> To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both methods >> >> Hello All, >> >> I have updated the webrev to include the following changes. >> >> 1) Have identity as equals check in equals() method of ColorModel >> but elaborate the specification of equals() and hashCode() in >> ColorModel on what properties to check in subclasses of >> ColorModel. >> 2) Made changes to test case to have single helper method >> wherever we have same equals/hashCode() check. >> 3) Updated IndexColorModel equals() method to use Arrays.equals() >> for rgb[] data. >> 4) Add comment on why we are not using validBits to calculate >> hashCode() in IndexColorModel hashCode() method. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, February 02, 2017 2:51 AM >> To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both methods >> >> I think we should move this issue (array size returned from >> getCompSizes) into a separate bug entry and a separate fix. >> I don't think we need to fix the clone() in the constructor and the >> getter just to get hashcode/equals right... >> >> ...jim >> >> On 1/31/17 2:34 PM, Jim Graham wrote: >>> For an application to run into this same issue they'd have to expect >>> getCompSizes() to return data for components that don't exist. It's >>> unlikely they would use that data if they really understand the >>> objects. While that would be odd, I guess I can see someone might be >>> constructing all of their CM's from an array of 4 components >>> regardless of the number of actual components and we'd be happily >>> remembering the useless extra components and returning an array of 4 >>> from getCompSizes(). As I said, they shouldn't really be reading and >>> interpreting those extra components for any image processing, but I >>> can imagine that they might do something like create a variant CM by >>> calling the CompSizes() and copying them into a new array to >>> construct a new CM with modifications. They might just robotically >>> always copy 4 values without really checking how many are valid. >>> That's a stretch, and their code is weak. I can conceive of how >>> this might happen, but I really have no idea how likely it is... >>> >>> ...jim >>> >>> On 1/30/17 3:56 PM, Phil Race wrote: >>>> Sounds like we should at least try to get the tests updated so they >>>> only test what the spec. says. >>>> Although it does indicate that there is at least a chance that >>>> application code might also fail due to similar assumptions. >>>> Does #1 not fail with the previous iteration of this change too ? >>>> >>>> -phil. >>>> >>>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>>> Hmmm. Sounds like the test cases were written based on bugs in the >>>>> implementation. I'm not sure what the best tactic is here for the >>>>> short term for getting this in, but many of these changes should >>>>> eventually be considered bugs in the tests. Is it acceptable to >>>>> break API tests like this at the last minute even if the tests are >>>>> at fault? Phil? >>>>> >>>>> Notes on specific instances below... >>>>> >>>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>>> Hi Phil, >>>>>> >>>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>>> ColorModel2001 >>>>>> >>>>>> This test fails because getComponentSize() returned an array >>>>>> with length 3 but it expects the length to be 4. In >>>>>> the test case they have bits per component array of length 4 >>>>>> like {8, 8, 8, 8}. But in the test case wherever >>>>>> they are passing "has Alpha" as "false" we omit the alpha >>>>>> component bit. This is because of tighter check that we >>>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>>> >>>>> This is a bug in the test then, especially if the size of our >>>>> array matches the return value of getNumComponents. >>>>> >>>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>>>> cases: 3; passed: 2; failed: 1; first test case >>>>>> failure: ColorModel0004 >>>>>> >>>>>> Here they check for equality between 2 ColorModel objects >>>>>> having same values, but it fails because now we are using >>>>>> identity-as-equals check in ColorModel. >>>>> >>>>> How do they accomplish this when the CM class is abstract? Do they >>>>> create a relatively empty subclass and instantiate that? >>>>> >>>>> The documentation for the equals() method does not document the >>>>> conditions under which it returns true, it uses a vague concept of >>>>> "equals this ColorModel". I don't see how they could test >>>>> anything given that documentation. >>>>> >>>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>>> failure: ColorModel2006 >>>>>> >>>>>> Here they check for hashCode equality between 2 ColorModel >>>>>> objects having same values, but it fails since we >>>>>> don't have hashCode check in ColorModel and it will be >>>>>> different between 2 Objects. >>>>> >>>>> Same as above, there are no promises documented. >>>>> >>>>>> >>>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTest >>>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>>> failed: 1; first test case failure: testCase1 >>>>>> >>>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >>>>>> also happening because of same reason as why the >>>>>> first JCK test is failing. We omit alpha bit if hasAlpha is false >>>>>> but JCK test tries to call getComponentSize() >>>>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>>>> >>>>> Same assessment as #1 above... >>>>> >>>>> Again, while these are my recommendations about the correctness of >>>>> these tests, the question remains whether we want to introduce a >>>>> change at this point in the release cycle that will essentially >>>>> invalidate a number of tests that have been working for several >>>>> releases already. I'll leave that tactic issue to Phil... >>>>> >>>>> ...jim >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Feb 10 03:09:00 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 09 Feb 2017 19:09:00 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: <459b6a81-1ae9-9876-e86a-c567dd4529e8@oracle.com> References: <459b6a81-1ae9-9876-e86a-c567dd4529e8@oracle.com> Message-ID: <589D2ECC.4090505@oracle.com> I am OK with this if you can confirm that removing Lucida Sans Regular from the JDK does not cause any nasty exceptions. Apple use the PostScript name but our lookup code should work for the TrueType name. So overall I think this should be fine - from visual inspection - and assuming it has been tested :-) +1 -phil. On 2/9/17, 1:08 AM, Prasanta Sadhukhan wrote: > > Hi All, > > Please review a fix for an issue which causes arabic character "alef" > to be not rendered in osx for menlo font in italic style. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 > > The issue was actually a regression caused by the fix to JDK-7162125: > [macosx] A font has different behaviour for ligatures depending on its > creation mode > in which we have added cascaded font list to find the real fonts that > CFont uses, so that there is no need to use "negative" glyph code for > finding the fallback fonts > using the "subsititution"/"fallback" mechanism used by osx code. > > However, the above logic of using cascaded font list in CFont does not > take into account of using JRE provided fonts like all those Lucida* > ttf in jdk/lib/fonts/, so > when a glyph (in this intance, arabic 'alef' character) is intended to > be rendered in Menlo font in italic style, osx will not be able to > find the glyph in Menlo-Italic font > and neither in all the cascaded system fonts provided by CoreText, so > it results in empty box. > > Before 7162125 fix, the fallback code in > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() > uses JRSFontCreateFallbackFontForCharacters() > was adding jre/lib/fonts to the fallback list which was causing the > glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was > rendered. > > So, the proposed fix is to add jre provided font "Lucida Sans Regular" > to the cascaded list so that we get the "alef" glyph. > The reason for choosing "Lucida Sans Regular" over "Lucida Bright > Regular" is, because it is the largest font file in jre and has all > the glyph codepoints that no other font in the jre has, > so we will not lose out on any codepoints and will help us in not > getting missing glyph. > > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ > > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Fri Feb 10 03:34:34 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 9 Feb 2017 19:34:34 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: <98e3b75f-b2e5-41a4-9489-62ec34b05985@default> The change looks good. +1. Minor observation: The copyright should be updated to 2017 in the CFont.java file. If you use any script to update the same, then ignore this observation. Thanks Have a good day Prahalad N. -----Original Message----- From: 2d-dev-request at openjdk.java.net [mailto:2d-dev-request at openjdk.java.net] Sent: Friday, February 10, 2017 3:37 AM To: 2d-dev at openjdk.java.net Subject: 2d-dev Digest, Vol 117, Issue 3 Send 2d-dev mailing list submissions to 2d-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/2d-dev or, via email, send a message with subject or body 'help' to 2d-dev-request at openjdk.java.net You can reach the person managing the list at 2d-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of 2d-dev digest..." Today's Topics: 1. [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X (Prasanta Sadhukhan) 2. RFR: 8172967: [macosx] Exception while working with layout for text containing unmappable character (Philip Race) 3. Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods (Jim Graham) 4. Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods (Phil Race) ---------------------------------------------------------------------- Message: 1 Date: Thu, 9 Feb 2017 14:38:11 +0530 From: Prasanta Sadhukhan To: 2d-dev <2d-dev at openjdk.java.net>, Philip Race Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: <459b6a81-1ae9-9876-e86a-c567dd4529e8 at oracle.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi All, Please review a fix for an issue which causes arabic character "alef" to be not rendered in osx for menlo font in italic style. Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 The issue was actually a regression caused by the fix to JDK-7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode in which we have added cascaded font list to find the real fonts that CFont uses, so that there is no need to use "negative" glyph code for finding the fallback fonts using the "subsititution"/"fallback" mechanism used by osx code. However, the above logic of using cascaded font list in CFont does not take into account of using JRE provided fonts like all those Lucida* ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' character) is intended to be rendered in Menlo font in italic style, osx will not be able to find the glyph in Menlo-Italic font and neither in all the cascaded system fonts provided by CoreText, so it results in empty box. Before 7162125 fix, the fallback code in CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses JRSFontCreateFallbackFontForCharacters() was adding jre/lib/fonts to the fallback list which was causing the glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was rendered. So, the proposed fix is to add jre provided font "Lucida Sans Regular" to the cascaded list so that we get the "alef" glyph. The reason for choosing "Lucida Sans Regular" over "Lucida Bright Regular" is, because it is the largest font file in jre and has all the glyph codepoints that no other font in the jre has, so we will not lose out on any codepoints and will help us in not getting missing glyph. webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 09 Feb 2017 11:30:26 -0800 From: Philip Race To: 2d-dev <2d-dev at openjdk.java.net> Subject: [OpenJDK 2D-Dev] RFR: 8172967: [macosx] Exception while working with layout for text containing unmappable character Message-ID: <589CC352.6040408 at oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed http://cr.openjdk.java.net/~prr/8172967/ https://bugs.openjdk.java.net/browse/JDK-8172967 Full evaluation in the bug report. Short summary: avoid AIOB and NPE when Mac glyph mapper returns a negated unicode which is misinterpreted as having composite font slot 255 -phil. ------------------------------ Message: 3 Date: Thu, 9 Feb 2017 13:59:37 -0800 From: Jim Graham To: Jayathirth D V , Philip Race , 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Message-ID: Content-Type: text/plain; charset=windows-1252; format=flowed From my end this looks good. +1 except for 2 outstanding review issues: - Would like to hear back final comments from Joe Darcy on the new doc changes/CCC request - Phil pointed out that there is an unneeded import in some of the files. I agree that we should make a final webrev to delete them, but I don't need to approve it if that is the only change... ...jim On 2/8/17 11:56 PM, Jayathirth D V wrote: > Hello All, > > There was a closed test which was failing because of identity-as-equals approach for ColorModel equals() method. > I have modified it and added in the webrev. Along with this we are now using colorspace.hashCode() in hashCode() functions instead of Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in IndexColorModel equals() method because Arrays.copyOf() takes lot of time. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ > > Ran jtreg test and JCK there are no additional test case failures because of the above change. Only 4 JCK tests are failing as it was happening previously. > > Just copy pasted my observation regarding JCK failures so that we can trace it easily: > > 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test > cases: 4; passed: 3; failed: 1; first test case failure: > ColorModel2001 > > This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. > > 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: > 3; passed: 2; failed: 1; first test case failure: ColorModel0004 > > Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. > > 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test > cases: 2; passed: 1; failed: 1; first test case failure: > ColorModel2006 > > Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. > > 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttes > tCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case > failure: testCase1 > > Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. > > Thanks, > Jay > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, February 08, 2017 3:41 PM > To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > > Hello All, > > I have updated the webrev to include the following changes. > > 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. > 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. > 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. > 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, February 02, 2017 2:51 AM > To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > > I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. > I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... > > ...jim > > On 1/31/17 2:34 PM, Jim Graham wrote: >> For an application to run into this same issue they'd have to expect >> getCompSizes() to return data for components that don't exist. It's >> unlikely they would use that data if they really understand the >> objects. While that would be odd, I guess I can see someone might be >> constructing all of their CM's from an array of 4 components >> regardless of the number of actual components and we'd be happily >> remembering the useless extra components and returning an array of 4 >> from getCompSizes(). As I said, they shouldn't really be reading and >> interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... >> >> ...jim >> >> On 1/30/17 3:56 PM, Phil Race wrote: >>> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >>> Although it does indicate that there is at least a chance that >>> application code might also fail due to similar assumptions. >>> Does #1 not fail with the previous iteration of this change too ? >>> >>> -phil. >>> >>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>> Hmmm. Sounds like the test cases were written based on bugs in the >>>> implementation. I'm not sure what the best tactic is here for the >>>> short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>>> >>>> Notes on specific instances below... >>>> >>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>> Hi Phil, >>>>> >>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>> ColorModel2001 >>>>> >>>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>> >>>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>>> >>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. >>>>> test >>>>> cases: 3; passed: 2; failed: 1; first test case >>>>> failure: ColorModel0004 >>>>> >>>>> Here they check for equality between 2 ColorModel objects >>>>> having same values, but it fails because now we are using identity-as-equals check in ColorModel. >>>> >>>> How do they accomplish this when the CM class is abstract? Do they >>>> create a relatively empty subclass and instantiate that? >>>> >>>> The documentation for the equals() method does not document the >>>> conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>>> >>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>> failure: ColorModel2006 >>>>> >>>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>>> >>>> Same as above, there are no promises documented. >>>> >>>>> >>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTes >>>>> t >>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>> failed: 1; first test case failure: testCase1 >>>>> >>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>>> >>>> Same assessment as #1 above... >>>> >>>> Again, while these are my recommendations about the correctness of >>>> these tests, the question remains whether we want to introduce a >>>> change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... >>>> >>>> ...jim >>>> >>> ------------------------------ Message: 4 Date: Thu, 9 Feb 2017 14:05:24 -0800 From: Phil Race To: Jim Graham , Jayathirth D V , 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Message-ID: <78dab679-6b22-ea05-5418-67528881b960 at oracle.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Oh .. my reply was to an off-list email. I did not notice that. So I should repeat that here : On 2/9/17 12:38 PM, Phil Race wrote: > 32 import java.util.Objects; > > This is now un-used, isn't it ? Yet all 3 subclasses still have this > import. > > I don't need to "approve" a new webrev containing that but it would be > good to publish one. > > +1 -phil. On 02/09/2017 01:59 PM, Jim Graham wrote: > From my end this looks good. +1 except for 2 outstanding review issues: > > - Would like to hear back final comments from Joe Darcy on the new doc > changes/CCC request > - Phil pointed out that there is an unneeded import in some of the > files. I agree that we should make a final webrev to delete them, but > I don't need to approve it if that is the only change... > > ...jim > > On 2/8/17 11:56 PM, Jayathirth D V wrote: >> Hello All, >> >> There was a closed test which was failing because of >> identity-as-equals approach for ColorModel equals() method. >> I have modified it and added in the webrev. Along with this we are >> now using colorspace.hashCode() in hashCode() functions instead of >> Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in >> IndexColorModel equals() method because Arrays.copyOf() takes lot of >> time. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ >> >> Ran jtreg test and JCK there are no additional test case failures >> because of the above change. Only 4 JCK tests are failing as it was >> happening previously. >> >> Just copy pasted my observation regarding JCK failures so that we can >> trace it easily: >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test >> cases: 4; passed: 3; failed: 1; first test case failure: >> ColorModel2001 >> >> This test fails because getComponentSize() returned an array with >> length 3 but it expects the length to be 4. In the test case they >> have bits per component array of length 4 like {8, 8, 8, 8}. But >> in the test case wherever they are passing "has Alpha" as "false" we >> omit the alpha component bit. This is because of tighter check >> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >> >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >> cases: 3; passed: 2; failed: 1; first test case failure: >> ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having >> same values, but it fails because now we are using identity-as-equals >> check in ColorModel. >> >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: >> ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel >> objects having same values, but it fails since we don't have hashCode >> check in ColorModel and it will be different between 2 Objects. >> >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >> testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >> also happening because of same reason as why the first JCK test is >> failing. We omit alpha bit if hasAlpha is false but JCK test >> tries to call getComponentSize() with index 3 which throws >> ArrayIndexOutOfBoundsException. >> >> Thanks, >> Jay >> -----Original Message----- >> From: Jayathirth D V >> Sent: Wednesday, February 08, 2017 3:41 PM >> To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> Hello All, >> >> I have updated the webrev to include the following changes. >> >> 1) Have identity as equals check in equals() method of ColorModel >> but elaborate the specification of equals() and hashCode() in >> ColorModel on what properties to check in subclasses of >> ColorModel. >> 2) Made changes to test case to have single helper method >> wherever we have same equals/hashCode() check. >> 3) Updated IndexColorModel equals() method to use Arrays.equals() >> for rgb[] data. >> 4) Add comment on why we are not using validBits to calculate >> hashCode() in IndexColorModel hashCode() method. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, February 02, 2017 2:51 AM >> To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> I think we should move this issue (array size returned from >> getCompSizes) into a separate bug entry and a separate fix. >> I don't think we need to fix the clone() in the constructor and the >> getter just to get hashcode/equals right... >> >> ...jim >> >> On 1/31/17 2:34 PM, Jim Graham wrote: >>> For an application to run into this same issue they'd have to expect >>> getCompSizes() to return data for components that don't exist. It's >>> unlikely they would use that data if they really understand the >>> objects. While that would be odd, I guess I can see someone might >>> be constructing all of their CM's from an array of 4 components >>> regardless of the number of actual components and we'd be happily >>> remembering the useless extra components and returning an array of 4 >>> from getCompSizes(). As I said, they shouldn't really be reading >>> and interpreting those extra components for any image processing, >>> but I can imagine that they might do something like create a variant >>> CM by calling the CompSizes() and copying them into a new array to >>> construct a new CM with modifications. They might just robotically >>> always copy 4 values without really checking how many are valid. >>> That's a stretch, and their code is weak. I can conceive of how >>> this might happen, but I really have no idea how likely it is... >>> >>> ...jim >>> >>> On 1/30/17 3:56 PM, Phil Race wrote: >>>> Sounds like we should at least try to get the tests updated so they >>>> only test what the spec. says. >>>> Although it does indicate that there is at least a chance that >>>> application code might also fail due to similar assumptions. >>>> Does #1 not fail with the previous iteration of this change too ? >>>> >>>> -phil. >>>> >>>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>>> Hmmm. Sounds like the test cases were written based on bugs in >>>>> the implementation. I'm not sure what the best tactic is here for >>>>> the short term for getting this in, but many of these changes >>>>> should eventually be considered bugs in the tests. Is it >>>>> acceptable to break API tests like this at the last minute even if >>>>> the tests are at fault? Phil? >>>>> >>>>> Notes on specific instances below... >>>>> >>>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>>> Hi Phil, >>>>>> >>>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>>> ColorModel2001 >>>>>> >>>>>> This test fails because getComponentSize() returned an array >>>>>> with length 3 but it expects the length to be 4. In >>>>>> the test case they have bits per component array of length 4 >>>>>> like {8, 8, 8, 8}. But in the test case wherever they are passing >>>>>> "has Alpha" as "false" we omit the alpha >>>>>> component bit. This is because of tighter check that we >>>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>>> >>>>> This is a bug in the test then, especially if the size of our >>>>> array matches the return value of getNumComponents. >>>>> >>>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>>>> cases: 3; passed: 2; failed: 1; first test case >>>>>> failure: ColorModel0004 >>>>>> >>>>>> Here they check for equality between 2 ColorModel objects >>>>>> having same values, but it fails because now we are using >>>>>> identity-as-equals check in ColorModel. >>>>> >>>>> How do they accomplish this when the CM class is abstract? Do >>>>> they create a relatively empty subclass and instantiate that? >>>>> >>>>> The documentation for the equals() method does not document the >>>>> conditions under which it returns true, it uses a vague concept of >>>>> "equals this ColorModel". I don't see how they could test >>>>> anything given that documentation. >>>>> >>>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>>> failure: ColorModel2006 >>>>>> >>>>>> Here they check for hashCode equality between 2 ColorModel >>>>>> objects having same values, but it fails since we >>>>>> don't have hashCode check in ColorModel and it will be >>>>>> different between 2 Objects. >>>>> >>>>> Same as above, there are no promises documented. >>>>> >>>>>> >>>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTe >>>>>> st >>>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>>> failed: 1; first test case failure: testCase1 >>>>>> >>>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >>>>>> also happening because of same reason as why the first JCK test >>>>>> is failing. We omit alpha bit if hasAlpha is false but JCK test >>>>>> tries to call getComponentSize() with index 3 which throws >>>>>> ArrayIndexOutOfBoundsException. >>>>> >>>>> Same assessment as #1 above... >>>>> >>>>> Again, while these are my recommendations about the correctness of >>>>> these tests, the question remains whether we want to introduce a >>>>> change at this point in the release cycle that will essentially >>>>> invalidate a number of tests that have been working for several >>>>> releases already. I'll leave that tactic issue to Phil... >>>>> >>>>> ...jim >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: End of 2d-dev Digest, Vol 117, Issue 3 ************************************** From prahalad.kumar.narayanan at oracle.com Fri Feb 10 04:21:42 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 9 Feb 2017 20:21:42 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: Hello Phil A very good feedback: > I am OK with this if you can confirm that removing Lucida Sans Regular from the JDK does not cause any nasty exceptions. I believe, removing Lucida Sans Regular from JDK won't cause any trouble. Reason is that- FontManager.findFont2D should return NULL in this case. The logic that follows this call in CFont.java checks if number of physical fonts is lesser than expected count and updates the list of fonts accordingly. 234 if (idx < fonts.length) { 235 PhysicalFont[] orig = fonts; 236 fonts = new PhysicalFont[idx]; 237 System.arraycopy(orig, 0, fonts, 0, idx); 238 } A quick look at SunFontManager.findFont2D : The definition invokes findJREDeferredFont method to first search for an entry in jreFontMap and then initialize the Lucida Sans font. If the initialization succeeds a valid physical font is returned. Upon failure, it should return NULL. Thanks Have a good day Prahalad N. ---------------------------------------------------------------------- Message: 1 Date: Thu, 09 Feb 2017 19:09:00 -0800 From: Philip Race To: Prasanta Sadhukhan Cc: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: <589D2ECC.4090505 at oracle.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" I am OK with this if you can confirm that removing Lucida Sans Regular from the JDK does not cause any nasty exceptions. Apple use the PostScript name but our lookup code should work for the TrueType name. So overall I think this should be fine - from visual inspection - and assuming it has been tested :-) +1 -phil. On 2/9/17, 1:08 AM, Prasanta Sadhukhan wrote: > > Hi All, > > Please review a fix for an issue which causes arabic character "alef" > to be not rendered in osx for menlo font in italic style. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 > > The issue was actually a regression caused by the fix to JDK-7162125: > [macosx] A font has different behaviour for ligatures depending on its > creation mode in which we have added cascaded font list to find the > real fonts that CFont uses, so that there is no need to use "negative" > glyph code for finding the fallback fonts using the > "subsititution"/"fallback" mechanism used by osx code. > > However, the above logic of using cascaded font list in CFont does not > take into account of using JRE provided fonts like all those Lucida* > ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' > character) is intended to be rendered in Menlo font in italic style, > osx will not be able to find the glyph in Menlo-Italic font and > neither in all the cascaded system fonts provided by CoreText, so it > results in empty box. > > Before 7162125 fix, the fallback code in > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() > uses JRSFontCreateFallbackFontForCharacters() > was adding jre/lib/fonts to the fallback list which was causing the > glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was > rendered. > > So, the proposed fix is to add jre provided font "Lucida Sans Regular" > to the cascaded list so that we get the "alef" glyph. > The reason for choosing "Lucida Sans Regular" over "Lucida Bright > Regular" is, because it is the largest font file in jre and has all > the glyph codepoints that no other font in the jre has, so we will not > lose out on any codepoints and will help us in not getting missing > glyph. > > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ > > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 9 Feb 2017 19:34:34 -0800 (PST) From: Prahalad Kumar Narayanan To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: <98e3b75f-b2e5-41a4-9489-62ec34b05985 at default> Content-Type: text/plain; charset=us-ascii The change looks good. +1. Minor observation: The copyright should be updated to 2017 in the CFont.java file. If you use any script to update the same, then ignore this observation. Thanks Have a good day Prahalad N. -----Original Message----- From: 2d-dev-request at openjdk.java.net [mailto:2d-dev-request at openjdk.java.net] Sent: Friday, February 10, 2017 3:37 AM To: 2d-dev at openjdk.java.net Subject: 2d-dev Digest, Vol 117, Issue 3 Send 2d-dev mailing list submissions to 2d-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/2d-dev or, via email, send a message with subject or body 'help' to 2d-dev-request at openjdk.java.net You can reach the person managing the list at 2d-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of 2d-dev digest..." Today's Topics: 1. [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X (Prasanta Sadhukhan) 2. RFR: 8172967: [macosx] Exception while working with layout for text containing unmappable character (Philip Race) 3. Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods (Jim Graham) 4. Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods (Phil Race) ---------------------------------------------------------------------- Message: 1 Date: Thu, 9 Feb 2017 14:38:11 +0530 From: Prasanta Sadhukhan To: 2d-dev <2d-dev at openjdk.java.net>, Philip Race Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: <459b6a81-1ae9-9876-e86a-c567dd4529e8 at oracle.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi All, Please review a fix for an issue which causes arabic character "alef" to be not rendered in osx for menlo font in italic style. Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 The issue was actually a regression caused by the fix to JDK-7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode in which we have added cascaded font list to find the real fonts that CFont uses, so that there is no need to use "negative" glyph code for finding the fallback fonts using the "subsititution"/"fallback" mechanism used by osx code. However, the above logic of using cascaded font list in CFont does not take into account of using JRE provided fonts like all those Lucida* ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' character) is intended to be rendered in Menlo font in italic style, osx will not be able to find the glyph in Menlo-Italic font and neither in all the cascaded system fonts provided by CoreText, so it results in empty box. Before 7162125 fix, the fallback code in CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses JRSFontCreateFallbackFontForCharacters() was adding jre/lib/fonts to the fallback list which was causing the glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was rendered. So, the proposed fix is to add jre provided font "Lucida Sans Regular" to the cascaded list so that we get the "alef" glyph. The reason for choosing "Lucida Sans Regular" over "Lucida Bright Regular" is, because it is the largest font file in jre and has all the glyph codepoints that no other font in the jre has, so we will not lose out on any codepoints and will help us in not getting missing glyph. webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 09 Feb 2017 11:30:26 -0800 From: Philip Race To: 2d-dev <2d-dev at openjdk.java.net> Subject: [OpenJDK 2D-Dev] RFR: 8172967: [macosx] Exception while working with layout for text containing unmappable character Message-ID: <589CC352.6040408 at oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed http://cr.openjdk.java.net/~prr/8172967/ https://bugs.openjdk.java.net/browse/JDK-8172967 Full evaluation in the bug report. Short summary: avoid AIOB and NPE when Mac glyph mapper returns a negated unicode which is misinterpreted as having composite font slot 255 -phil. ------------------------------ Message: 3 Date: Thu, 9 Feb 2017 13:59:37 -0800 From: Jim Graham To: Jayathirth D V , Philip Race , 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Message-ID: Content-Type: text/plain; charset=windows-1252; format=flowed From my end this looks good. +1 except for 2 outstanding review issues: - Would like to hear back final comments from Joe Darcy on the new doc changes/CCC request - Phil pointed out that there is an unneeded import in some of the files. I agree that we should make a final webrev to delete them, but I don't need to approve it if that is the only change... ...jim On 2/8/17 11:56 PM, Jayathirth D V wrote: > Hello All, > > There was a closed test which was failing because of identity-as-equals approach for ColorModel equals() method. > I have modified it and added in the webrev. Along with this we are now using colorspace.hashCode() in hashCode() functions instead of Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in IndexColorModel equals() method because Arrays.copyOf() takes lot of time. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ > > Ran jtreg test and JCK there are no additional test case failures because of the above change. Only 4 JCK tests are failing as it was happening previously. > > Just copy pasted my observation regarding JCK failures so that we can trace it easily: > > 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test > cases: 4; passed: 3; failed: 1; first test case failure: > ColorModel2001 > > This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. > > 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: > 3; passed: 2; failed: 1; first test case failure: ColorModel0004 > > Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. > > 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test > cases: 2; passed: 1; failed: 1; first test case failure: > ColorModel2006 > > Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. > > 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttes > tCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case > failure: testCase1 > > Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. > > Thanks, > Jay > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, February 08, 2017 3:41 PM > To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > > Hello All, > > I have updated the webrev to include the following changes. > > 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. > 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. > 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. > 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, February 02, 2017 2:51 AM > To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > > I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. > I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... > > ...jim > > On 1/31/17 2:34 PM, Jim Graham wrote: >> For an application to run into this same issue they'd have to expect >> getCompSizes() to return data for components that don't exist. It's >> unlikely they would use that data if they really understand the >> objects. While that would be odd, I guess I can see someone might be >> constructing all of their CM's from an array of 4 components >> regardless of the number of actual components and we'd be happily >> remembering the useless extra components and returning an array of 4 >> from getCompSizes(). As I said, they shouldn't really be reading and >> interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... >> >> ...jim >> >> On 1/30/17 3:56 PM, Phil Race wrote: >>> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >>> Although it does indicate that there is at least a chance that >>> application code might also fail due to similar assumptions. >>> Does #1 not fail with the previous iteration of this change too ? >>> >>> -phil. >>> >>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>> Hmmm. Sounds like the test cases were written based on bugs in the >>>> implementation. I'm not sure what the best tactic is here for the >>>> short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>>> >>>> Notes on specific instances below... >>>> >>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>> Hi Phil, >>>>> >>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>> ColorModel2001 >>>>> >>>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>> >>>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>>> >>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. >>>>> test >>>>> cases: 3; passed: 2; failed: 1; first test case >>>>> failure: ColorModel0004 >>>>> >>>>> Here they check for equality between 2 ColorModel objects >>>>> having same values, but it fails because now we are using identity-as-equals check in ColorModel. >>>> >>>> How do they accomplish this when the CM class is abstract? Do they >>>> create a relatively empty subclass and instantiate that? >>>> >>>> The documentation for the equals() method does not document the >>>> conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>>> >>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>> failure: ColorModel2006 >>>>> >>>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>>> >>>> Same as above, there are no promises documented. >>>> >>>>> >>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTes >>>>> t >>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>> failed: 1; first test case failure: testCase1 >>>>> >>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>>> >>>> Same assessment as #1 above... >>>> >>>> Again, while these are my recommendations about the correctness of >>>> these tests, the question remains whether we want to introduce a >>>> change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... >>>> >>>> ...jim >>>> >>> ------------------------------ Message: 4 Date: Thu, 9 Feb 2017 14:05:24 -0800 From: Phil Race To: Jim Graham , Jayathirth D V , 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Message-ID: <78dab679-6b22-ea05-5418-67528881b960 at oracle.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Oh .. my reply was to an off-list email. I did not notice that. So I should repeat that here : On 2/9/17 12:38 PM, Phil Race wrote: > 32 import java.util.Objects; > > This is now un-used, isn't it ? Yet all 3 subclasses still have this > import. > > I don't need to "approve" a new webrev containing that but it would be > good to publish one. > > +1 -phil. On 02/09/2017 01:59 PM, Jim Graham wrote: > From my end this looks good. +1 except for 2 outstanding review issues: > > - Would like to hear back final comments from Joe Darcy on the new doc > changes/CCC request > - Phil pointed out that there is an unneeded import in some of the > files. I agree that we should make a final webrev to delete them, but > I don't need to approve it if that is the only change... > > ...jim > > On 2/8/17 11:56 PM, Jayathirth D V wrote: >> Hello All, >> >> There was a closed test which was failing because of >> identity-as-equals approach for ColorModel equals() method. >> I have modified it and added in the webrev. Along with this we are >> now using colorspace.hashCode() in hashCode() functions instead of >> Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in >> IndexColorModel equals() method because Arrays.copyOf() takes lot of >> time. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ >> >> Ran jtreg test and JCK there are no additional test case failures >> because of the above change. Only 4 JCK tests are failing as it was >> happening previously. >> >> Just copy pasted my observation regarding JCK failures so that we can >> trace it easily: >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test >> cases: 4; passed: 3; failed: 1; first test case failure: >> ColorModel2001 >> >> This test fails because getComponentSize() returned an array with >> length 3 but it expects the length to be 4. In the test case they >> have bits per component array of length 4 like {8, 8, 8, 8}. But >> in the test case wherever they are passing "has Alpha" as "false" we >> omit the alpha component bit. This is because of tighter check >> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >> >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >> cases: 3; passed: 2; failed: 1; first test case failure: >> ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having >> same values, but it fails because now we are using identity-as-equals >> check in ColorModel. >> >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: >> ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel >> objects having same values, but it fails since we don't have hashCode >> check in ColorModel and it will be different between 2 Objects. >> >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >> testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >> also happening because of same reason as why the first JCK test is >> failing. We omit alpha bit if hasAlpha is false but JCK test >> tries to call getComponentSize() with index 3 which throws >> ArrayIndexOutOfBoundsException. >> >> Thanks, >> Jay >> -----Original Message----- >> From: Jayathirth D V >> Sent: Wednesday, February 08, 2017 3:41 PM >> To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> Hello All, >> >> I have updated the webrev to include the following changes. >> >> 1) Have identity as equals check in equals() method of ColorModel >> but elaborate the specification of equals() and hashCode() in >> ColorModel on what properties to check in subclasses of >> ColorModel. >> 2) Made changes to test case to have single helper method >> wherever we have same equals/hashCode() check. >> 3) Updated IndexColorModel equals() method to use Arrays.equals() >> for rgb[] data. >> 4) Add comment on why we are not using validBits to calculate >> hashCode() in IndexColorModel hashCode() method. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, February 02, 2017 2:51 AM >> To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> I think we should move this issue (array size returned from >> getCompSizes) into a separate bug entry and a separate fix. >> I don't think we need to fix the clone() in the constructor and the >> getter just to get hashcode/equals right... >> >> ...jim >> >> On 1/31/17 2:34 PM, Jim Graham wrote: >>> For an application to run into this same issue they'd have to expect >>> getCompSizes() to return data for components that don't exist. It's >>> unlikely they would use that data if they really understand the >>> objects. While that would be odd, I guess I can see someone might >>> be constructing all of their CM's from an array of 4 components >>> regardless of the number of actual components and we'd be happily >>> remembering the useless extra components and returning an array of 4 >>> from getCompSizes(). As I said, they shouldn't really be reading >>> and interpreting those extra components for any image processing, >>> but I can imagine that they might do something like create a variant >>> CM by calling the CompSizes() and copying them into a new array to >>> construct a new CM with modifications. They might just robotically >>> always copy 4 values without really checking how many are valid. >>> That's a stretch, and their code is weak. I can conceive of how >>> this might happen, but I really have no idea how likely it is... >>> >>> ...jim >>> >>> On 1/30/17 3:56 PM, Phil Race wrote: >>>> Sounds like we should at least try to get the tests updated so they >>>> only test what the spec. says. >>>> Although it does indicate that there is at least a chance that >>>> application code might also fail due to similar assumptions. >>>> Does #1 not fail with the previous iteration of this change too ? >>>> >>>> -phil. >>>> >>>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>>> Hmmm. Sounds like the test cases were written based on bugs in >>>>> the implementation. I'm not sure what the best tactic is here for >>>>> the short term for getting this in, but many of these changes >>>>> should eventually be considered bugs in the tests. Is it >>>>> acceptable to break API tests like this at the last minute even if >>>>> the tests are at fault? Phil? >>>>> >>>>> Notes on specific instances below... >>>>> >>>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>>> Hi Phil, >>>>>> >>>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>>> ColorModel2001 >>>>>> >>>>>> This test fails because getComponentSize() returned an array >>>>>> with length 3 but it expects the length to be 4. In >>>>>> the test case they have bits per component array of length 4 >>>>>> like {8, 8, 8, 8}. But in the test case wherever they are passing >>>>>> "has Alpha" as "false" we omit the alpha >>>>>> component bit. This is because of tighter check that we >>>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>>> >>>>> This is a bug in the test then, especially if the size of our >>>>> array matches the return value of getNumComponents. >>>>> >>>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>>>> cases: 3; passed: 2; failed: 1; first test case >>>>>> failure: ColorModel0004 >>>>>> >>>>>> Here they check for equality between 2 ColorModel objects >>>>>> having same values, but it fails because now we are using >>>>>> identity-as-equals check in ColorModel. >>>>> >>>>> How do they accomplish this when the CM class is abstract? Do >>>>> they create a relatively empty subclass and instantiate that? >>>>> >>>>> The documentation for the equals() method does not document the >>>>> conditions under which it returns true, it uses a vague concept of >>>>> "equals this ColorModel". I don't see how they could test >>>>> anything given that documentation. >>>>> >>>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>>> failure: ColorModel2006 >>>>>> >>>>>> Here they check for hashCode equality between 2 ColorModel >>>>>> objects having same values, but it fails since we >>>>>> don't have hashCode check in ColorModel and it will be >>>>>> different between 2 Objects. >>>>> >>>>> Same as above, there are no promises documented. >>>>> >>>>>> >>>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTe >>>>>> st >>>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>>> failed: 1; first test case failure: testCase1 >>>>>> >>>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >>>>>> also happening because of same reason as why the first JCK test >>>>>> is failing. We omit alpha bit if hasAlpha is false but JCK test >>>>>> tries to call getComponentSize() with index 3 which throws >>>>>> ArrayIndexOutOfBoundsException. >>>>> >>>>> Same assessment as #1 above... >>>>> >>>>> Again, while these are my recommendations about the correctness of >>>>> these tests, the question remains whether we want to introduce a >>>>> change at this point in the release cycle that will essentially >>>>> invalidate a number of tests that have been working for several >>>>> releases already. I'll leave that tactic issue to Phil... >>>>> >>>>> ...jim >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: End of 2d-dev Digest, Vol 117, Issue 3 ************************************** End of 2d-dev Digest, Vol 117, Issue 4 ************************************** From jayathirth.d.v at oracle.com Fri Feb 10 04:41:50 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 9 Feb 2017 20:41:50 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: [JDK-6852563] ArrayOutOfBoundException when reading RLE8 compressed bitmap In-Reply-To: <589A562F.5050507@oracle.com> References: <589A562F.5050507@oracle.com> Message-ID: <09a4cb6e-64b6-49b8-86a4-f31f90f75fee@default> Hi Prahalad, Changes are fine. Thanks, Jay -----Original Message----- From: Philip Race Sent: Wednesday, February 08, 2017 4:50 AM To: Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: [JDK-6852563] ArrayOutOfBoundException when reading RLE8 compressed bitmap That was deja vu all over again. I wonder if there is some additional sharing that can be done here between RLE4 and RLE8. But not right now .. just something to think about. +1 -phil. On 2/6/17, 7:46 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for the bug [JDK-6852563] > ArrayOutOfBoundException when reading RLE8 compressed bitmap > > Root Cause > . The issue is similar to JDK-8167278 except for the difference in the Bitmap's compression format. > . The issue surfaces when either of the following holds true- > . When a malformed RLE8 bitmap image is decoded /or > . When a valid RLE8 bitmap image with 'Delta sequence' is decoded. > > Details on the Fix: > . Necessary guard conditions have been put in RLE8 bitmap decoding code. > . Handling of Delta encoding (0x00 0x02 xOffset yOffset) in source image has been corrected with appropriate logic. > . [Note] No regression test case has been provided with the fix. > . The fix will require input RLE8 bitmap as mentioned in the root cause. > . When we tried to create one such bitmap using Gimp editor, the resulting image didn't contain corruption /or the delta sequence to trigger the issue. > . However, the fix was tested with all RLE8 Bitmap images from bitmap test suite (including corrupt images) and no issues were seen. > > Other Details: > . The fix was run through both Jtreg and JCK test suites. No regressions were noticed. > > The changes are available for your review under: > Link: http://cr.openjdk.java.net/~pnarayanan/6852563/webrev.00/ > > Kindly review the changes at your convenience and share your feedback. > > Thank you for your time in review > Have a good day > > Prahalad N. From jayathirth.d.v at oracle.com Fri Feb 10 04:51:39 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 9 Feb 2017 20:51:39 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <78dab679-6b22-ea05-5418-67528881b960@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> <496e0881-eb9e-4d51-b655-c15e46a50fc9@default> <78dab679-6b22-ea05-5418-67528881b960@oracle.com> Message-ID: Hi, Phil & Jim thanks for your review. I have modified the code to remove the unneeded import of import java.util.Objects. Please find the updated webrev : http://cr.openjdk.java.net/~jdv/7107905/webrev.19/ Thanks, Jay From: Phil Race Sent: Friday, February 10, 2017 3:35 AM To: Jim Graham; Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Oh .. my reply was to an off-list email. I did not notice that. So I should repeat that here : On 2/9/17 12:38 PM, Phil Race wrote: 32 import java.util.Objects; This is now un-used, isn't it ? Yet all 3 subclasses still have this import. I don't need to "approve" a new webrev containing that but it would be good to publish one. +1 -phil. On 02/09/2017 01:59 PM, Jim Graham wrote: >From my end this looks good. +1 except for 2 outstanding review issues: - Would like to hear back final comments from Joe Darcy on the new doc changes/CCC request - Phil pointed out that there is an unneeded import in some of the files. I agree that we should make a final webrev to delete them, but I don't need to approve it if that is the only change... ...jim On 2/8/17 11:56 PM, Jayathirth D V wrote: Hello All, There was a closed test which was failing because of identity-as-equals approach for ColorModel equals() method. I have modified it and added in the webrev. Along with this we are now using colorspace.hashCode() in hashCode() functions instead of Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in IndexColorModel equals() method because Arrays.copyOf() takes lot of time. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ Ran jtreg test and JCK there are no additional test case failures because of the above change. Only 4 JCK tests are failing as it was happening previously. Just copy pasted my observation regarding JCK failures so that we can trace it easily: 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test case failure: ColorModel2001 This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: testCase1 Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Wednesday, February 08, 2017 3:41 PM To: Jim Graham; Philip Race; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Hello All, I have updated the webrev to include the following changes. 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, February 02, 2017 2:51 AM To: Phil Race; Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... ...jim On 1/31/17 2:34 PM, Jim Graham wrote: For an application to run into this same issue they'd have to expect getCompSizes() to return data for components that don't exist. It's unlikely they would use that data if they really understand the objects. While that would be odd, I guess I can see someone might be constructing all of their CM's from an array of 4 components regardless of the number of actual components and we'd be happily remembering the useless extra components and returning an array of 4 from getCompSizes(). As I said, they shouldn't really be reading and interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... ...jim On 1/30/17 3:56 PM, Phil Race wrote: Sounds like we should at least try to get the tests updated so they only test what the spec. says. Although it does indicate that there is at least a chance that application code might also fail due to similar assumptions. Does #1 not fail with the previous iteration of this change too ? -phil. On 01/30/2017 01:40 PM, Jim Graham wrote: Hmmm. Sounds like the test cases were written based on bugs in the implementation. I'm not sure what the best tactic is here for the short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? Notes on specific instances below... On 1/30/17 2:22 AM, Jayathirth D V wrote: Hi Phil, 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test case failure: ColorModel2001 This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. How do they accomplish this when the CM class is abstract? Do they create a relatively empty subclass and instantiate that? The documentation for the equals() method does not document the conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. Same as above, there are no promises documented. 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTest testCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: testCase1 Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. Same assessment as #1 above... Again, while these are my recommendations about the correctness of these tests, the question remains whether we want to introduce a change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... ...jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Feb 10 05:01:48 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 10 Feb 2017 10:31:48 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: References: Message-ID: <3fd294d3-6eaa-17eb-c36f-b96f57667fb2@oracle.com> Hi Phil, Yes, I agree with Prahalad's findings. If "Lucida Sans Regular" is removed, then findFont2D() call, later on called in createCompositeFont() will return null and so the font2D object will not get added to the list of Physical fonts and we will get missing glyph ie empty box and NOT an exception. I have tested this scenario too. Regards Prasanta On 2/10/2017 9:51 AM, Prahalad Kumar Narayanan wrote: > Hello Phil > > A very good feedback: >> I am OK with this if you can confirm that removing Lucida Sans Regular from the JDK does not cause any nasty exceptions. > I believe, removing Lucida Sans Regular from JDK won't cause any trouble. > > Reason is that- FontManager.findFont2D should return NULL in this case. The logic that follows this call in CFont.java checks if number of physical fonts is lesser than expected count and updates the list of fonts accordingly. > 234 if (idx < fonts.length) { > 235 PhysicalFont[] orig = fonts; > 236 fonts = new PhysicalFont[idx]; > 237 System.arraycopy(orig, 0, fonts, 0, idx); > 238 } > > A quick look at SunFontManager.findFont2D : The definition invokes findJREDeferredFont method to first search for an entry in jreFontMap and then initialize the Lucida Sans font. If the initialization succeeds a valid physical font is returned. Upon failure, it should return NULL. > > Thanks > Have a good day > > Prahalad N. > > ---------------------------------------------------------------------- > Message: 1 > Date: Thu, 09 Feb 2017 19:09:00 -0800 > From: Philip Race > To: Prasanta Sadhukhan > Cc: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic > character cannot be rendered on MacOS X > Message-ID: <589D2ECC.4090505 at oracle.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > I am OK with this if you can confirm that removing Lucida Sans Regular from the JDK does not cause any nasty exceptions. > > Apple use the PostScript name but our lookup code should work for the TrueType name. > > So overall I think this should be fine - from visual inspection - and assuming it has been tested :-) > > +1 > > -phil. > > On 2/9/17, 1:08 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue which causes arabic character "alef" >> to be not rendered in osx for menlo font in italic style. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 >> >> The issue was actually a regression caused by the fix to JDK-7162125: >> [macosx] A font has different behaviour for ligatures depending on its >> creation mode in which we have added cascaded font list to find the >> real fonts that CFont uses, so that there is no need to use "negative" >> glyph code for finding the fallback fonts using the >> "subsititution"/"fallback" mechanism used by osx code. >> >> However, the above logic of using cascaded font list in CFont does not >> take into account of using JRE provided fonts like all those Lucida* >> ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' >> character) is intended to be rendered in Menlo font in italic style, >> osx will not be able to find the glyph in Menlo-Italic font and >> neither in all the cascaded system fonts provided by CoreText, so it >> results in empty box. >> >> Before 7162125 fix, the fallback code in >> CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() >> uses JRSFontCreateFallbackFontForCharacters() >> was adding jre/lib/fonts to the fallback list which was causing the >> glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was >> rendered. >> >> So, the proposed fix is to add jre provided font "Lucida Sans Regular" >> to the cascaded list so that we get the "alef" glyph. >> The reason for choosing "Lucida Sans Regular" over "Lucida Bright >> Regular" is, because it is the largest font file in jre and has all >> the glyph codepoints that no other font in the jre has, so we will not >> lose out on any codepoints and will help us in not getting missing >> glyph. >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ >> >> >> Regards >> Prasanta > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Thu, 9 Feb 2017 19:34:34 -0800 (PST) > From: Prahalad Kumar Narayanan > To: 2d-dev at openjdk.java.net > Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic > character cannot be rendered on MacOS X > Message-ID: <98e3b75f-b2e5-41a4-9489-62ec34b05985 at default> > Content-Type: text/plain; charset=us-ascii > > The change looks good. +1. > > Minor observation: The copyright should be updated to 2017 in the CFont.java file. > If you use any script to update the same, then ignore this observation. > > Thanks > Have a good day > > Prahalad N. > > -----Original Message----- > From: 2d-dev-request at openjdk.java.net [mailto:2d-dev-request at openjdk.java.net] > Sent: Friday, February 10, 2017 3:37 AM > To: 2d-dev at openjdk.java.net > Subject: 2d-dev Digest, Vol 117, Issue 3 > > Send 2d-dev mailing list submissions to > 2d-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/2d-dev > or, via email, send a message with subject or body 'help' to > 2d-dev-request at openjdk.java.net > > You can reach the person managing the list at > 2d-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific than "Re: Contents of 2d-dev digest..." > > > Today's Topics: > > 1. [9] RFR JDK-8147002:[macosx] Arabic character cannot be > rendered on MacOS X (Prasanta Sadhukhan) > 2. RFR: 8172967: [macosx] Exception while working with layout > for text containing unmappable character (Philip Race) > 3. Re: Review Request for JDK-7107905: ColorModel subclasses > are missing hashCode() or equals() or both methods (Jim Graham) > 4. Re: Review Request for JDK-7107905: ColorModel subclasses > are missing hashCode() or equals() or both methods (Phil Race) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 9 Feb 2017 14:38:11 +0530 > From: Prasanta Sadhukhan > To: 2d-dev <2d-dev at openjdk.java.net>, Philip Race > > Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic > character cannot be rendered on MacOS X > Message-ID: <459b6a81-1ae9-9876-e86a-c567dd4529e8 at oracle.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi All, > > Please review a fix for an issue which causes arabic character "alef" to be not rendered in osx for menlo font in italic style. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 > > The issue was actually a regression caused by the fix to JDK-7162125: > [macosx] A font has different behaviour for ligatures depending on its creation mode in which we have added cascaded font list to find the real fonts that CFont uses, so that there is no need to use "negative" glyph code for finding the fallback fonts using the "subsititution"/"fallback" mechanism used by osx code. > > However, the above logic of using cascaded font list in CFont does not take into account of using JRE provided fonts like all those Lucida* ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' character) is intended to be rendered in Menlo font in italic style, osx will not be able to find the glyph in Menlo-Italic font and neither in all the cascaded system fonts provided by CoreText, so it results in empty box. > > Before 7162125 fix, the fallback code in > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses > JRSFontCreateFallbackFontForCharacters() > was adding jre/lib/fonts to the fallback list which was causing the glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was rendered. > > So, the proposed fix is to add jre provided font "Lucida Sans Regular" > to the cascaded list so that we get the "alef" glyph. > The reason for choosing "Lucida Sans Regular" over "Lucida Bright Regular" is, because it is the largest font file in jre and has all the glyph codepoints that no other font in the jre has, so we will not lose out on any codepoints and will help us in not getting missing glyph. > > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ > > Regards > Prasanta > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Thu, 09 Feb 2017 11:30:26 -0800 > From: Philip Race > To: 2d-dev <2d-dev at openjdk.java.net> > Subject: [OpenJDK 2D-Dev] RFR: 8172967: [macosx] Exception while > working with layout for text containing unmappable character > Message-ID: <589CC352.6040408 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > http://cr.openjdk.java.net/~prr/8172967/ > https://bugs.openjdk.java.net/browse/JDK-8172967 > > Full evaluation in the bug report. > Short summary: avoid AIOB and NPE when Mac glyph mapper returns a negated unicode which is misinterpreted as having composite font slot 255 > > -phil. > > > ------------------------------ > > Message: 3 > Date: Thu, 9 Feb 2017 13:59:37 -0800 > From: Jim Graham > To: Jayathirth D V , Philip Race > , 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > Message-ID: > Content-Type: text/plain; charset=windows-1252; format=flowed > > From my end this looks good. +1 except for 2 outstanding review issues: > > - Would like to hear back final comments from Joe Darcy on the new doc changes/CCC request > - Phil pointed out that there is an unneeded import in some of the files. I agree that we should make a final webrev to delete them, but I don't need to approve it if that is the only change... > > ...jim > > On 2/8/17 11:56 PM, Jayathirth D V wrote: >> Hello All, >> >> There was a closed test which was failing because of identity-as-equals approach for ColorModel equals() method. >> I have modified it and added in the webrev. Along with this we are now using colorspace.hashCode() in hashCode() functions instead of Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in IndexColorModel equals() method because Arrays.copyOf() takes lot of time. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ >> >> Ran jtreg test and JCK there are no additional test case failures because of the above change. Only 4 JCK tests are failing as it was happening previously. >> >> Just copy pasted my observation regarding JCK failures so that we can trace it easily: >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test >> cases: 4; passed: 3; failed: 1; first test case failure: >> ColorModel2001 >> >> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. >> >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: >> 3; passed: 2; failed: 1; first test case failure: ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. >> >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: >> ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. >> >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttes >> tCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case >> failure: testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. >> >> Thanks, >> Jay >> -----Original Message----- >> From: Jayathirth D V >> Sent: Wednesday, February 08, 2017 3:41 PM >> To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> Hello All, >> >> I have updated the webrev to include the following changes. >> >> 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. >> 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. >> 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. >> 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, February 02, 2017 2:51 AM >> To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. >> I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... >> >> ...jim >> >> On 1/31/17 2:34 PM, Jim Graham wrote: >>> For an application to run into this same issue they'd have to expect >>> getCompSizes() to return data for components that don't exist. It's >>> unlikely they would use that data if they really understand the >>> objects. While that would be odd, I guess I can see someone might be >>> constructing all of their CM's from an array of 4 components >>> regardless of the number of actual components and we'd be happily >>> remembering the useless extra components and returning an array of 4 >>> from getCompSizes(). As I said, they shouldn't really be reading and >>> interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... >>> >>> ...jim >>> >>> On 1/30/17 3:56 PM, Phil Race wrote: >>>> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >>>> Although it does indicate that there is at least a chance that >>>> application code might also fail due to similar assumptions. >>>> Does #1 not fail with the previous iteration of this change too ? >>>> >>>> -phil. >>>> >>>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>>> Hmmm. Sounds like the test cases were written based on bugs in the >>>>> implementation. I'm not sure what the best tactic is here for the >>>>> short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>>>> >>>>> Notes on specific instances below... >>>>> >>>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>>> Hi Phil, >>>>>> >>>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>>> ColorModel2001 >>>>>> >>>>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>>>> >>>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. >>>>>> test >>>>>> cases: 3; passed: 2; failed: 1; first test case >>>>>> failure: ColorModel0004 >>>>>> >>>>>> Here they check for equality between 2 ColorModel objects >>>>>> having same values, but it fails because now we are using identity-as-equals check in ColorModel. >>>>> How do they accomplish this when the CM class is abstract? Do they >>>>> create a relatively empty subclass and instantiate that? >>>>> >>>>> The documentation for the equals() method does not document the >>>>> conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>>>> >>>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>>> failure: ColorModel2006 >>>>>> >>>>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>>>> Same as above, there are no promises documented. >>>>> >>>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTes >>>>>> t >>>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>>> failed: 1; first test case failure: testCase1 >>>>>> >>>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>>>> Same assessment as #1 above... >>>>> >>>>> Again, while these are my recommendations about the correctness of >>>>> these tests, the question remains whether we want to introduce a >>>>> change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... >>>>> >>>>> ...jim >>>>> > > ------------------------------ > > Message: 4 > Date: Thu, 9 Feb 2017 14:05:24 -0800 > From: Phil Race > To: Jim Graham , Jayathirth D V > , 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > Message-ID: <78dab679-6b22-ea05-5418-67528881b960 at oracle.com> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Oh .. my reply was to an off-list email. I did not notice that. > So I should repeat that here : > > On 2/9/17 12:38 PM, Phil Race wrote: >> 32 import java.util.Objects; >> >> This is now un-used, isn't it ? Yet all 3 subclasses still have this >> import. >> >> I don't need to "approve" a new webrev containing that but it would be >> good to publish one. >> >> +1 > -phil. > > > On 02/09/2017 01:59 PM, Jim Graham wrote: >> From my end this looks good. +1 except for 2 outstanding review issues: >> >> - Would like to hear back final comments from Joe Darcy on the new doc >> changes/CCC request >> - Phil pointed out that there is an unneeded import in some of the >> files. I agree that we should make a final webrev to delete them, but >> I don't need to approve it if that is the only change... >> >> ...jim >> >> On 2/8/17 11:56 PM, Jayathirth D V wrote: >>> Hello All, >>> >>> There was a closed test which was failing because of >>> identity-as-equals approach for ColorModel equals() method. >>> I have modified it and added in the webrev. Along with this we are >>> now using colorspace.hashCode() in hashCode() functions instead of >>> Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in >>> IndexColorModel equals() method because Arrays.copyOf() takes lot of >>> time. >>> >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ >>> >>> Ran jtreg test and JCK there are no additional test case failures >>> because of the above change. Only 4 JCK tests are failing as it was >>> happening previously. >>> >>> Just copy pasted my observation regarding JCK failures so that we can >>> trace it easily: >>> >>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test >>> cases: 4; passed: 3; failed: 1; first test case failure: >>> ColorModel2001 >>> >>> This test fails because getComponentSize() returned an array with >>> length 3 but it expects the length to be 4. In the test case they >>> have bits per component array of length 4 like {8, 8, 8, 8}. But >>> in the test case wherever they are passing "has Alpha" as "false" we >>> omit the alpha component bit. This is because of tighter check >>> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>> >>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>> cases: 3; passed: 2; failed: 1; first test case failure: >>> ColorModel0004 >>> >>> Here they check for equality between 2 ColorModel objects having >>> same values, but it fails because now we are using identity-as-equals >>> check in ColorModel. >>> >>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >>> cases: 2; passed: 1; failed: 1; first test case failure: >>> ColorModel2006 >>> >>> Here they check for hashCode equality between 2 ColorModel >>> objects having same values, but it fails since we don't have hashCode >>> check in ColorModel and it will be different between 2 Objects. >>> >>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >>> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >>> testCase1 >>> >>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >>> also happening because of same reason as why the first JCK test is >>> failing. We omit alpha bit if hasAlpha is false but JCK test >>> tries to call getComponentSize() with index 3 which throws >>> ArrayIndexOutOfBoundsException. >>> >>> Thanks, >>> Jay >>> -----Original Message----- >>> From: Jayathirth D V >>> Sent: Wednesday, February 08, 2017 3:41 PM >>> To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>> ColorModel subclasses are missing hashCode() or equals() or both >>> methods >>> >>> Hello All, >>> >>> I have updated the webrev to include the following changes. >>> >>> 1) Have identity as equals check in equals() method of ColorModel >>> but elaborate the specification of equals() and hashCode() in >>> ColorModel on what properties to check in subclasses of >>> ColorModel. >>> 2) Made changes to test case to have single helper method >>> wherever we have same equals/hashCode() check. >>> 3) Updated IndexColorModel equals() method to use Arrays.equals() >>> for rgb[] data. >>> 4) Add comment on why we are not using validBits to calculate >>> hashCode() in IndexColorModel hashCode() method. >>> >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Thursday, February 02, 2017 2:51 AM >>> To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>> ColorModel subclasses are missing hashCode() or equals() or both >>> methods >>> >>> I think we should move this issue (array size returned from >>> getCompSizes) into a separate bug entry and a separate fix. >>> I don't think we need to fix the clone() in the constructor and the >>> getter just to get hashcode/equals right... >>> >>> ...jim >>> >>> On 1/31/17 2:34 PM, Jim Graham wrote: >>>> For an application to run into this same issue they'd have to expect >>>> getCompSizes() to return data for components that don't exist. It's >>>> unlikely they would use that data if they really understand the >>>> objects. While that would be odd, I guess I can see someone might >>>> be constructing all of their CM's from an array of 4 components >>>> regardless of the number of actual components and we'd be happily >>>> remembering the useless extra components and returning an array of 4 >>>> from getCompSizes(). As I said, they shouldn't really be reading >>>> and interpreting those extra components for any image processing, >>>> but I can imagine that they might do something like create a variant >>>> CM by calling the CompSizes() and copying them into a new array to >>>> construct a new CM with modifications. They might just robotically >>>> always copy 4 values without really checking how many are valid. >>>> That's a stretch, and their code is weak. I can conceive of how >>>> this might happen, but I really have no idea how likely it is... >>>> >>>> ...jim >>>> >>>> On 1/30/17 3:56 PM, Phil Race wrote: >>>>> Sounds like we should at least try to get the tests updated so they >>>>> only test what the spec. says. >>>>> Although it does indicate that there is at least a chance that >>>>> application code might also fail due to similar assumptions. >>>>> Does #1 not fail with the previous iteration of this change too ? >>>>> >>>>> -phil. >>>>> >>>>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>>>> Hmmm. Sounds like the test cases were written based on bugs in >>>>>> the implementation. I'm not sure what the best tactic is here for >>>>>> the short term for getting this in, but many of these changes >>>>>> should eventually be considered bugs in the tests. Is it >>>>>> acceptable to break API tests like this at the last minute even if >>>>>> the tests are at fault? Phil? >>>>>> >>>>>> Notes on specific instances below... >>>>>> >>>>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>>>> ColorModel2001 >>>>>>> >>>>>>> This test fails because getComponentSize() returned an array >>>>>>> with length 3 but it expects the length to be 4. In >>>>>>> the test case they have bits per component array of length 4 >>>>>>> like {8, 8, 8, 8}. But in the test case wherever they are passing >>>>>>> "has Alpha" as "false" we omit the alpha >>>>>>> component bit. This is because of tighter check that we >>>>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>>>> This is a bug in the test then, especially if the size of our >>>>>> array matches the return value of getNumComponents. >>>>>> >>>>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>>>>> cases: 3; passed: 2; failed: 1; first test case >>>>>>> failure: ColorModel0004 >>>>>>> >>>>>>> Here they check for equality between 2 ColorModel objects >>>>>>> having same values, but it fails because now we are using >>>>>>> identity-as-equals check in ColorModel. >>>>>> How do they accomplish this when the CM class is abstract? Do >>>>>> they create a relatively empty subclass and instantiate that? >>>>>> >>>>>> The documentation for the equals() method does not document the >>>>>> conditions under which it returns true, it uses a vague concept of >>>>>> "equals this ColorModel". I don't see how they could test >>>>>> anything given that documentation. >>>>>> >>>>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>>>> failure: ColorModel2006 >>>>>>> >>>>>>> Here they check for hashCode equality between 2 ColorModel >>>>>>> objects having same values, but it fails since we >>>>>>> don't have hashCode check in ColorModel and it will be >>>>>>> different between 2 Objects. >>>>>> Same as above, there are no promises documented. >>>>>> >>>>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTe >>>>>>> st >>>>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>>>> failed: 1; first test case failure: testCase1 >>>>>>> >>>>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >>>>>>> also happening because of same reason as why the first JCK test >>>>>>> is failing. We omit alpha bit if hasAlpha is false but JCK test >>>>>>> tries to call getComponentSize() with index 3 which throws >>>>>>> ArrayIndexOutOfBoundsException. >>>>>> Same assessment as #1 above... >>>>>> >>>>>> Again, while these are my recommendations about the correctness of >>>>>> these tests, the question remains whether we want to introduce a >>>>>> change at this point in the release cycle that will essentially >>>>>> invalidate a number of tests that have been working for several >>>>>> releases already. I'll leave that tactic issue to Phil... >>>>>> >>>>>> ...jim >>>>>> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > End of 2d-dev Digest, Vol 117, Issue 3 > ************************************** > > > End of 2d-dev Digest, Vol 117, Issue 4 > ************************************** From philip.race at oracle.com Fri Feb 10 05:12:54 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 09 Feb 2017 21:12:54 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> <476f36ad-7503-a4d6-4ccf-262c5c651559@oracle.com> <496e0881-eb9e-4d51-b655-c15e46a50fc9@default> <78dab679-6b22-ea05-5418-67528881b960@oracle.com> Message-ID: <589D4BD6.6040405@oracle.com> So +1 .. and please update the CCC -phil. On 2/9/17, 8:51 PM, Jayathirth D V wrote: > > Hi, > > Phil & Jim thanks for your review. > > I have modified the code to remove the unneeded import of import > java.util.Objects. > > Please find the updated webrev : > > http://cr.openjdk.java.net/~jdv/7107905/webrev.19/ > > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Friday, February 10, 2017 3:35 AM > *To:* Jim Graham; Jayathirth D V; 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both methods > > Oh .. my reply was to an off-list email. I did not notice that. > So I should repeat that here : > > On 2/9/17 12:38 PM, Phil Race wrote: > > 32 import java.util.Objects; > > This is now un-used, isn't it ? Yet all 3 subclasses still have > this import. > > I don't need to "approve" a new webrev containing that but it would > be good to publish one. > > +1 > > > -phil. > > On 02/09/2017 01:59 PM, Jim Graham wrote: > > From my end this looks good. +1 except for 2 outstanding review > issues: > > - Would like to hear back final comments from Joe Darcy on the new > doc changes/CCC request > - Phil pointed out that there is an unneeded import in some of the > files. I agree that we should make a final webrev to delete them, > but I don't need to approve it if that is the only change... > > ...jim > > On 2/8/17 11:56 PM, Jayathirth D V wrote: > > Hello All, > > There was a closed test which was failing because of > identity-as-equals approach for ColorModel equals() method. > I have modified it and added in the webrev. Along with this we > are now using colorspace.hashCode() in hashCode() functions > instead of Objects.hashCode(this.colorspace). Reverted using > Arrays.equals() in IndexColorModel equals() method because > Arrays.copyOf() takes lot of time. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ > > > Ran jtreg test and JCK there are no additional test case > failures because of the above change. Only 4 JCK tests are > failing as it was happening previously. > > Just copy pasted my observation regarding JCK failures so that > we can trace it easily: > > 1)api/java_awt/Image/ColorModel/index.html#Constructor: > Failed. test cases: 4; passed: 3; failed: 1; first test case > failure: ColorModel2001 > > This test fails because getComponentSize() returned an > array with length 3 but it expects the length to be 4. In the > test case they have bits per component array of length 4 > like {8, 8, 8, 8}. But in the test case wherever they are > passing "has Alpha" as "false" we omit the alpha component > bit. This is because of tighter check that we have in > ColorModel class as "nBits = Arrays.copyOf(bits, > numComponents);" . "numComponents" will be 3 if hasAlpha is > false. > > 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. > test cases: 3; passed: 2; failed: 1; first test case failure: > ColorModel0004 > > Here they check for equality between 2 ColorModel objects > having same values, but it fails because now we are using > identity-as-equals check in ColorModel. > > 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. > test cases: 2; passed: 1; failed: 1; first test case failure: > ColorModel2006 > > Here they check for hashCode equality between 2 ColorModel > objects having same values, but it fails since we don't have > hashCode check in ColorModel and it will be different > between 2 Objects. > > 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: > Failed. test cases: 2; passed: 1; failed: 1; first test case > failure: testCase1 > > Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This > is also happening because of same reason as why the first JCK > test is failing. We omit alpha bit if hasAlpha is false > but JCK test tries to call getComponentSize() with index 3 > which throws ArrayIndexOutOfBoundsException. > > Thanks, > Jay > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, February 08, 2017 3:41 PM > To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or > both methods > > Hello All, > > I have updated the webrev to include the following changes. > > 1) Have identity as equals check in equals() method of > ColorModel but elaborate the specification of equals() and > hashCode() in ColorModel on what properties to check > in subclasses of ColorModel. > 2) Made changes to test case to have single helper method > wherever we have same equals/hashCode() check. > 3) Updated IndexColorModel equals() method to use > Arrays.equals() for rgb[] data. > 4) Add comment on why we are not using validBits to > calculate hashCode() in IndexColorModel hashCode() method. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ > > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, February 02, 2017 2:51 AM > To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or > both methods > > I think we should move this issue (array size returned from > getCompSizes) into a separate bug entry and a separate fix. > I don't think we need to fix the clone() in the constructor > and the getter just to get hashcode/equals right... > > ...jim > > On 1/31/17 2:34 PM, Jim Graham wrote: > > For an application to run into this same issue they'd have > to expect > getCompSizes() to return data for components that don't > exist. It's > unlikely they would use that data if they really > understand the > objects. While that would be odd, I guess I can see > someone might be > constructing all of their CM's from an array of 4 components > regardless of the number of actual components and we'd be > happily > remembering the useless extra components and returning an > array of 4 > from getCompSizes(). As I said, they shouldn't really be > reading and > interpreting those extra components for any image > processing, but I can imagine that they might do something > like create a variant CM by calling the CompSizes() and > copying them into a new array to construct a new CM with > modifications. They might just robotically always copy 4 > values without really checking how many are valid. That's > a stretch, and their code is weak. I can conceive of how > this might happen, but I really have no idea how likely it > is... > > ...jim > > On 1/30/17 3:56 PM, Phil Race wrote: > > Sounds like we should at least try to get the tests > updated so they only test what the spec. says. > Although it does indicate that there is at least a > chance that > application code might also fail due to similar > assumptions. > Does #1 not fail with the previous iteration of this > change too ? > > -phil. > > On 01/30/2017 01:40 PM, Jim Graham wrote: > > Hmmm. Sounds like the test cases were written > based on bugs in the > implementation. I'm not sure what the best tactic > is here for the > short term for getting this in, but many of these > changes should eventually be considered bugs in > the tests. Is it acceptable to break API tests > like this at the last minute even if the tests are > at fault? Phil? > > Notes on specific instances below... > > On 1/30/17 2:22 AM, Jayathirth D V wrote: > > Hi Phil, > > > 1)api/java_awt/Image/ColorModel/index.html#Constructor: > Failed. > test cases: 4; passed: 3; failed: 1; first > test case failure: > ColorModel2001 > > This test fails because getComponentSize() > returned an array with length 3 but it expects > the length to be 4. In > the test case they have bits per component > array of length 4 like {8, 8, 8, 8}. But > in the test case wherever > they are passing "has Alpha" as "false" we > omit the alpha component bit. This is because > of tighter check that we > have in ColorModel class as "nBits = > Arrays.copyOf(bits, > numComponents);" . "numComponents" will be 3 > if hasAlpha is false. > > > This is a bug in the test then, especially if the > size of our array matches the return value of > getNumComponents. > > > > 2)api/java_awt/Image/ColorModel/index.html#Equals: > Failed. test > cases: 3; passed: 2; failed: 1; first test case > failure: ColorModel0004 > > Here they check for equality between 2 > ColorModel objects > having same values, but it fails because now > we are using identity-as-equals check in > ColorModel. > > > How do they accomplish this when the CM class is > abstract? Do they > create a relatively empty subclass and instantiate > that? > > The documentation for the equals() method does not > document the > conditions under which it returns true, it uses a > vague concept of "equals this ColorModel". I > don't see how they could test anything given that > documentation. > > > > 3)api/java_awt/Image/ColorModel/index.html#HashCode: > Failed. > test cases: 2; passed: 1; failed: 1; first > test case > failure: ColorModel2006 > > Here they check for hashCode equality > between 2 ColorModel objects having same > values, but it fails since we > don't have hashCode check in ColorModel and > it will be different between 2 Objects. > > > Same as above, there are no promises documented. > > > > 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTest > > testCase1: Failed. test cases: 2; passed: 1; > failed: 1; first test case failure: testCase1 > > Throws > "java.lang.ArrayIndexOutOfBoundsException: 3". > This is also happening because of same reason > as why the > first JCK test is failing. We omit alpha bit > if hasAlpha is false but JCK test tries to > call getComponentSize() > with index 3 which throws > ArrayIndexOutOfBoundsException. > > > Same assessment as #1 above... > > Again, while these are my recommendations about > the correctness of > these tests, the question remains whether we want > to introduce a > change at this point in the release cycle that > will essentially invalidate a number of tests that > have been working for several releases already. > I'll leave that tactic issue to Phil... > > ...jim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Feb 10 06:00:00 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 10 Feb 2017 11:30:00 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8172967: [macosx] Exception while working with layout for text containing unmappable character In-Reply-To: <589CC352.6040408@oracle.com> References: <589CC352.6040408@oracle.com> Message-ID: <4519d84e-486d-7732-0d89-3d8752072c19@oracle.com> I faced the same issue while investigating and trying for solution for 8147002. Looks good to me. Regards Prasanta On 2/10/2017 1:00 AM, Philip Race wrote: > > http://cr.openjdk.java.net/~prr/8172967/ > https://bugs.openjdk.java.net/browse/JDK-8172967 > > Full evaluation in the bug report. > Short summary: avoid AIOB and NPE when Mac glyph mapper returns > a negated unicode which is misinterpreted as having composite font > slot 255 > > -phil. From jayathirth.d.v at oracle.com Fri Feb 10 07:57:47 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 9 Feb 2017 23:57:47 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: <3fd294d3-6eaa-17eb-c36f-b96f57667fb2@oracle.com> References: <3fd294d3-6eaa-17eb-c36f-b96f57667fb2@oracle.com> Message-ID: <04e4d16a-ed57-4481-8ef5-b5e343a89815@default> Hi Prasanta, Changes are fine. Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Friday, February 10, 2017 10:32 AM To: Prahalad Kumar Narayanan; Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Hi Phil, Yes, I agree with Prahalad's findings. If "Lucida Sans Regular" is removed, then findFont2D() call, later on called in createCompositeFont() will return null and so the font2D object will not get added to the list of Physical fonts and we will get missing glyph ie empty box and NOT an exception. I have tested this scenario too. Regards Prasanta On 2/10/2017 9:51 AM, Prahalad Kumar Narayanan wrote: > Hello Phil > > A very good feedback: >> I am OK with this if you can confirm that removing Lucida Sans Regular from the JDK does not cause any nasty exceptions. > I believe, removing Lucida Sans Regular from JDK won't cause any trouble. > > Reason is that- FontManager.findFont2D should return NULL in this case. The logic that follows this call in CFont.java checks if number of physical fonts is lesser than expected count and updates the list of fonts accordingly. > 234 if (idx < fonts.length) { > 235 PhysicalFont[] orig = fonts; > 236 fonts = new PhysicalFont[idx]; > 237 System.arraycopy(orig, 0, fonts, 0, idx); > 238 } > > A quick look at SunFontManager.findFont2D : The definition invokes findJREDeferredFont method to first search for an entry in jreFontMap and then initialize the Lucida Sans font. If the initialization succeeds a valid physical font is returned. Upon failure, it should return NULL. > > Thanks > Have a good day > > Prahalad N. > > ---------------------------------------------------------------------- > Message: 1 > Date: Thu, 09 Feb 2017 19:09:00 -0800 > From: Philip Race > To: Prasanta Sadhukhan > Cc: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic > character cannot be rendered on MacOS X > Message-ID: <589D2ECC.4090505 at oracle.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > I am OK with this if you can confirm that removing Lucida Sans Regular from the JDK does not cause any nasty exceptions. > > Apple use the PostScript name but our lookup code should work for the TrueType name. > > So overall I think this should be fine - from visual inspection - and > assuming it has been tested :-) > > +1 > > -phil. > > On 2/9/17, 1:08 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue which causes arabic character "alef" >> to be not rendered in osx for menlo font in italic style. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 >> >> The issue was actually a regression caused by the fix to JDK-7162125: >> [macosx] A font has different behaviour for ligatures depending on >> its creation mode in which we have added cascaded font list to find >> the real fonts that CFont uses, so that there is no need to use "negative" >> glyph code for finding the fallback fonts using the >> "subsititution"/"fallback" mechanism used by osx code. >> >> However, the above logic of using cascaded font list in CFont does >> not take into account of using JRE provided fonts like all those >> Lucida* ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' >> character) is intended to be rendered in Menlo font in italic style, >> osx will not be able to find the glyph in Menlo-Italic font and >> neither in all the cascaded system fonts provided by CoreText, so it >> results in empty box. >> >> Before 7162125 fix, the fallback code in >> CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() >> uses JRSFontCreateFallbackFontForCharacters() >> was adding jre/lib/fonts to the fallback list which was causing the >> glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was >> rendered. >> >> So, the proposed fix is to add jre provided font "Lucida Sans Regular" >> to the cascaded list so that we get the "alef" glyph. >> The reason for choosing "Lucida Sans Regular" over "Lucida Bright >> Regular" is, because it is the largest font file in jre and has all >> the glyph codepoints that no other font in the jre has, so we will >> not lose out on any codepoints and will help us in not getting >> missing glyph. >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ >> >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > baa90a/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 9 Feb 2017 19:34:34 -0800 (PST) > From: Prahalad Kumar Narayanan > To: 2d-dev at openjdk.java.net > Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic > character cannot be rendered on MacOS X > Message-ID: <98e3b75f-b2e5-41a4-9489-62ec34b05985 at default> > Content-Type: text/plain; charset=us-ascii > > The change looks good. +1. > > Minor observation: The copyright should be updated to 2017 in the CFont.java file. > If you use any script to update the same, then ignore this observation. > > Thanks > Have a good day > > Prahalad N. > > -----Original Message----- > From: 2d-dev-request at openjdk.java.net > [mailto:2d-dev-request at openjdk.java.net] > Sent: Friday, February 10, 2017 3:37 AM > To: 2d-dev at openjdk.java.net > Subject: 2d-dev Digest, Vol 117, Issue 3 > > Send 2d-dev mailing list submissions to > 2d-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/2d-dev > or, via email, send a message with subject or body 'help' to > 2d-dev-request at openjdk.java.net > > You can reach the person managing the list at > 2d-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific than "Re: Contents of 2d-dev digest..." > > > Today's Topics: > > 1. [9] RFR JDK-8147002:[macosx] Arabic character cannot be > rendered on MacOS X (Prasanta Sadhukhan) > 2. RFR: 8172967: [macosx] Exception while working with layout > for text containing unmappable character (Philip Race) > 3. Re: Review Request for JDK-7107905: ColorModel subclasses > are missing hashCode() or equals() or both methods (Jim Graham) > 4. Re: Review Request for JDK-7107905: ColorModel subclasses > are missing hashCode() or equals() or both methods (Phil Race) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 9 Feb 2017 14:38:11 +0530 > From: Prasanta Sadhukhan > To: 2d-dev <2d-dev at openjdk.java.net>, Philip Race > > Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic > character cannot be rendered on MacOS X > Message-ID: <459b6a81-1ae9-9876-e86a-c567dd4529e8 at oracle.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi All, > > Please review a fix for an issue which causes arabic character "alef" to be not rendered in osx for menlo font in italic style. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 > > The issue was actually a regression caused by the fix to JDK-7162125: > [macosx] A font has different behaviour for ligatures depending on its creation mode in which we have added cascaded font list to find the real fonts that CFont uses, so that there is no need to use "negative" glyph code for finding the fallback fonts using the "subsititution"/"fallback" mechanism used by osx code. > > However, the above logic of using cascaded font list in CFont does not take into account of using JRE provided fonts like all those Lucida* ttf in jdk/lib/fonts/, so when a glyph (in this intance, arabic 'alef' character) is intended to be rendered in Menlo font in italic style, osx will not be able to find the glyph in Menlo-Italic font and neither in all the cascaded system fonts provided by CoreText, so it results in empty box. > > Before 7162125 fix, the fallback code in > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() > uses > JRSFontCreateFallbackFontForCharacters() > was adding jre/lib/fonts to the fallback list which was causing the glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was rendered. > > So, the proposed fix is to add jre provided font "Lucida Sans Regular" > to the cascaded list so that we get the "alef" glyph. > The reason for choosing "Lucida Sans Regular" over "Lucida Bright Regular" is, because it is the largest font file in jre and has all the glyph codepoints that no other font in the jre has, so we will not lose out on any codepoints and will help us in not getting missing glyph. > > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > d48b17/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 09 Feb 2017 11:30:26 -0800 > From: Philip Race > To: 2d-dev <2d-dev at openjdk.java.net> > Subject: [OpenJDK 2D-Dev] RFR: 8172967: [macosx] Exception while > working with layout for text containing unmappable character > Message-ID: <589CC352.6040408 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > http://cr.openjdk.java.net/~prr/8172967/ > https://bugs.openjdk.java.net/browse/JDK-8172967 > > Full evaluation in the bug report. > Short summary: avoid AIOB and NPE when Mac glyph mapper returns a > negated unicode which is misinterpreted as having composite font slot > 255 > > -phil. > > > ------------------------------ > > Message: 3 > Date: Thu, 9 Feb 2017 13:59:37 -0800 > From: Jim Graham > To: Jayathirth D V , Philip Race > , 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > Message-ID: > Content-Type: text/plain; charset=windows-1252; format=flowed > > From my end this looks good. +1 except for 2 outstanding review issues: > > - Would like to hear back final comments from Joe Darcy on the new doc > changes/CCC request > - Phil pointed out that there is an unneeded import in some of the files. I agree that we should make a final webrev to delete them, but I don't need to approve it if that is the only change... > > ...jim > > On 2/8/17 11:56 PM, Jayathirth D V wrote: >> Hello All, >> >> There was a closed test which was failing because of identity-as-equals approach for ColorModel equals() method. >> I have modified it and added in the webrev. Along with this we are now using colorspace.hashCode() in hashCode() functions instead of Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in IndexColorModel equals() method because Arrays.copyOf() takes lot of time. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ >> >> Ran jtreg test and JCK there are no additional test case failures because of the above change. Only 4 JCK tests are failing as it was happening previously. >> >> Just copy pasted my observation regarding JCK failures so that we can trace it easily: >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test >> cases: 4; passed: 3; failed: 1; first test case failure: >> ColorModel2001 >> >> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. >> >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: >> 3; passed: 2; failed: 1; first test case failure: ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. >> >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: >> ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. >> >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTestte >> s >> tCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case >> failure: testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. >> >> Thanks, >> Jay >> -----Original Message----- >> From: Jayathirth D V >> Sent: Wednesday, February 08, 2017 3:41 PM >> To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> Hello All, >> >> I have updated the webrev to include the following changes. >> >> 1) Have identity as equals check in equals() method of ColorModel but elaborate the specification of equals() and hashCode() in ColorModel on what properties to check in subclasses of ColorModel. >> 2) Made changes to test case to have single helper method wherever we have same equals/hashCode() check. >> 3) Updated IndexColorModel equals() method to use Arrays.equals() for rgb[] data. >> 4) Add comment on why we are not using validBits to calculate hashCode() in IndexColorModel hashCode() method. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, February 02, 2017 2:51 AM >> To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> I think we should move this issue (array size returned from getCompSizes) into a separate bug entry and a separate fix. >> I don't think we need to fix the clone() in the constructor and the getter just to get hashcode/equals right... >> >> ...jim >> >> On 1/31/17 2:34 PM, Jim Graham wrote: >>> For an application to run into this same issue they'd have to expect >>> getCompSizes() to return data for components that don't exist. It's >>> unlikely they would use that data if they really understand the >>> objects. While that would be odd, I guess I can see someone might >>> be constructing all of their CM's from an array of 4 components >>> regardless of the number of actual components and we'd be happily >>> remembering the useless extra components and returning an array of 4 >>> from getCompSizes(). As I said, they shouldn't really be reading >>> and interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... >>> >>> ...jim >>> >>> On 1/30/17 3:56 PM, Phil Race wrote: >>>> Sounds like we should at least try to get the tests updated so they only test what the spec. says. >>>> Although it does indicate that there is at least a chance that >>>> application code might also fail due to similar assumptions. >>>> Does #1 not fail with the previous iteration of this change too ? >>>> >>>> -phil. >>>> >>>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>>> Hmmm. Sounds like the test cases were written based on bugs in >>>>> the implementation. I'm not sure what the best tactic is here for >>>>> the short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >>>>> >>>>> Notes on specific instances below... >>>>> >>>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>>> Hi Phil, >>>>>> >>>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>>> ColorModel2001 >>>>>> >>>>>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>>>>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>>>>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>>> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >>>>> >>>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. >>>>>> test >>>>>> cases: 3; passed: 2; failed: 1; first test case >>>>>> failure: ColorModel0004 >>>>>> >>>>>> Here they check for equality between 2 ColorModel objects >>>>>> having same values, but it fails because now we are using identity-as-equals check in ColorModel. >>>>> How do they accomplish this when the CM class is abstract? Do >>>>> they create a relatively empty subclass and instantiate that? >>>>> >>>>> The documentation for the equals() method does not document the >>>>> conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >>>>> >>>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>>> failure: ColorModel2006 >>>>>> >>>>>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>>>>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >>>>> Same as above, there are no promises documented. >>>>> >>>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTe >>>>>> s >>>>>> t >>>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>>> failed: 1; first test case failure: testCase1 >>>>>> >>>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>>>>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>>>>> with index 3 which throws ArrayIndexOutOfBoundsException. >>>>> Same assessment as #1 above... >>>>> >>>>> Again, while these are my recommendations about the correctness of >>>>> these tests, the question remains whether we want to introduce a >>>>> change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... >>>>> >>>>> ...jim >>>>> > > ------------------------------ > > Message: 4 > Date: Thu, 9 Feb 2017 14:05:24 -0800 > From: Phil Race > To: Jim Graham , Jayathirth D V > , 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > Message-ID: <78dab679-6b22-ea05-5418-67528881b960 at oracle.com> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Oh .. my reply was to an off-list email. I did not notice that. > So I should repeat that here : > > On 2/9/17 12:38 PM, Phil Race wrote: >> 32 import java.util.Objects; >> >> This is now un-used, isn't it ? Yet all 3 subclasses still have this >> import. >> >> I don't need to "approve" a new webrev containing that but it would >> be good to publish one. >> >> +1 > -phil. > > > On 02/09/2017 01:59 PM, Jim Graham wrote: >> From my end this looks good. +1 except for 2 outstanding review issues: >> >> - Would like to hear back final comments from Joe Darcy on the new >> doc changes/CCC request >> - Phil pointed out that there is an unneeded import in some of the >> files. I agree that we should make a final webrev to delete them, >> but I don't need to approve it if that is the only change... >> >> ...jim >> >> On 2/8/17 11:56 PM, Jayathirth D V wrote: >>> Hello All, >>> >>> There was a closed test which was failing because of >>> identity-as-equals approach for ColorModel equals() method. >>> I have modified it and added in the webrev. Along with this we are >>> now using colorspace.hashCode() in hashCode() functions instead of >>> Objects.hashCode(this.colorspace). Reverted using Arrays.equals() in >>> IndexColorModel equals() method because Arrays.copyOf() takes lot of >>> time. >>> >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.18/ >>> >>> Ran jtreg test and JCK there are no additional test case failures >>> because of the above change. Only 4 JCK tests are failing as it was >>> happening previously. >>> >>> Just copy pasted my observation regarding JCK failures so that we >>> can trace it easily: >>> >>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test >>> cases: 4; passed: 3; failed: 1; first test case failure: >>> ColorModel2001 >>> >>> This test fails because getComponentSize() returned an array >>> with length 3 but it expects the length to be 4. In the test case they >>> have bits per component array of length 4 like {8, 8, 8, 8}. But >>> in the test case wherever they are passing "has Alpha" as "false" we >>> omit the alpha component bit. This is because of tighter check that >>> we have in ColorModel class as "nBits = Arrays.copyOf(bits, >>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>> >>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>> cases: 3; passed: 2; failed: 1; first test case failure: >>> ColorModel0004 >>> >>> Here they check for equality between 2 ColorModel objects >>> having same values, but it fails because now we are using >>> identity-as-equals check in ColorModel. >>> >>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >>> cases: 2; passed: 1; failed: 1; first test case failure: >>> ColorModel2006 >>> >>> Here they check for hashCode equality between 2 ColorModel >>> objects having same values, but it fails since we don't have hashCode >>> check in ColorModel and it will be different between 2 Objects. >>> >>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >>> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >>> testCase1 >>> >>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >>> also happening because of same reason as why the first JCK test is >>> failing. We omit alpha bit if hasAlpha is false but JCK test >>> tries to call getComponentSize() with index 3 which throws >>> ArrayIndexOutOfBoundsException. >>> >>> Thanks, >>> Jay >>> -----Original Message----- >>> From: Jayathirth D V >>> Sent: Wednesday, February 08, 2017 3:41 PM >>> To: Jim Graham; Philip Race; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>> ColorModel subclasses are missing hashCode() or equals() or both >>> methods >>> >>> Hello All, >>> >>> I have updated the webrev to include the following changes. >>> >>> 1) Have identity as equals check in equals() method of >>> ColorModel but elaborate the specification of equals() and hashCode() in >>> ColorModel on what properties to check in subclasses of >>> ColorModel. >>> 2) Made changes to test case to have single helper method >>> wherever we have same equals/hashCode() check. >>> 3) Updated IndexColorModel equals() method to use >>> Arrays.equals() for rgb[] data. >>> 4) Add comment on why we are not using validBits to calculate >>> hashCode() in IndexColorModel hashCode() method. >>> >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.17/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Thursday, February 02, 2017 2:51 AM >>> To: Phil Race; Jayathirth D V; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>> ColorModel subclasses are missing hashCode() or equals() or both >>> methods >>> >>> I think we should move this issue (array size returned from >>> getCompSizes) into a separate bug entry and a separate fix. >>> I don't think we need to fix the clone() in the constructor and the >>> getter just to get hashcode/equals right... >>> >>> ...jim >>> >>> On 1/31/17 2:34 PM, Jim Graham wrote: >>>> For an application to run into this same issue they'd have to >>>> expect >>>> getCompSizes() to return data for components that don't exist. >>>> It's unlikely they would use that data if they really understand >>>> the objects. While that would be odd, I guess I can see someone >>>> might be constructing all of their CM's from an array of 4 >>>> components regardless of the number of actual components and we'd >>>> be happily remembering the useless extra components and returning >>>> an array of 4 from getCompSizes(). As I said, they shouldn't >>>> really be reading and interpreting those extra components for any >>>> image processing, but I can imagine that they might do something >>>> like create a variant CM by calling the CompSizes() and copying >>>> them into a new array to construct a new CM with modifications. >>>> They might just robotically always copy 4 values without really checking how many are valid. >>>> That's a stretch, and their code is weak. I can conceive of how >>>> this might happen, but I really have no idea how likely it is... >>>> >>>> ...jim >>>> >>>> On 1/30/17 3:56 PM, Phil Race wrote: >>>>> Sounds like we should at least try to get the tests updated so >>>>> they only test what the spec. says. >>>>> Although it does indicate that there is at least a chance that >>>>> application code might also fail due to similar assumptions. >>>>> Does #1 not fail with the previous iteration of this change too ? >>>>> >>>>> -phil. >>>>> >>>>> On 01/30/2017 01:40 PM, Jim Graham wrote: >>>>>> Hmmm. Sounds like the test cases were written based on bugs in >>>>>> the implementation. I'm not sure what the best tactic is here >>>>>> for the short term for getting this in, but many of these changes >>>>>> should eventually be considered bugs in the tests. Is it >>>>>> acceptable to break API tests like this at the last minute even >>>>>> if the tests are at fault? Phil? >>>>>> >>>>>> Notes on specific instances below... >>>>>> >>>>>> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>>>>>> test cases: 4; passed: 3; failed: 1; first test case failure: >>>>>>> ColorModel2001 >>>>>>> >>>>>>> This test fails because getComponentSize() returned an >>>>>>> array with length 3 but it expects the length to be 4. In >>>>>>> the test case they have bits per component array of length 4 >>>>>>> like {8, 8, 8, 8}. But in the test case wherever they are >>>>>>> passing "has Alpha" as "false" we omit the alpha >>>>>>> component bit. This is because of tighter check that we >>>>>>> have in ColorModel class as "nBits = Arrays.copyOf(bits, >>>>>>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >>>>>> This is a bug in the test then, especially if the size of our >>>>>> array matches the return value of getNumComponents. >>>>>> >>>>>>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>>>>>> cases: 3; passed: 2; failed: 1; first test case >>>>>>> failure: ColorModel0004 >>>>>>> >>>>>>> Here they check for equality between 2 ColorModel objects >>>>>>> having same values, but it fails because now we are using >>>>>>> identity-as-equals check in ColorModel. >>>>>> How do they accomplish this when the CM class is abstract? Do >>>>>> they create a relatively empty subclass and instantiate that? >>>>>> >>>>>> The documentation for the equals() method does not document the >>>>>> conditions under which it returns true, it uses a vague concept >>>>>> of "equals this ColorModel". I don't see how they could test >>>>>> anything given that documentation. >>>>>> >>>>>>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. >>>>>>> test cases: 2; passed: 1; failed: 1; first test case >>>>>>> failure: ColorModel2006 >>>>>>> >>>>>>> Here they check for hashCode equality between 2 ColorModel >>>>>>> objects having same values, but it fails since we >>>>>>> don't have hashCode check in ColorModel and it will be >>>>>>> different between 2 Objects. >>>>>> Same as above, there are no promises documented. >>>>>> >>>>>>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorT >>>>>>> e >>>>>>> st >>>>>>> testCase1: Failed. test cases: 2; passed: 1; >>>>>>> failed: 1; first test case failure: testCase1 >>>>>>> >>>>>>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This >>>>>>> is also happening because of same reason as why the first JCK >>>>>>> test is failing. We omit alpha bit if hasAlpha is false but JCK >>>>>>> test tries to call getComponentSize() with index 3 which throws >>>>>>> ArrayIndexOutOfBoundsException. >>>>>> Same assessment as #1 above... >>>>>> >>>>>> Again, while these are my recommendations about the correctness >>>>>> of these tests, the question remains whether we want to introduce >>>>>> a change at this point in the release cycle that will essentially >>>>>> invalidate a number of tests that have been working for several >>>>>> releases already. I'll leave that tactic issue to Phil... >>>>>> >>>>>> ...jim >>>>>> > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 1a98ce/attachment.html> > > End of 2d-dev Digest, Vol 117, Issue 3 > ************************************** > > > End of 2d-dev Digest, Vol 117, Issue 4 > ************************************** From dmitry.batrak at jetbrains.com Fri Feb 10 09:07:41 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Fri, 10 Feb 2017 12:07:41 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170552: [macosx] Wrong rendering of diacritics on macOS Message-ID: Hello, I'd like to propose a fix for JDK-8170552. bug: https://bugs.openjdk.java.net/browse/JDK-8170552 webrev: http://cr.openjdk.java.net/~dbatrak/8170552/webrev.00/ I don't have a Committer status, so I'll require a sponsor. I've proposed this patch earlier via support ticket (it's also attached to JIRA issue). It brings the code used to detect complex text when working with system fonts on macOS on par with similar code used for other fonts and platforms. As compared to the previously provided patch, I've also added a test case. It depends on specifics of the font being used (Menlo), but I couldn't think of another way to create an automated test for this issue. Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at tagtraum.com Fri Feb 10 09:12:22 2017 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 10 Feb 2017 10:12:22 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] Deadlock in CGLGraphicsConfig.getCGLConfigInfo In-Reply-To: References: <18AD0EF9-82B2-4BD6-904A-EF1B0F72E7EA@oracle.com> <21F7FC1E-B806-4DDF-AC92-AE8C0A85BF0E@xk72.com> Message-ID: <4F3006E4-934C-4D9B-8DC7-1CC1F2517835@tagtraum.com> Hey there, just curious regarding the state of this bug. @Karl: Did someone review your patch? Or did you gain any additional support for submitting it? It would be a shame to not incorporate the fix, just because it was simply forgotten? -hendrik > On Jan 12, 2017, at 08:58, Hendrik Schreiber wrote: > > >> On Jan 12, 2017, at 04:22, Karl von Randow wrote: >> >> I?m sorry I didn?t discover this bug somehow! > > Who cares??I really appreciate that you provide a fix after no progress has been made for more than half a year! > > That?s awesome. > > -hendrik > From dmitry.batrak at jetbrains.com Fri Feb 10 09:13:39 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Fri, 10 Feb 2017 12:13:39 +0300 Subject: [OpenJDK 2D-Dev] Reporting new bugs (with Author role) Message-ID: Hello again, Now that I have an OpenJDK account, it seems like I can create new tickets directly in OpenJDK JIRA instance (https://bugs.openjdk.java.net/). Should I use this way, or should I continue to use http://bugreport.java.com/ to report new bugs? I'm mostly speaking about bugs for which I'm ready to propose a fix myself. Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Fri Feb 10 14:34:33 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Feb 2017 17:34:33 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8172967: [macosx] Exception while working with layout for text containing unmappable character In-Reply-To: <4519d84e-486d-7732-0d89-3d8752072c19@oracle.com> References: <589CC352.6040408@oracle.com> <4519d84e-486d-7732-0d89-3d8752072c19@oracle.com> Message-ID: <75B28669-92F9-42B9-96B5-1A5A80B46C29@oracle.com> > Looks good to me. +1 > > Regards > Prasanta > On 2/10/2017 1:00 AM, Philip Race wrote: >> >> http://cr.openjdk.java.net/~prr/8172967/ >> https://bugs.openjdk.java.net/browse/JDK-8172967 >> >> Full evaluation in the bug report. >> Short summary: avoid AIOB and NPE when Mac glyph mapper returns >> a negated unicode which is misinterpreted as having composite font slot 255 >> >> -phil. > From dalibor.topic at oracle.com Fri Feb 10 11:44:54 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 10 Feb 2017 12:44:54 +0100 Subject: [OpenJDK 2D-Dev] Reporting new bugs (with Author role) In-Reply-To: References: Message-ID: On 10.02.2017 10:13, Dmitry Batrak wrote: > Hello again, > > Now that I have an OpenJDK account, it seems like I can create new > tickets directly in OpenJDK JIRA instance > (https://bugs.openjdk.java.net/). Should I use this way, or should I > continue to use http://bugreport.java.com/ to report new bugs? I'm > mostly speaking about bugs for which I'm ready to propose a fix myself. As an Author, please use bugs.openjdk.java.net for issues. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dmitry.batrak at jetbrains.com Fri Feb 10 15:59:21 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Fri, 10 Feb 2017 18:59:21 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X Message-ID: Hi, I've tried to build OpenJDK from 'client' repository with the fix, and the issue is still reproducible for me. Are you fixing it only for Oracle JDK (including Lucida Sans Regular font), and not for OpenJDK? The problem is not that some character cannot be rendered using a particular font, it's that rendering behaviour doesn't match what 'canDisplay' returns. If you're interested I can share the way we've fixed this issue in our OpenJDK-based runtime. As you've mentioned, the problem is that JRSFontCreateFallbackFontForCharacters returns fallback font, which is not on the cascaded font list, and it can be absent even in the whole list of fonts reported by the system. On my machine, with OpenJDK, it's .GeezaProInterface (with name starting with dot). I guess such fonts are treated by macOS as 'hidden' (just like files with names starting with dots), still they seem to be usable from application if requested by their name. As JRSFontCreateFallbackFontForCharacters is a 'black box', it's hard to make sure cascade list we're building matches its internal logic, so we've chosen to build the list dynamically based on the output of JRSFontCreateFallbackFontForCharacters itself. I can try to prepare corresponding webrev, if you think that can be useful. Alternative solution (and, probably, a better one strategically), would be not using JRSFontCreateFallbackFontForCharacters at all. The cascade list, that is built currently, can probably be used to perform font fallback in all cases. Best regards, Dmitry Batrak > Hi All, > > Please review a fix for an issue which causes arabic character "alef" to > be not rendered in osx for menlo font in italic style. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 > > The issue was actually a regression caused by the fix to JDK-7162125: > [macosx] A font has different behaviour for ligatures depending on its > creation mode > in which we have added cascaded font list to find the real fonts that > CFont uses, so that there is no need to use "negative" glyph code for > finding the fallback fonts > using the "subsititution"/"fallback" mechanism used by osx code. > > However, the above logic of using cascaded font list in CFont does not > take into account of using JRE provided fonts like all those Lucida* ttf > in jdk/lib/fonts/, so > when a glyph (in this intance, arabic 'alef' character) is intended to > be rendered in Menlo font in italic style, osx will not be able to find > the glyph in Menlo-Italic font > and neither in all the cascaded system fonts provided by CoreText, so it > results in empty box. > > Before 7162125 fix, the fallback code in > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses > JRSFontCreateFallbackFontForCharacters() > was adding jre/lib/fonts to the fallback list which was causing the > glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was > rendered. > > So, the proposed fix is to add jre provided font "Lucida Sans Regular" > to the cascaded list so that we get the "alef" glyph. > The reason for choosing "Lucida Sans Regular" over "Lucida Bright > Regular" is, because it is the largest font file in jre and has all the > glyph codepoints that no other font in the jre has, > so we will not lose out on any codepoints and will help us in not > getting missing glyph. > > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Feb 10 17:19:50 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 10 Feb 2017 09:19:50 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: References: Message-ID: I think that so long as we are using JRS* in some places and CoreText's cascading list in others there is the likelihood of some inconsistency where JRS introduces some magic that we don't know about So canDisplay() needs to be fixed to be consistent and perhaps we also need to see if we are always getting the glyphs from the same fonts for the cases where there is no missing glyph. I do agree that getting away from JRS* support is the way to go so we are in control. However not at this time in JDK 9. Yes "." fonts are not enumerated by OS X but if you can find them they work. This is how the UI fonts are handled. Yes, we are aware this fixed it only for Oracle JDK. The bit I missed is that GeezaProInterface was then used on OpenJDK by JRS. So we could add that as well. If you have any other fonts you think should be added to the tail of that list we can add them too. -phil. On 02/10/2017 07:59 AM, Dmitry Batrak wrote: > Hi, > > I've tried to build OpenJDK from 'client' repository with the fix, and the > issue is still reproducible for me. Are you fixing it only for Oracle JDK > (including Lucida Sans Regular font), and not for OpenJDK? The problem > is not > that some character cannot be rendered using a particular font, it's that > rendering behaviour doesn't match what 'canDisplay' returns. > > If you're interested I can share the way we've fixed this issue in our > OpenJDK-based runtime. > > As you've mentioned, the problem is that > JRSFontCreateFallbackFontForCharacters returns fallback font, which is > not on > the cascaded font list, and it can be absent even in the whole list of > fonts > reported by the system. On my machine, with OpenJDK, it's > .GeezaProInterface > (with name starting with dot). I guess such fonts are treated by macOS as > 'hidden' (just like files with names starting with dots), still they > seem to be > usable from application if requested by their name. > > As JRSFontCreateFallbackFontForCharacters is a 'black box', it's hard > to make > sure cascade list we're building matches its internal logic, so we've > chosen to > build the list dynamically based on the output of > JRSFontCreateFallbackFontForCharacters itself. I can try to prepare > corresponding webrev, if you think that can be useful. > > Alternative solution (and, probably, a better one strategically), > would be not > using JRSFontCreateFallbackFontForCharacters at all. The cascade list, > that is > built currently, can probably be used to perform font fallback in all > cases. > > Best regards, > Dmitry Batrak > > > > Hi All, > > > > Please review a fix for an issue which causes arabic character "alef" to > > be not rendered in osx for menlo font in italic style. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 > > > > The issue was actually a regression caused by the fix to JDK-7162125: > > [macosx] A font has different behaviour for ligatures depending on its > > creation mode > > in which we have added cascaded font list to find the real fonts that > > CFont uses, so that there is no need to use "negative" glyph code for > > finding the fallback fonts > > using the "subsititution"/"fallback" mechanism used by osx code. > > > > However, the above logic of using cascaded font list in CFont does not > > take into account of using JRE provided fonts like all those Lucida* ttf > > in jdk/lib/fonts/, so > > when a glyph (in this intance, arabic 'alef' character) is intended to > > be rendered in Menlo font in italic style, osx will not be able to find > > the glyph in Menlo-Italic font > > and neither in all the cascaded system fonts provided by CoreText, so it > > results in empty box. > > > > Before 7162125 fix, the fallback code in > > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses > > JRSFontCreateFallbackFontForCharacters() > > was adding jre/lib/fonts to the fallback list which was causing the > > glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was > > rendered. > > > > So, the proposed fix is to add jre provided font "Lucida Sans Regular" > > to the cascaded list so that we get the "alef" glyph. > > The reason for choosing "Lucida Sans Regular" over "Lucida Bright > > Regular" is, because it is the largest font file in jre and has all the > > glyph codepoints that no other font in the jre has, > > so we will not lose out on any codepoints and will help us in not > > getting missing glyph. > > > > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ > > > > > Regards > > Prasanta > From philip.race at oracle.com Fri Feb 10 18:02:04 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 10 Feb 2017 10:02:04 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8170913: Java "1.8.0_112" on Windows 10 displays different characters for EUDCs from ones created in eudcedit.exe. Message-ID: https://bugs.openjdk.java.net/browse/JDK-8170913 http://cr.openjdk.java.net/~prr/8170913/ The EUDC font is now placed first in the list of fall backs, since anyone who has a EUDC font presumably wants the code points from there more than any other fallbacks that map PUA code points. No reg. test as it requires system configuration. -phil From philip.race at oracle.com Fri Feb 10 23:44:29 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 10 Feb 2017 15:44:29 -0800 Subject: [OpenJDK 2D-Dev] Reporting new bugs (with Author role) In-Reply-To: References: Message-ID: <84a6e04f-2859-1c23-581d-115e4e4f7322@oracle.com> The author role entitles you to file bugs directly .. -phil. On 02/10/2017 01:13 AM, Dmitry Batrak wrote: > Hello again, > > Now that I have an OpenJDK account, it seems like I can create new > tickets directly in OpenJDK JIRA instance > (https://bugs.openjdk.java.net/). Should I use this way, or should I > continue to use http://bugreport.java.com/ to report new bugs? I'm > mostly speaking about bugs for which I'm ready to propose a fix myself. > > Best regards, > Dmitry Batrak From philip.race at oracle.com Fri Feb 10 23:48:51 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 10 Feb 2017 15:48:51 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8170552: [macosx] Wrong rendering of diacritics on macOS In-Reply-To: References: Message-ID: <2fc97682-6a0b-5f3e-c6db-e79abbeebcad@oracle.com> Looks good to me. It used to be a pain keeping several places in sync, hence the single util function. I guess that pre-dated the Apple code and we didn't realise it had its own copy .. So much code ... so little time ... -phil. On 02/10/2017 01:07 AM, Dmitry Batrak wrote: > Hello, > > I'd like to propose a fix for JDK-8170552. > bug: https://bugs.openjdk.java.net/browse/JDK-8170552 > webrev: http://cr.openjdk.java.net/~dbatrak/8170552/webrev.00/ > > > I don't have a Committer status, so I'll require a sponsor. > > I've proposed this patch earlier via support ticket (it's also > attached to JIRA > issue). It brings the code used to detect complex text when working > with system > fonts on macOS on par with similar code used for other fonts and > platforms. > > As compared to the previously provided patch, I've also added a test > case. It > depends on specifics of the font being used (Menlo), but I couldn't > think of > another way to create an automated test for this issue. > > Best regards, > Dmitry Batrak From dmitry.markov at oracle.com Sat Feb 11 13:15:31 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Sat, 11 Feb 2017 16:15:31 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170552: [macosx] Wrong rendering of diacritics on macOS In-Reply-To: <2fc97682-6a0b-5f3e-c6db-e79abbeebcad@oracle.com> References: <2fc97682-6a0b-5f3e-c6db-e79abbeebcad@oracle.com> Message-ID: <589F0E73.9090603@oracle.com> Hi Dmitry, The fix looks good to me too, but I am not a reviewer. So you need one more +1 from someone else with reviewer status. I will sponsor integration of the fix once it is finally approved. Thanks, Dmitry On 11/02/2017 02:48, Phil Race wrote: > Looks good to me. > It used to be a pain keeping several places in sync, hence the single > util function. > I guess that pre-dated the Apple code and we didn't realise it had its > own copy .. > So much code ... so little time ... > > -phil. > > On 02/10/2017 01:07 AM, Dmitry Batrak wrote: >> Hello, >> >> I'd like to propose a fix for JDK-8170552. >> bug: https://bugs.openjdk.java.net/browse/JDK-8170552 >> webrev: http://cr.openjdk.java.net/~dbatrak/8170552/webrev.00/ >> >> >> I don't have a Committer status, so I'll require a sponsor. >> >> I've proposed this patch earlier via support ticket (it's also >> attached to JIRA >> issue). It brings the code used to detect complex text when working >> with system >> fonts on macOS on par with similar code used for other fonts and >> platforms. >> >> As compared to the previously provided patch, I've also added a test >> case. It >> depends on specifics of the font being used (Menlo), but I couldn't >> think of >> another way to create an automated test for this issue. >> >> Best regards, >> Dmitry Batrak > From vadim.pakhnushev at oracle.com Sat Feb 11 16:17:43 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sat, 11 Feb 2017 19:17:43 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170913: Java "1.8.0_112" on Windows 10 displays different characters for EUDCs from ones created in eudcedit.exe. In-Reply-To: References: Message-ID: <6f4e3bed-6703-8311-3a79-415f9b32f8e9@oracle.com> Looks good. Vadim On 10.02.2017 21:02, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8170913 > http://cr.openjdk.java.net/~prr/8170913/ > > The EUDC font is now placed first in the list of fall backs, since > anyone who > has a EUDC font presumably wants the code points from there more than > any other fallbacks that map PUA code points. > > No reg. test as it requires system configuration. > > -phil > From dmitry.batrak at jetbrains.com Mon Feb 13 07:47:26 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Mon, 13 Feb 2017 10:47:26 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder In-Reply-To: <589A678E.7050607@oracle.com> References: <588F3344.90008@oracle.com> <589A678E.7050607@oracle.com> Message-ID: Could anyone else review this please? Best regards, Dmitry Batrak On Wed, Feb 8, 2017 at 3:34 AM, Philip Race 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 >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batrak at jetbrains.com Mon Feb 13 09:56:09 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Mon, 13 Feb 2017 12:56:09 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: References: Message-ID: > Yes, we are aware this fixed it only for Oracle JDK. > The bit I missed is that GeezaProInterface was then used on OpenJDK by JRS. > So we could add that as well. > If you have any other fonts you think should be added to the tail of that list we > can add them too. I ran JRSFontCreateFallbackFontForCharacters against all Unicode code points with Menlo-Italic as base font, and got 63 possible fallback fonts - vs 29 present in cascade list, currently used by JDK 9 (given in JDK-8147002). So the mismatch is quite large. But the interesting thing is that cascade list returned by CTFontCopyDefaultCascadeListForLanguages still covers that whole Unicode range. The problem is that JDK doesn't use that list fully. In particular, Arabic alef letter U+0627 can be displayed using the font .NotoSansUniversal from that list. This font doesn't get into composite font, as it's not found among the fonts known to Java. So a better fix (and still quite small) will probably be using those 'hidden' fonts as part of cascade composites - by creating a new, 'local' CFont instance if lookup in the known font list fails (this, btw, seems to work fine for us). If even this is considered risky for JDK 9, then probably adding .NotoSansUniversal with or instead of .GeezaProInterface as a hardcoded component makes sense. Best regards, Dmitry Batrak On Fri, Feb 10, 2017 at 8:19 PM, Phil Race wrote: > I think that so long as we are using JRS* in some places and CoreText's > cascading list > in others there is the likelihood of some inconsistency where JRS > introduces some magic > that we don't know about > > So canDisplay() needs to be fixed to be consistent and perhaps we also > need to see > if we are always getting the glyphs from the same fonts for the cases > where there > is no missing glyph. > > I do agree that getting away from JRS* support is the way to go so we are > in control. > However not at this time in JDK 9. > > Yes "." fonts are not enumerated by OS X but if you can find them they > work. > This is how the UI fonts are handled. > > Yes, we are aware this fixed it only for Oracle JDK. > The bit I missed is that GeezaProInterface was then used on OpenJDK by JRS. > So we could add that as well. > If you have any other fonts you think should be added to the tail of that > list we > can add them too. > > -phil. > > On 02/10/2017 07:59 AM, Dmitry Batrak wrote: > >> Hi, >> >> I've tried to build OpenJDK from 'client' repository with the fix, and the >> issue is still reproducible for me. Are you fixing it only for Oracle JDK >> (including Lucida Sans Regular font), and not for OpenJDK? The problem is >> not >> that some character cannot be rendered using a particular font, it's that >> rendering behaviour doesn't match what 'canDisplay' returns. >> >> If you're interested I can share the way we've fixed this issue in our >> OpenJDK-based runtime. >> >> As you've mentioned, the problem is that >> JRSFontCreateFallbackFontForCharacters returns fallback font, which is >> not on >> the cascaded font list, and it can be absent even in the whole list of >> fonts >> reported by the system. On my machine, with OpenJDK, it's >> .GeezaProInterface >> (with name starting with dot). I guess such fonts are treated by macOS as >> 'hidden' (just like files with names starting with dots), still they seem >> to be >> usable from application if requested by their name. >> >> As JRSFontCreateFallbackFontForCharacters is a 'black box', it's hard to >> make >> sure cascade list we're building matches its internal logic, so we've >> chosen to >> build the list dynamically based on the output of >> JRSFontCreateFallbackFontForCharacters itself. I can try to prepare >> corresponding webrev, if you think that can be useful. >> >> Alternative solution (and, probably, a better one strategically), would >> be not >> using JRSFontCreateFallbackFontForCharacters at all. The cascade list, >> that is >> built currently, can probably be used to perform font fallback in all >> cases. >> >> Best regards, >> Dmitry Batrak >> >> >> > Hi All, >> > >> > Please review a fix for an issue which causes arabic character "alef" to >> > be not rendered in osx for menlo font in italic style. >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 >> > >> > The issue was actually a regression caused by the fix to JDK-7162125: >> > [macosx] A font has different behaviour for ligatures depending on its >> > creation mode >> > in which we have added cascaded font list to find the real fonts that >> > CFont uses, so that there is no need to use "negative" glyph code for >> > finding the fallback fonts >> > using the "subsititution"/"fallback" mechanism used by osx code. >> > >> > However, the above logic of using cascaded font list in CFont does not >> > take into account of using JRE provided fonts like all those Lucida* ttf >> > in jdk/lib/fonts/, so >> > when a glyph (in this intance, arabic 'alef' character) is intended to >> > be rendered in Menlo font in italic style, osx will not be able to find >> > the glyph in Menlo-Italic font >> > and neither in all the cascaded system fonts provided by CoreText, so it >> > results in empty box. >> > >> > Before 7162125 fix, the fallback code in >> > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses >> > JRSFontCreateFallbackFontForCharacters() >> > was adding jre/lib/fonts to the fallback list which was causing the >> > glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was >> > rendered. >> > >> > So, the proposed fix is to add jre provided font "Lucida Sans Regular" >> > to the cascaded list so that we get the "alef" glyph. >> > The reason for choosing "Lucida Sans Regular" over "Lucida Bright >> > Regular" is, because it is the largest font file in jre and has all the >> > glyph codepoints that no other font in the jre has, >> > so we will not lose out on any codepoints and will help us in not >> > getting missing glyph. >> > >> > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ < >> http://cr.openjdk.java.net/%7Epsadhukhan/8147002/webrev.00/> >> > >> > Regards >> > Prasanta >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Feb 13 11:13:59 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 13 Feb 2017 16:43:59 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8170913: Java "1.8.0_112" on Windows 10 displays different characters for EUDCs from ones created in eudcedit.exe. In-Reply-To: <6f4e3bed-6703-8311-3a79-415f9b32f8e9@oracle.com> References: <6f4e3bed-6703-8311-3a79-415f9b32f8e9@oracle.com> Message-ID: <08129d61-cd59-e3ca-d628-7c6bd60c30f3@oracle.com> Looks good to me. Regards Prasanta > Looks good. > > On 10.02.2017 21:02, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8170913 >> http://cr.openjdk.java.net/~prr/8170913/ >> >> The EUDC font is now placed first in the list of fall backs, since >> anyone who >> has a EUDC font presumably wants the code points from there more than >> any other fallbacks that map PUA code points. >> >> No reg. test as it requires system configuration. >> >> -phil >> > From philip.race at oracle.com Mon Feb 13 17:37:13 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 13 Feb 2017 09:37:13 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8173028: Incorrect processing of supplementary-plane characters in text fields Message-ID: <7b18301d-0815-38a7-f401-65db7dd9cd69@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8173028 http://cr.openjdk.java.net/~prr/8173028/ An off by-one bug in assigning remaining glyphs in the cluster to char indices so that the zero advance gets assigned to latin "a" and it is not a hit anymore. font/layout/swing text regression tests have been run. -phil. From sergey.bylokhov at oracle.com Mon Feb 13 17:52:40 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Feb 2017 20:52:40 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8173028: Incorrect processing of supplementary-plane characters in text fields In-Reply-To: <7b18301d-0815-38a7-f401-65db7dd9cd69@oracle.com> References: <7b18301d-0815-38a7-f401-65db7dd9cd69@oracle.com> Message-ID: <24F8F125-9405-41C4-9130-91728140B78C@oracle.com> Looks fine, but I?am not an expert in this area. > > https://bugs.openjdk.java.net/browse/JDK-8173028 > http://cr.openjdk.java.net/~prr/8173028/ > > An off by-one bug in assigning remaining glyphs in the cluster to char indices > so that the zero advance gets assigned to latin "a" and it is not a hit anymore. > > font/layout/swing text regression tests have been run. > > -phil. From vadim.pakhnushev at oracle.com Mon Feb 13 19:28:14 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 13 Feb 2017 22:28:14 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8173028: Incorrect processing of supplementary-plane characters in text fields In-Reply-To: <24F8F125-9405-41C4-9130-91728140B78C@oracle.com> References: <7b18301d-0815-38a7-f401-65db7dd9cd69@oracle.com> <24F8F125-9405-41C4-9130-91728140B78C@oracle.com> Message-ID: <3fdd37d8-e9af-1341-ac78-5a2e41910889@oracle.com> +1 Vadim On 13/02/2017 20:52, Sergey Bylokhov wrote: > Looks fine, but I?am not an expert in this area. > >> https://bugs.openjdk.java.net/browse/JDK-8173028 >> http://cr.openjdk.java.net/~prr/8173028/ >> >> An off by-one bug in assigning remaining glyphs in the cluster to char indices >> so that the zero advance gets assigned to latin "a" and it is not a hit anymore. >> >> font/layout/swing text regression tests have been run. >> >> -phil. From sergey.bylokhov at oracle.com Mon Feb 13 19:30:12 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Feb 2017 22:30:12 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder In-Reply-To: References: <588F3344.90008@oracle.com> <589A678E.7050607@oracle.com> Message-ID: <8899C22A-DB58-4484-B83D-125D2D2169C2@oracle.com> > 13 ????. 2017 ?., ? 10:47, Dmitry Batrak ???????(?): > > Could anyone else review this please? +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Mon Feb 13 21:17:52 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Tue, 14 Feb 2017 00:17:52 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder In-Reply-To: References: Message-ID: <58A22280.5090906@oracle.com> The fix was integrated into jdk9-client. Changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/7ba90377c7f4 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/ > > > 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 From vadim.pakhnushev at oracle.com Tue Feb 14 19:44:25 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 14 Feb 2017 22:44:25 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170552: [macosx] Wrong rendering of diacritics on macOS In-Reply-To: <589F0E73.9090603@oracle.com> References: <2fc97682-6a0b-5f3e-c6db-e79abbeebcad@oracle.com> <589F0E73.9090603@oracle.com> Message-ID: +1 Vadim On 11/02/2017 16:15, dmitry markov wrote: > Hi Dmitry, > > The fix looks good to me too, but I am not a reviewer. So you need > one more +1 from someone else with reviewer status. > I will sponsor integration of the fix once it is finally approved. > > Thanks, > Dmitry > On 11/02/2017 02:48, Phil Race wrote: >> Looks good to me. >> It used to be a pain keeping several places in sync, hence the single >> util function. >> I guess that pre-dated the Apple code and we didn't realise it had >> its own copy .. >> So much code ... so little time ... >> >> -phil. >> >> On 02/10/2017 01:07 AM, Dmitry Batrak wrote: >>> Hello, >>> >>> I'd like to propose a fix for JDK-8170552. >>> bug: https://bugs.openjdk.java.net/browse/JDK-8170552 >>> webrev: http://cr.openjdk.java.net/~dbatrak/8170552/webrev.00/ >>> >>> >>> I don't have a Committer status, so I'll require a sponsor. >>> >>> I've proposed this patch earlier via support ticket (it's also >>> attached to JIRA >>> issue). It brings the code used to detect complex text when working >>> with system >>> fonts on macOS on par with similar code used for other fonts and >>> platforms. >>> >>> As compared to the previously provided patch, I've also added a test >>> case. It >>> depends on specifics of the font being used (Menlo), but I couldn't >>> think of >>> another way to create an automated test for this issue. >>> >>> Best regards, >>> Dmitry Batrak >> > From sergey.bylokhov at oracle.com Wed Feb 15 12:47:23 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 15 Feb 2017 15:47:23 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170552: [macosx] Wrong rendering of diacritics on macOS In-Reply-To: References: <2fc97682-6a0b-5f3e-c6db-e79abbeebcad@oracle.com> <589F0E73.9090603@oracle.com> Message-ID: <2C713AD0-62D8-4238-AEF3-022EACC319F7@oracle.com> I am not sure, but Is the apache license in the test can be accepted in the openjdk? I had an impression that all code should by under GPL v2 or GPL v2 + the Classpath exception. > > > +1 > > Vadim > > On 11/02/2017 16:15, dmitry markov wrote: >> Hi Dmitry, >> >> The fix looks good to me too, but I am not a reviewer. So you need one more +1 from someone else with reviewer status. >> I will sponsor integration of the fix once it is finally approved. >> >> Thanks, >> Dmitry >> On 11/02/2017 02:48, Phil Race wrote: >>> Looks good to me. >>> It used to be a pain keeping several places in sync, hence the single util function. >>> I guess that pre-dated the Apple code and we didn't realise it had its own copy .. >>> So much code ... so little time ... >>> >>> -phil. >>> >>> On 02/10/2017 01:07 AM, Dmitry Batrak wrote: >>>> Hello, >>>> >>>> I'd like to propose a fix for JDK-8170552. >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170552 >>>> webrev: http://cr.openjdk.java.net/~dbatrak/8170552/webrev.00/ >>>> >>>> I don't have a Committer status, so I'll require a sponsor. >>>> >>>> I've proposed this patch earlier via support ticket (it's also attached to JIRA >>>> issue). It brings the code used to detect complex text when working with system >>>> fonts on macOS on par with similar code used for other fonts and platforms. >>>> >>>> As compared to the previously provided patch, I've also added a test case. It >>>> depends on specifics of the font being used (Menlo), but I couldn't think of >>>> another way to create an automated test for this issue. >>>> >>>> Best regards, >>>> Dmitry Batrak >>> >> > From philip.race at oracle.com Wed Feb 15 15:36:14 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Feb 2017 07:36:14 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8170552: [macosx] Wrong rendering of diacritics on macOS In-Reply-To: <2C713AD0-62D8-4238-AEF3-022EACC319F7@oracle.com> References: <2fc97682-6a0b-5f3e-c6db-e79abbeebcad@oracle.com> <589F0E73.9090603@oracle.com> <2C713AD0-62D8-4238-AEF3-022EACC319F7@oracle.com> Message-ID: <58A4756E.90605@oracle.com> You are right ! I missed that. OpenJDK rules rquire it be contributed under GPL v2 (not classpath) The test needs to be updated or deleted ASAP (today would be good). -phil. On 2/15/17, 4:47 AM, Sergey Bylokhov wrote: > I am not sure, but Is the apache license in the test can be accepted in the openjdk? I had an impression that all code should by under GPL v2 or GPL v2 + the Classpath exception. > >> >> +1 >> >> Vadim >> >> On 11/02/2017 16:15, dmitry markov wrote: >>> Hi Dmitry, >>> >>> The fix looks good to me too, but I am not a reviewer. So you need one more +1 from someone else with reviewer status. >>> I will sponsor integration of the fix once it is finally approved. >>> >>> Thanks, >>> Dmitry >>> On 11/02/2017 02:48, Phil Race wrote: >>>> Looks good to me. >>>> It used to be a pain keeping several places in sync, hence the single util function. >>>> I guess that pre-dated the Apple code and we didn't realise it had its own copy .. >>>> So much code ... so little time ... >>>> >>>> -phil. >>>> >>>> On 02/10/2017 01:07 AM, Dmitry Batrak wrote: >>>>> Hello, >>>>> >>>>> I'd like to propose a fix for JDK-8170552. >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170552 >>>>> webrev: http://cr.openjdk.java.net/~dbatrak/8170552/webrev.00/ >>>>> >>>>> I don't have a Committer status, so I'll require a sponsor. >>>>> >>>>> I've proposed this patch earlier via support ticket (it's also attached to JIRA >>>>> issue). It brings the code used to detect complex text when working with system >>>>> fonts on macOS on par with similar code used for other fonts and platforms. >>>>> >>>>> As compared to the previously provided patch, I've also added a test case. It >>>>> depends on specifics of the font being used (Menlo), but I couldn't think of >>>>> another way to create an automated test for this issue. >>>>> >>>>> Best regards, >>>>> Dmitry Batrak From dmitry.markov at oracle.com Wed Feb 15 15:45:14 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Wed, 15 Feb 2017 18:45:14 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170552: [macosx] Wrong rendering of diacritics on macOS In-Reply-To: <58A4756E.90605@oracle.com> References: <2fc97682-6a0b-5f3e-c6db-e79abbeebcad@oracle.com> <589F0E73.9090603@oracle.com> <2C713AD0-62D8-4238-AEF3-022EACC319F7@oracle.com> <58A4756E.90605@oracle.com> Message-ID: <58A4778A.3050905@oracle.com> I have opened JDK-8175025 for that. Will send review soon. Thanks, Dmitry On 15/02/2017 18:36, Philip Race wrote: > You are right ! > I missed that. OpenJDK rules rquire it be contributed under GPL v2 > (not classpath) > The test needs to be updated or deleted ASAP (today would be good). > > -phil. > > On 2/15/17, 4:47 AM, Sergey Bylokhov wrote: >> I am not sure, but Is the apache license in the test can be accepted >> in the openjdk? I had an impression that all code should by under GPL >> v2 or GPL v2 + the Classpath exception. >> >>> >>> +1 >>> >>> Vadim >>> >>> On 11/02/2017 16:15, dmitry markov wrote: >>>> Hi Dmitry, >>>> >>>> The fix looks good to me too, but I am not a reviewer. So you need >>>> one more +1 from someone else with reviewer status. >>>> I will sponsor integration of the fix once it is finally approved. >>>> >>>> Thanks, >>>> Dmitry >>>> On 11/02/2017 02:48, Phil Race wrote: >>>>> Looks good to me. >>>>> It used to be a pain keeping several places in sync, hence the >>>>> single util function. >>>>> I guess that pre-dated the Apple code and we didn't realise it had >>>>> its own copy .. >>>>> So much code ... so little time ... >>>>> >>>>> -phil. >>>>> >>>>> On 02/10/2017 01:07 AM, Dmitry Batrak wrote: >>>>>> Hello, >>>>>> >>>>>> I'd like to propose a fix for JDK-8170552. >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170552 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~dbatrak/8170552/webrev.00/ >>>>>> >>>>>> I don't have a Committer status, so I'll require a sponsor. >>>>>> >>>>>> I've proposed this patch earlier via support ticket (it's also >>>>>> attached to JIRA >>>>>> issue). It brings the code used to detect complex text when >>>>>> working with system >>>>>> fonts on macOS on par with similar code used for other fonts and >>>>>> platforms. >>>>>> >>>>>> As compared to the previously provided patch, I've also added a >>>>>> test case. It >>>>>> depends on specifics of the font being used (Menlo), but I >>>>>> couldn't think of >>>>>> another way to create an automated test for this issue. >>>>>> >>>>>> Best regards, >>>>>> Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Wed Feb 15 16:15:35 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 15 Feb 2017 19:15:35 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8175025: The copyright section in the test/java/awt/font/TextLayout/DiacriticsDrawingTest.java should be updated Message-ID: Hello, Could you review a simple fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8175025 webrev: http://cr.openjdk.java.net/~dmarkov/8175025/webrev.00/ Changed the license in the test to GPL v2. Thanks, Dmitry From philip.race at oracle.com Wed Feb 15 17:10:12 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 15 Feb 2017 09:10:12 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: References: Message-ID: <5d0f21c0-8828-35d8-41f4-8bed4656c994@oracle.com> Hi, I don't know what versions of MacOS X either of you (Dmitry+Prasanta) used but I am going to guess they are different (can you both report these, for the record). In https://bugs.openjdk.java.net/browse/JDK-8147002, Prasanta enumerates the cascade list for the Italic case and I don't see .NotoSansUniversal anywhere on that list. So although if enumerated it likely still won't work (since it is not enumerated by the other APIs), there does not appear to be any font in the cascade list reported by Prasanta that "would not work", so the fix still seems fine to me as it is plugging a gap. A fix for using "hidden" fonts in the cascade list seems like a JDK 10 candidate unless there is some critical case we are still missing. -phil. On 02/13/2017 01:56 AM, Dmitry Batrak wrote: > > Yes, we are aware this fixed it only for Oracle JDK. > > The bit I missed is that GeezaProInterface was then used on OpenJDK by JRS. > > So we could add that as well. > > If you have any other fonts you think should be added to the tail of that list we > > can add them too. > > I ran JRSFontCreateFallbackFontForCharacters against all Unicode code > points with Menlo-Italic as base font, > and got 63 possible fallback fonts - vs 29 present in cascade list, > currently used by JDK 9 (given in JDK-8147002). > So the mismatch is quite large. But the interesting thing is that > cascade list returned by > CTFontCopyDefaultCascadeListForLanguages still covers that whole > Unicode range. The problem is that JDK > doesn't use that list fully. In particular, Arabic alef letter U+0627 > can be displayed using the font > .NotoSansUniversal from that list. This font doesn't get into > composite font, as it's not found among the fonts > known to Java. So a better fix (and still quite small) will probably > be using those 'hidden' fonts as part of > cascade composites - by creating a new, 'local' CFont instance if > lookup in the known font list fails > (this, btw, seems to work fine for us). If even this is considered > risky for JDK 9, then probably adding > .NotoSansUniversal with or instead of .GeezaProInterface as a > hardcoded component makes sense. > Best regards, > Dmitry Batrak > > On Fri, Feb 10, 2017 at 8:19 PM, Phil Race > wrote: > > I think that so long as we are using JRS* in some places and > CoreText's cascading list > in others there is the likelihood of some inconsistency where JRS > introduces some magic > that we don't know about > > So canDisplay() needs to be fixed to be consistent and perhaps we > also need to see > if we are always getting the glyphs from the same fonts for the > cases where there > is no missing glyph. > > I do agree that getting away from JRS* support is the way to go so > we are in control. > However not at this time in JDK 9. > > Yes "." fonts are not enumerated by OS X but if you can find them > they work. > This is how the UI fonts are handled. > > Yes, we are aware this fixed it only for Oracle JDK. > The bit I missed is that GeezaProInterface was then used on > OpenJDK by JRS. > So we could add that as well. > If you have any other fonts you think should be added to the tail > of that list we > can add them too. > > -phil. > > On 02/10/2017 07:59 AM, Dmitry Batrak wrote: > > Hi, > > I've tried to build OpenJDK from 'client' repository with the > fix, and the > issue is still reproducible for me. Are you fixing it only for > Oracle JDK > (including Lucida Sans Regular font), and not for OpenJDK? The > problem is not > that some character cannot be rendered using a particular > font, it's that > rendering behaviour doesn't match what 'canDisplay' returns. > > If you're interested I can share the way we've fixed this > issue in our > OpenJDK-based runtime. > > As you've mentioned, the problem is that > JRSFontCreateFallbackFontForCharacters returns fallback font, > which is not on > the cascaded font list, and it can be absent even in the whole > list of fonts > reported by the system. On my machine, with OpenJDK, it's > .GeezaProInterface > (with name starting with dot). I guess such fonts are treated > by macOS as > 'hidden' (just like files with names starting with dots), > still they seem to be > usable from application if requested by their name. > > As JRSFontCreateFallbackFontForCharacters is a 'black box', > it's hard to make > sure cascade list we're building matches its internal logic, > so we've chosen to > build the list dynamically based on the output of > JRSFontCreateFallbackFontForCharacters itself. I can try to > prepare > corresponding webrev, if you think that can be useful. > > Alternative solution (and, probably, a better one > strategically), would be not > using JRSFontCreateFallbackFontForCharacters at all. The > cascade list, that is > built currently, can probably be used to perform font fallback > in all cases. > > Best regards, > Dmitry Batrak > > > > Hi All, > > > > Please review a fix for an issue which causes arabic > character "alef" to > > be not rendered in osx for menlo font in italic style. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 > > > > > The issue was actually a regression caused by the fix to > JDK-7162125: > > [macosx] A font has different behaviour for ligatures > depending on its > > creation mode > > in which we have added cascaded font list to find the real > fonts that > > CFont uses, so that there is no need to use "negative" glyph > code for > > finding the fallback fonts > > using the "subsititution"/"fallback" mechanism used by osx code. > > > > However, the above logic of using cascaded font list in > CFont does not > > take into account of using JRE provided fonts like all those > Lucida* ttf > > in jdk/lib/fonts/, so > > when a glyph (in this intance, arabic 'alef' character) is > intended to > > be rendered in Menlo font in italic style, osx will not be > able to find > > the glyph in Menlo-Italic font > > and neither in all the cascaded system fonts provided by > CoreText, so it > > results in empty box. > > > > Before 7162125 fix, the fallback code in > > > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() > uses > > JRSFontCreateFallbackFontForCharacters() > > was adding jre/lib/fonts to the fallback list which was > causing the > > glyph to be found in "LucidaBrightRegular.ttf" font and the > glyph was > > rendered. > > > > So, the proposed fix is to add jre provided font "Lucida > Sans Regular" > > to the cascaded list so that we get the "alef" glyph. > > The reason for choosing "Lucida Sans Regular" over "Lucida > Bright > > Regular" is, because it is the largest font file in jre and > has all the > > glyph codepoints that no other font in the jre has, > > so we will not lose out on any codepoints and will help us > in not > > getting missing glyph. > > > > webrev: > http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ > > > > > > > Regards > > Prasanta > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Feb 16 05:33:24 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 16 Feb 2017 11:03:24 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: <5d0f21c0-8828-35d8-41f4-8bed4656c994@oracle.com> References: <5d0f21c0-8828-35d8-41f4-8bed4656c994@oracle.com> Message-ID: <25b11d07-c01c-1bff-069d-8515ac49d2bc@oracle.com> Hi Phil, I was using osx10.11 but the list I enumerated in JBS is actually the composite font I get in CCompositeGlyphMapper#convertToGlyph() which contains those 29 slots [CCompositeGlyphMapper#convertToGlyph(unicode=value 1575) gets the glyph code(909) from slot[4] which is CourierNewPSMT, for italic the list was taken from convertToGlyph()] But, if we are considering the cascade list "listOfString", it contains .NotoSansUniversal just before AppleColorEmoji. However, it does not get added to CompositeFont list because findFont2D() returned null for it. There was another hidden font in the cascade list ".AppleSymbolsFB" but it was changed to "AppleSymbols" and that along with other fonts findFont2D() was able to find and could add to CompositeFont list for convertGlyph() to use. Regards Prasanta On 2/15/2017 10:40 PM, Phil Race wrote: > Hi, > I don't know what versions of MacOS X either of you (Dmitry+Prasanta) > used but I am going to guess they are different > (can you both report these, for the record). > > In https://bugs.openjdk.java.net/browse/JDK-8147002, Prasanta enumerates > the cascade list for the Italic case and I don't see > .NotoSansUniversal anywhere on that list. > > So although if enumerated it likely still won't work (since it is not > enumerated by the other APIs), > there does not appear to be any font in the cascade list reported by > Prasanta that "would not work", > so the fix still seems fine to me as it is plugging a gap. > > A fix for using "hidden" fonts in the cascade list seems like a JDK 10 > candidate unless there > is some critical case we are still missing. > > -phil. > > > > On 02/13/2017 01:56 AM, Dmitry Batrak wrote: >> > Yes, we are aware this fixed it only for Oracle JDK. >> > The bit I missed is that GeezaProInterface was then used on OpenJDK by JRS. >> > So we could add that as well. >> > If you have any other fonts you think should be added to the tail of that list we >> > can add them too. >> >> I ran JRSFontCreateFallbackFontForCharacters against all Unicode code >> points with Menlo-Italic as base font, >> and got 63 possible fallback fonts - vs 29 present in cascade list, >> currently used by JDK 9 (given in JDK-8147002). >> So the mismatch is quite large. But the interesting thing is that >> cascade list returned by >> CTFontCopyDefaultCascadeListForLanguages still covers that whole >> Unicode range. The problem is that JDK >> doesn't use that list fully. In particular, Arabic alef letter U+0627 >> can be displayed using the font >> .NotoSansUniversal from that list. This font doesn't get into >> composite font, as it's not found among the fonts >> known to Java. So a better fix (and still quite small) will probably >> be using those 'hidden' fonts as part of >> cascade composites - by creating a new, 'local' CFont instance if >> lookup in the known font list fails >> (this, btw, seems to work fine for us). If even this is considered >> risky for JDK 9, then probably adding >> .NotoSansUniversal with or instead of .GeezaProInterface as a >> hardcoded component makes sense. >> Best regards, >> Dmitry Batrak >> >> On Fri, Feb 10, 2017 at 8:19 PM, Phil Race > > wrote: >> >> I think that so long as we are using JRS* in some places and >> CoreText's cascading list >> in others there is the likelihood of some inconsistency where JRS >> introduces some magic >> that we don't know about >> >> So canDisplay() needs to be fixed to be consistent and perhaps we >> also need to see >> if we are always getting the glyphs from the same fonts for the >> cases where there >> is no missing glyph. >> >> I do agree that getting away from JRS* support is the way to go >> so we are in control. >> However not at this time in JDK 9. >> >> Yes "." fonts are not enumerated by OS X but if you can find them >> they work. >> This is how the UI fonts are handled. >> >> Yes, we are aware this fixed it only for Oracle JDK. >> The bit I missed is that GeezaProInterface was then used on >> OpenJDK by JRS. >> So we could add that as well. >> If you have any other fonts you think should be added to the tail >> of that list we >> can add them too. >> >> -phil. >> >> On 02/10/2017 07:59 AM, Dmitry Batrak wrote: >> >> Hi, >> >> I've tried to build OpenJDK from 'client' repository with the >> fix, and the >> issue is still reproducible for me. Are you fixing it only >> for Oracle JDK >> (including Lucida Sans Regular font), and not for OpenJDK? >> The problem is not >> that some character cannot be rendered using a particular >> font, it's that >> rendering behaviour doesn't match what 'canDisplay' returns. >> >> If you're interested I can share the way we've fixed this >> issue in our >> OpenJDK-based runtime. >> >> As you've mentioned, the problem is that >> JRSFontCreateFallbackFontForCharacters returns fallback font, >> which is not on >> the cascaded font list, and it can be absent even in the >> whole list of fonts >> reported by the system. On my machine, with OpenJDK, it's >> .GeezaProInterface >> (with name starting with dot). I guess such fonts are treated >> by macOS as >> 'hidden' (just like files with names starting with dots), >> still they seem to be >> usable from application if requested by their name. >> >> As JRSFontCreateFallbackFontForCharacters is a 'black box', >> it's hard to make >> sure cascade list we're building matches its internal logic, >> so we've chosen to >> build the list dynamically based on the output of >> JRSFontCreateFallbackFontForCharacters itself. I can try to >> prepare >> corresponding webrev, if you think that can be useful. >> >> Alternative solution (and, probably, a better one >> strategically), would be not >> using JRSFontCreateFallbackFontForCharacters at all. The >> cascade list, that is >> built currently, can probably be used to perform font >> fallback in all cases. >> >> Best regards, >> Dmitry Batrak >> >> >> > Hi All, >> > >> > Please review a fix for an issue which causes arabic >> character "alef" to >> > be not rendered in osx for menlo font in italic style. >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 >> >> > >> > The issue was actually a regression caused by the fix to >> JDK-7162125: >> > [macosx] A font has different behaviour for ligatures >> depending on its >> > creation mode >> > in which we have added cascaded font list to find the real >> fonts that >> > CFont uses, so that there is no need to use "negative" >> glyph code for >> > finding the fallback fonts >> > using the "subsititution"/"fallback" mechanism used by osx >> code. >> > >> > However, the above logic of using cascaded font list in >> CFont does not >> > take into account of using JRE provided fonts like all >> those Lucida* ttf >> > in jdk/lib/fonts/, so >> > when a glyph (in this intance, arabic 'alef' character) is >> intended to >> > be rendered in Menlo font in italic style, osx will not be >> able to find >> > the glyph in Menlo-Italic font >> > and neither in all the cascaded system fonts provided by >> CoreText, so it >> > results in empty box. >> > >> > Before 7162125 fix, the fallback code in >> > >> CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() >> uses >> > JRSFontCreateFallbackFontForCharacters() >> > was adding jre/lib/fonts to the fallback list which was >> causing the >> > glyph to be found in "LucidaBrightRegular.ttf" font and the >> glyph was >> > rendered. >> > >> > So, the proposed fix is to add jre provided font "Lucida >> Sans Regular" >> > to the cascaded list so that we get the "alef" glyph. >> > The reason for choosing "Lucida Sans Regular" over "Lucida >> Bright >> > Regular" is, because it is the largest font file in jre and >> has all the >> > glyph codepoints that no other font in the jre has, >> > so we will not lose out on any codepoints and will help us >> in not >> > getting missing glyph. >> > >> > webrev: >> http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ >> >> > > >> > >> > Regards >> > Prasanta >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batrak at jetbrains.com Thu Feb 16 08:02:30 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Thu, 16 Feb 2017 11:02:30 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X In-Reply-To: <25b11d07-c01c-1bff-069d-8515ac49d2bc@oracle.com> References: <5d0f21c0-8828-35d8-41f4-8bed4656c994@oracle.com> <25b11d07-c01c-1bff-069d-8515ac49d2bc@oracle.com> Message-ID: I used macOS 10.12.3 and I got the same cascade list for Menlo-Italic as Prasanta mentioned (with .AppleSymbolsFB substituted and .NotoSansUniversal omitted in Java code). If it's not possible to add .NotoSansUniversal now, some Unicode ranges, apart from Arabic, will still remain not covered in OpenJDK builds (e.g. Ethiopic and Dingbats) for the Menlo-Italic case. Don't know whether that can be considered critical. Other non-hidden fonts can probably be added to cover those ranges as well, if needed. Best regards, Dmitry Batrak On Thu, Feb 16, 2017 at 8:33 AM, Prasanta Sadhukhan < prasanta.sadhukhan at oracle.com> wrote: > Hi Phil, > I was using osx10.11 but the list I enumerated in JBS is actually the > composite font I get in CCompositeGlyphMapper#convertToGlyph() which > contains those 29 slots [CCompositeGlyphMapper#convertToGlyph(unicode=value > 1575) gets the glyph code(909) from slot[4] which is CourierNewPSMT, for > italic the list was taken from convertToGlyph()] > > But, if we are considering the cascade list "listOfString", it contains > .NotoSansUniversal just before AppleColorEmoji. > > However, it does not get added to CompositeFont list because findFont2D() > returned null for it. There was another hidden font in the cascade list > ".AppleSymbolsFB" but it was changed to "AppleSymbols" and that along with > other fonts findFont2D() was able to find and could add to CompositeFont > list for convertGlyph() to use. > > Regards > Prasanta > On 2/15/2017 10:40 PM, Phil Race wrote: > > Hi, > I don't know what versions of MacOS X either of you (Dmitry+Prasanta) used > but I am going to guess they are different > (can you both report these, for the record). > > In https://bugs.openjdk.java.net/browse/JDK-8147002, Prasanta enumerates > the cascade list for the Italic case and I don't see .NotoSansUniversal > anywhere on that list. > > So although if enumerated it likely still won't work (since it is not > enumerated by the other APIs), > there does not appear to be any font in the cascade list reported by > Prasanta that "would not work", > so the fix still seems fine to me as it is plugging a gap. > > A fix for using "hidden" fonts in the cascade list seems like a JDK 10 > candidate unless there > is some critical case we are still missing. > > -phil. > > > > On 02/13/2017 01:56 AM, Dmitry Batrak wrote: > > > Yes, we are aware this fixed it only for Oracle JDK. > > The bit I missed is that GeezaProInterface was then used on OpenJDK by > JRS. > > So we could add that as well. > > If you have any other fonts you think should be added to the tail of > that list we > > can add them too. > > I ran JRSFontCreateFallbackFontForCharacters against all Unicode code > points with Menlo-Italic as base font, > and got 63 possible fallback fonts - vs 29 present in cascade list, > currently used by JDK 9 (given in JDK-8147002). > So the mismatch is quite large. But the interesting thing is that cascade > list returned by > CTFontCopyDefaultCascadeListForLanguages still covers that whole Unicode > range. The problem is that JDK > doesn't use that list fully. In particular, Arabic alef letter U+0627 can > be displayed using the font > .NotoSansUniversal from that list. This font doesn't get into composite > font, as it's not found among the fonts > known to Java. So a better fix (and still quite small) will probably be > using those 'hidden' fonts as part of > cascade composites - by creating a new, 'local' CFont instance if lookup > in the known font list fails > (this, btw, seems to work fine for us). If even this is considered risky > for JDK 9, then probably adding > .NotoSansUniversal with or instead of .GeezaProInterface as a hardcoded > component makes sense. > > Best regards, > Dmitry Batrak > > On Fri, Feb 10, 2017 at 8:19 PM, Phil Race wrote: > >> I think that so long as we are using JRS* in some places and CoreText's >> cascading list >> in others there is the likelihood of some inconsistency where JRS >> introduces some magic >> that we don't know about >> >> So canDisplay() needs to be fixed to be consistent and perhaps we also >> need to see >> if we are always getting the glyphs from the same fonts for the cases >> where there >> is no missing glyph. >> >> I do agree that getting away from JRS* support is the way to go so we are >> in control. >> However not at this time in JDK 9. >> >> Yes "." fonts are not enumerated by OS X but if you can find them they >> work. >> This is how the UI fonts are handled. >> >> Yes, we are aware this fixed it only for Oracle JDK. >> The bit I missed is that GeezaProInterface was then used on OpenJDK by >> JRS. >> So we could add that as well. >> If you have any other fonts you think should be added to the tail of that >> list we >> can add them too. >> >> -phil. >> >> On 02/10/2017 07:59 AM, Dmitry Batrak wrote: >> >>> Hi, >>> >>> I've tried to build OpenJDK from 'client' repository with the fix, and >>> the >>> issue is still reproducible for me. Are you fixing it only for Oracle JDK >>> (including Lucida Sans Regular font), and not for OpenJDK? The problem >>> is not >>> that some character cannot be rendered using a particular font, it's that >>> rendering behaviour doesn't match what 'canDisplay' returns. >>> >>> If you're interested I can share the way we've fixed this issue in our >>> OpenJDK-based runtime. >>> >>> As you've mentioned, the problem is that >>> JRSFontCreateFallbackFontForCharacters returns fallback font, which is >>> not on >>> the cascaded font list, and it can be absent even in the whole list of >>> fonts >>> reported by the system. On my machine, with OpenJDK, it's >>> .GeezaProInterface >>> (with name starting with dot). I guess such fonts are treated by macOS as >>> 'hidden' (just like files with names starting with dots), still they >>> seem to be >>> usable from application if requested by their name. >>> >>> As JRSFontCreateFallbackFontForCharacters is a 'black box', it's hard >>> to make >>> sure cascade list we're building matches its internal logic, so we've >>> chosen to >>> build the list dynamically based on the output of >>> JRSFontCreateFallbackFontForCharacters itself. I can try to prepare >>> corresponding webrev, if you think that can be useful. >>> >>> Alternative solution (and, probably, a better one strategically), would >>> be not >>> using JRSFontCreateFallbackFontForCharacters at all. The cascade list, >>> that is >>> built currently, can probably be used to perform font fallback in all >>> cases. >>> >>> Best regards, >>> Dmitry Batrak >>> >>> >>> > Hi All, >>> > >>> > Please review a fix for an issue which causes arabic character "alef" >>> to >>> > be not rendered in osx for menlo font in italic style. >>> > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8147002 >>> > >>> > The issue was actually a regression caused by the fix to JDK-7162125: >>> > [macosx] A font has different behaviour for ligatures depending on its >>> > creation mode >>> > in which we have added cascaded font list to find the real fonts that >>> > CFont uses, so that there is no need to use "negative" glyph code for >>> > finding the fallback fonts >>> > using the "subsititution"/"fallback" mechanism used by osx code. >>> > >>> > However, the above logic of using cascaded font list in CFont does not >>> > take into account of using JRE provided fonts like all those Lucida* >>> ttf >>> > in jdk/lib/fonts/, so >>> > when a glyph (in this intance, arabic 'alef' character) is intended to >>> > be rendered in Menlo font in italic style, osx will not be able to find >>> > the glyph in Menlo-Italic font >>> > and neither in all the cascaded system fonts provided by CoreText, so >>> it >>> > results in empty box. >>> > >>> > Before 7162125 fix, the fallback code in >>> > CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() >>> uses >>> > JRSFontCreateFallbackFontForCharacters() >>> > was adding jre/lib/fonts to the fallback list which was causing the >>> > glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was >>> > rendered. >>> > >>> > So, the proposed fix is to add jre provided font "Lucida Sans Regular" >>> > to the cascaded list so that we get the "alef" glyph. >>> > The reason for choosing "Lucida Sans Regular" over "Lucida Bright >>> > Regular" is, because it is the largest font file in jre and has all the >>> > glyph codepoints that no other font in the jre has, >>> > so we will not lose out on any codepoints and will help us in not >>> > getting missing glyph. >>> > >>> > webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/ < >>> http://cr.openjdk.java.net/%7Epsadhukhan/8147002/webrev.00/> >>> > >>> > Regards >>> > Prasanta >>> >>> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Thu Feb 16 12:13:23 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Feb 2017 15:13:23 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8175025: The copyright section in the test/java/awt/font/TextLayout/DiacriticsDrawingTest.java should be updated In-Reply-To: References: Message-ID: <767EE5AF-41E0-42A3-A6F1-65B1BD557765@oracle.com> Looks fine. > > Hello, > > Could you review a simple fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8175025 > webrev: http://cr.openjdk.java.net/~dmarkov/8175025/webrev.00/ > > Changed the license in the test to GPL v2. > > Thanks, > Dmitry From vadim.pakhnushev at oracle.com Thu Feb 16 19:23:16 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 16 Feb 2017 22:23:16 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8175025: The copyright section in the test/java/awt/font/TextLayout/DiacriticsDrawingTest.java should be updated In-Reply-To: <767EE5AF-41E0-42A3-A6F1-65B1BD557765@oracle.com> References: <767EE5AF-41E0-42A3-A6F1-65B1BD557765@oracle.com> Message-ID: <2c8f1414-7e77-2167-fe54-37a975b384b1@oracle.com> +1 Vadim On 16.02.2017 15:13, Sergey Bylokhov wrote: > Looks fine. > >> Hello, >> >> Could you review a simple fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8175025 >> webrev: http://cr.openjdk.java.net/~dmarkov/8175025/webrev.00/ >> >> Changed the license in the test to GPL v2. >> >> Thanks, >> Dmitry