From prasanta.sadhukhan at oracle.com Fri Jul 1 06:10:59 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 1 Jul 2016 11:40:59 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified In-Reply-To: <57759627.5010203@oracle.com> References: <57710D96.8010808@oracle.com> <57740C8B.10609@oracle.com> <5774F4EB.7050806@oracle.com> <57759627.5010203@oracle.com> Message-ID: <57760973.7070900@oracle.com> Hi Phil, Right. I have rectified the calculation. Please find the modified webrev: http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.02/ Regards Prasanta On 7/1/2016 3:29 AM, Phil Race wrote: > Shouldn't these all be >= and <= ? > Else (eg) for X==1 in both cases you would return false when it should > be true .. > f ((mpa.getX(units) > mediaPrintables[i].getX(units)) && > > -phil. > > > On 06/30/2016 03:31 AM, Prasanta Sadhukhan wrote: >> Hi Phil, >> >> I modified the method to check for "fit" rather than perfect match as >> you suggested. >> Please find the modified webrev >> http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.01/ >> >> Regards >> Prasanta >> On 6/29/2016 11:29 PM, Philip Race wrote: >>> This is actually a little subtle. >>> >>> The check you are deleting has been there since 2000 .. >>> and it can't just be removed. But it need adjusting. >>> This is the subtlety. Most of the attribute checks >>> are yes/no. I think for this one we need to look at >>> the actual dimensions and return true if it is "fits" >>> So isSupportedMediaPrintableArea needs to do more than "equals" >>> I am not 100% sure that won't surprise some other code but >>> as far as I can think right now it seems the right thing to do. >>> >>> -phil. >>> >>> On 6/27/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it was found that setting >>>> left margin of 2" is ignored and when we query >>>> PrinterJob.job.getPageFormat(PrintRequestAttributeSet) >>>> we get the default paper mediapritable area of x=1" instead of the >>>> set 2". >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6789262 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.00/ >>>> >>>> This is because >>>> it was found that getPageFormat() calls >>>> Win32PrintService#isAttributeValueSupported() where we call >>>> isSupportedMediaPrintableArea() >>>> to check if the mediaprintable area is matching with the media size >>>> that has been cached. It gets the paperID by calling findPaperID() >>>> and stores the mpa of that paper in MediaPrintableArea[] >>>> I see that my printer supports 43 mediasize names (like iso_a4, >>>> iso_a5, na_letter etc) and none of the 43 mediaPrintables equals >>>> the mpa value of (50.4, 25.4, 133.8, 246.2)mm >>>> >>>> ---------------isSupportedMediaPrintableArea()--------- >>>> if (mediaPrintables != null) { >>>> for (int i=0; i>>> if (mpa.equals(mediaPrintables[i])) { >>>> return true; >>>> } >>>> } >>>> } >>>> ---------------------- >>>> So, it seems this check isSupportedMediaPrintableArea() is >>>> preventing valid mpa values to be propagated to RasterPrinterJob to >>>> be used for printing. >>>> >>>> I see in linux and mac, >>>> *IPPPrintService*#isAttributeValueSupported() is called which does >>>> not have this isSupportedMediaPrintableArea() check and there this >>>> left margin of 2" is not ignored and stored properly. >>>> >>>> So, the proposed fix do away with this >>>> isSupportedMediaPrintableArea() call from >>>> Win32PrintService#isAttributeValueSupported. >>>> >>>> Regards >>>> Prasanta >>>> >>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 1 09:23:20 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 1 Jul 2016 14:53:20 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <57752ABC.4020406@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> <57752ABC.4020406@oracle.com> Message-ID: <57763688.4070806@oracle.com> Hi Phil, On 6/30/2016 7:50 PM, Philip Race wrote: > Eh ? Before your change the code was calling > isAttributeCategorySupported(), not isAttributeValueSupported() So > there was not previously a possibility of that NPE, and my point was > now you have changed that call you need that !=null check even more .. Yes, I got that, right immediately after sending the below mail and sent another email clarifying my misunderstanding. > But I think there is still a problem. Now dstSupported is set only if > the *specific* destination is supported. A malformed file: URL would > not be valid but should not disable (grey out) the print to file > checkbox which is what it looks like here .. can you verify this ? Yes, we will grey out the checkbox for malformed url (like files::/tmp/output.ps) as I found out. Please find modified webrev that takes care of this problem too: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.02/ Regards Prasanta > -phil > > > On 6/30/16, 12:45 AM, Prasanta Sadhukhan wrote: >> Hi Phil, >> >> NPE will be thrown >> ---------- >> public boolean isAttributeValueSupported(Attribute attr, >> DocFlavor flavor, >> AttributeSet attributes) { >> if (attr == null) { >> throw new NullPointerException("null attribute"); >> } >> --------- >> before updateInfo() will be called so I guess null check is redundant >> there. Anyways, I have added the check back just to be safe >> http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ >> >> Regards >> Prasanta >> On 6/29/2016 11:59 PM, Philip Race wrote: >>> --- >>> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- >>> >>> >>> Throws: >>> NullPointerException - (unchecked exception) if attrval is null. >>> >>> -- >>> >>> So why did you remove the check for null ? >>> >>> >>> -phil. >>> >>> On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that >>>> "Print-To-File" option is enabled even for flavors that do not >>>> support Destination attribute >>>> even though isAttributeValueSupported for that flavor returns false. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ >>>> >>>> The reason for this behaviour is in Print Dialog code, the >>>> validation is done against isAttributeCategorySupported() which >>>> still returns true because Pageable and Printable supports it >>>> and therefore the "Print-to-File" option gets enabled. >>>> >>>> But print dialog is shown specific to a doc flavor and a print >>>> service (selected one) and hence must validate the attribute >>>> against the chosen doc flavor. >>>> So, the proposed fix checks the attributevalue is supported or not >>>> for that flavor to determine if we need to enable "Print-to-File" >>>> option in print dialog. >>>> >>>> Regards >>>> Prasanta >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jul 1 10:31:42 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 1 Jul 2016 03:31:42 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <57744D0D.9080809@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <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> Message-ID: <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> Hi Jim, Thanks for your inputs. I have discussed with Phil also regarding the same issue offline. I have collated all the changes mentioned by you and Phil in the latest webrev: http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, June 30, 2016 4:05 AM 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 Hi Jay, We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. A few grammar fixes: In all of the classes, insert a space before any parentheses in comment text as in "the same class (and not a subclass)". (That wouldn't apply if the text in the comment is referring to code - then space it as you would actual code.) In CM, insert the word "the" as in "also check the following ..." In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". ...jim On 06/29/2016 04:13 AM, Jayathirth D V wrote: > Hi, > > Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Saturday, June 04, 2016 4:52 AM > To: Jayathirth D V; Philip Race > Cc: 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 > > That looks good to me. Has the CCC cleared yet? > > ...jim > > On 6/3/16 2:49 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Oh that's an important change. >> Thanks for your review. >> >> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, June 03, 2016 2:25 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >> are missing hashCode() or equals() or both methods >> >> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >> >> Possible solutions: >> >> - Truncate validBits when it is accepted in the constructor >> (validBits.and(...)) >> - Manually compute the hash of the first N bits of validBits >> - Not use validBits in the hash code since it is allowed to omit >> significant data from the hash >> >> (Note that everything in hashcode must participate in equals(), but >> not vice versa) >> >> The same is true of nBits in ColorModel. (nBits can be copied and >> truncated with Arrays.copyOf) >> >> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >> >> ...jim >> >> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>> Hi Phil, >>> >>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>> Please find the updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Philip Race >>> Sent: Wednesday, June 01, 2016 10:06 PM >>> To: Jayathirth D V >>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>> are missing hashCode() or equals() or both methods >>> >>> Please post the updated webrev. >>> >>> -phil. >>> >>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>> Hi Phil& Jim, >>>> >>>> Collating all the changes needed: >>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>> 3) Comment section of equals() method, I will update it to : >>>> 1449 * the target object must be the same class (and not a subclass) as this >>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>> >>>> Please let me know your inputs. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>> To: Phil Race >>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>> are missing hashCode() or equals() or both methods >>>> >>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>> >>>> ...jim >>>> >>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>> I don't know of any design intent, so yes, I meant more as a >>>>> practical matter. >>>>> Unless they subclass then using equals() which I thought unlikely >>>>> it makes no difference here. >>>>> But it would be proof against that to use equals, unlikely to >>>>> matter as it might be .. >>>>> >>>>> -phil. >>>>> >>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>> >>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>> Hi Jay, >>>>>>>> >>>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>>> you simply removed it from the patch. You still need to edit >>>>>>>> it to remove the existing methods. >>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>>> not intentional. >>>>>>> >>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>> instances >>>>>>>> - Phil? >>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>> hashCode and all the predefined ones are constructed as >>>>>>> singletons so it seems unlikely to cause problems >>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>> baking in the assumption that it doesn't implement equals() into >>>>>> our implementation of the CM.equals() method. Might it some day >>>>>> implement equals (perhaps it isn't a practical issue today, but >>>>>> it might be in the future when we forget that it was omitted in >>>>>> this usage we create today). >>>>>> >>>>>> I guess what I'm asking is if it is a design feature that >>>>>> different objects are considered non-equal (such as an object >>>>>> that, for instance, has only predetermined instances that are >>>>>> shared by reference and reused). I think color spaces are sort >>>>>> of in-between in that we define a few constants that simply get >>>>>> used by reference in 99% of cases, but that isn't a design >>>>>> feature, more like a practical issue... >>>>>> >>>>>> ...jim From yasuenag at gmail.com Fri Jul 1 14:16:08 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Jul 2016 23:16:08 +0900 Subject: [OpenJDK 2D-Dev] Status of building problem with GCC 6 Message-ID: Hi all, I want to share task list for building OpenJDK with GCC 6. * jdk: - JDK-8160294: reviewing * hotspot Subtasks of JDK-8160310: - JDK-8160353: reviewing (includes patch for JDK-8156980) - JDK-8160354: reviewing (a part of fix depends on JDK-8156980) - JDK-8160356: waiting to push - JDK-8160357: might be discarded if JDK-8156980 will be resolved. - JDK-8160361: waiting to push - JDK-8160363: might be discarded if JDK-8156980 will be resolved. For HotSpot, I think JDK-8156980 should be fixed at first. I've proposed changes as below: ----------- diff -r ba08710f3b6c make/lib/CompileJvm.gmk --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 @@ -187,6 +187,11 @@ JVM_OPTIMIZATION ?= HIGHEST_JVM +JVM_CXXFLAGS := $(JVM_CFLAGS) +ifeq ($(TOOLCHAIN_TYPE), gcc) + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse +endif + ################################################################################ # Now set up the actual compilation of the main hotspot native library @@ -202,6 +207,7 @@ CFLAGS := $(JVM_CFLAGS), \ CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ + CXXFLAGS := $(JVM_CXXFLAGS), \ vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ empty-body format logical-op-parentheses parentheses \ ----------- I guess GCC 6 (or later) will be provided from several Linux Distros in near future. In fact, Fedora 24 already provides it. I'm sure this work helps many developers who use Linux. Thanks, Yasumasa From erik.joelsson at oracle.com Fri Jul 1 17:47:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Jul 2016 19:47:06 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed Message-ID: <5776AC9A.5000400@oracle.com> The separation between OpenJDK and Oracle's closed additions have historically been quite messy. The build-infra project has tried to improve on this, but failed in one regard, which was to hard code all references to "closed" source instead of using a variable. I decided to finally fix this. Along the way, I found that there weren't that many references left in open makefiles, which is a good thing. OpenJDK should not be tainted with Oracle specific stuff unnecessarily. So then I decided to completely remove the last references as part of fixing this bug. With this patch, the following is now in effect: * There is no longer a variable named "OPENJDK". That variable was confusing and got in the way of other people trying to add custom additions to the OpenJDK code base. In configure there is now only "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only option. This variable can be read by custom extensions to configure and should be used to disable those custom extensions. * There is no Oracle specific logic left in open makefiles. All customizations and references to custom source should be done in custom makefiles, included using the IncludeCustomExtension macro. I have converted the last uses of "ifndef OPENJDK" to such constructs. I have moved all Oracle specific mapfiles out of the open jdk repository. Specifically to 2d-dev reviewers, I have moved jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out of the open as well. This file has been explicitly excluded from all open builds since forever AFAICT. I see no reason for it be in the open. If someone would like to read the source outside of Oracle, it will still be in the hg history. I have tested these changes extensively using the compare script and -testset buildinfra in JPRT. This covers a wide variety of build configurations so I feel pretty confident that it won't break anything. Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ /Erik From philip.race at oracle.com Fri Jul 1 17:59:38 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Jul 2016 10:59:38 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776AC9A.5000400@oracle.com> References: <5776AC9A.5000400@oracle.com> Message-ID: <5776AF8A.9040505@oracle.com> erik, SUPPRESS_CUSTOM_SOURCE" FWIW "CLOSED" implies better to me what this is about than "CUSTOM". Can't this be SUPPRESS_CLOSED_SOURCE ? http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html Regarding all the freetype symbols in here .. they aren't used in the Oracle JDK, so is there another closed version of this file for the 'custom' source ? 57 ifdef OPENJDK 458 BUILD_LIBJAVAJPEG_MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers 459 else 460 BUILD_LIBJAVAJPEG_MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers-closed 461 LIBJAVAJPEG_SRC += $(JDK_TOPDIR)/src/closed/java.desktop/share/native/libjavajpeg 462 endif 463 Where is the closed replacement for this ? In another review you will send out internally ? > I have tested these changes extensively using the compare script and -testset buildinfra in JPRT So this verifies the resulting "bits" are correct ? .. and that includes the various combinations you are providing ? - build openjdk in presence of only openjdk - build oracle jdk in presence of open+closed - build 'openjdk-only" in presence of open+closed -phil. On 07/01/2016 10:47 AM, Erik Joelsson wrote: > The separation between OpenJDK and Oracle's closed additions have > historically been quite messy. The build-infra project has tried to > improve on this, but failed in one regard, which was to hard code all > references to "closed" source instead of using a variable. I decided > to finally fix this. Along the way, I found that there weren't that > many references left in open makefiles, which is a good thing. OpenJDK > should not be tainted with Oracle specific stuff unnecessarily. So > then I decided to completely remove the last references as part of > fixing this bug. With this patch, the following is now in effect: > > * There is no longer a variable named "OPENJDK". That variable was > confusing and got in the way of other people trying to add custom > additions to the OpenJDK code base. In configure there is now only > "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only > option. This variable can be read by custom extensions to configure > and should be used to disable those custom extensions. > > * There is no Oracle specific logic left in open makefiles. All > customizations and references to custom source should be done in > custom makefiles, included using the IncludeCustomExtension macro. I > have converted the last uses of "ifndef OPENJDK" to such constructs. > > I have moved all Oracle specific mapfiles out of the open jdk repository. > > Specifically to 2d-dev reviewers, I have moved > jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java > out of the open as well. This file has been explicitly excluded from > all open builds since forever AFAICT. I see no reason for it be in the > open. If someone would like to read the source outside of Oracle, it > will still be in the hg history. > > I have tested these changes extensively using the compare script and > -testset buildinfra in JPRT. This covers a wide variety of build > configurations so I feel pretty confident that it won't break anything. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 > Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ > > /Erik From erik.joelsson at oracle.com Fri Jul 1 18:16:33 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Jul 2016 20:16:33 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776AF8A.9040505@oracle.com> References: <5776AC9A.5000400@oracle.com> <5776AF8A.9040505@oracle.com> Message-ID: <5776B381.9020304@oracle.com> On 2016-07-01 19:59, Phil Race wrote: > erik, > > SUPPRESS_CUSTOM_SOURCE" > FWIW "CLOSED" implies better to me what this is about than "CUSTOM". > Can't this be SUPPRESS_CLOSED_SOURCE ? > "custom" is a term that we have been using for a while now instead of "closed" in the open parts of the build to refer to any kind of custom addition to OpenJDK. There are quite a few instances of macros and variables named that way, mostly in configure but also in the makefiles. If we were to change this variable to "closed", then the other places should go with it to match. I think that's a separate change that require a separate discussion. > http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html > > > Regarding all the freetype symbols in here .. they aren't used in the > Oracle JDK, so is there another > closed version of this file for the 'custom' source ? > Yes, it's in the closed review. The pattern is to have open mapfiles in the open and OracleJDK specific mapfiles in the Oracle closed repository. > 57 ifdef OPENJDK > 458 BUILD_LIBJAVAJPEG_MAPFILE := > $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers > 459 else > 460 BUILD_LIBJAVAJPEG_MAPFILE := > $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers-closed > 461 LIBJAVAJPEG_SRC += > $(JDK_TOPDIR)/src/closed/java.desktop/share/native/libjavajpeg > 462 endif > 463 > > Where is the closed replacement for this ? In another review you will > send out internally ? > Yes. >> I have tested these changes extensively using the compare script and >> -testset buildinfra in JPRT > So this verifies the resulting "bits" are correct ? > Yes. I went through a number of iterations to iron out all the details using this technique. It's quite powerful. > .. and that includes the various combinations you are providing ? > - build openjdk in presence of only openjdk > - build oracle jdk in presence of open+closed > - build 'openjdk-only" in presence of open+closed > Actually the first one is missing because of how JPRT works, but I could run an extra round with just that. That case is the least complicated however since it will just build what is there. /Erik From philip.race at oracle.com Fri Jul 1 18:24:47 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Jul 2016 11:24:47 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified In-Reply-To: <57760973.7070900@oracle.com> References: <57710D96.8010808@oracle.com> <57740C8B.10609@oracle.com> <5774F4EB.7050806@oracle.com> <57759627.5010203@oracle.com> <57760973.7070900@oracle.com> Message-ID: <5776B56F.7070007@oracle.com> +1 ... although I am a little nervous about FP error causing false results in some cases. -phil. On 06/30/2016 11:10 PM, Prasanta Sadhukhan wrote: > Hi Phil, > > Right. I have rectified the calculation. Please find the modified webrev: > http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.02/ > > Regards > Prasanta > On 7/1/2016 3:29 AM, Phil Race wrote: >> Shouldn't these all be >= and <= ? >> Else (eg) for X==1 in both cases you would return false when it >> should be true .. >> f ((mpa.getX(units) > mediaPrintables[i].getX(units)) && >> >> -phil. >> >> >> On 06/30/2016 03:31 AM, Prasanta Sadhukhan wrote: >>> Hi Phil, >>> >>> I modified the method to check for "fit" rather than perfect match >>> as you suggested. >>> Please find the modified webrev >>> http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 6/29/2016 11:29 PM, Philip Race wrote: >>>> This is actually a little subtle. >>>> >>>> The check you are deleting has been there since 2000 .. >>>> and it can't just be removed. But it need adjusting. >>>> This is the subtlety. Most of the attribute checks >>>> are yes/no. I think for this one we need to look at >>>> the actual dimensions and return true if it is "fits" >>>> So isSupportedMediaPrintableArea needs to do more than "equals" >>>> I am not 100% sure that won't surprise some other code but >>>> as far as I can think right now it seems the right thing to do. >>>> >>>> -phil. >>>> >>>> On 6/27/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it was found that setting >>>>> left margin of 2" is ignored and when we query >>>>> PrinterJob.job.getPageFormat(PrintRequestAttributeSet) >>>>> we get the default paper mediapritable area of x=1" instead of the >>>>> set 2". >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6789262 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.00/ >>>>> >>>>> This is because >>>>> it was found that getPageFormat() calls >>>>> Win32PrintService#isAttributeValueSupported() where we call >>>>> isSupportedMediaPrintableArea() >>>>> to check if the mediaprintable area is matching with the media >>>>> size that has been cached. It gets the paperID by calling >>>>> findPaperID() and stores the mpa of that paper in MediaPrintableArea[] >>>>> I see that my printer supports 43 mediasize names (like iso_a4, >>>>> iso_a5, na_letter etc) and none of the 43 mediaPrintables equals >>>>> the mpa value of (50.4, 25.4, 133.8, 246.2)mm >>>>> >>>>> ---------------isSupportedMediaPrintableArea()--------- >>>>> if (mediaPrintables != null) { >>>>> for (int i=0; i>>>> if (mpa.equals(mediaPrintables[i])) { >>>>> return true; >>>>> } >>>>> } >>>>> } >>>>> ---------------------- >>>>> So, it seems this check isSupportedMediaPrintableArea() is >>>>> preventing valid mpa values to be propagated to RasterPrinterJob >>>>> to be used for printing. >>>>> >>>>> I see in linux and mac, >>>>> *IPPPrintService*#isAttributeValueSupported() is called which does >>>>> not have this isSupportedMediaPrintableArea() check and there this >>>>> left margin of 2" is not ignored and stored properly. >>>>> >>>>> So, the proposed fix do away with this >>>>> isSupportedMediaPrintableArea() call from >>>>> Win32PrintService#isAttributeValueSupported. >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>>>> >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 1 20:17:42 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Jul 2016 13:17:42 -0700 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <57746B6D.5030405@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> <57746B6D.5030405@oracle.com> Message-ID: <5776CFE6.4000206@oracle.com> Hi, You have 3 reviewers (2 client, 1 build) so I am OK for this to be pushed. If Kim comes back with some more information the a new fix can be devised .. -phil. On 06/29/2016 05:44 PM, Philip Race wrote: > Hi, > > Not just yet. Whilst I am OK with it ... > > 1) We like 2 (two) reviewers to approve. > 2) I would like Kim to reply to the questions so I understand > his concerns first. > > -phil. > > On 6/29/16, 4:30 PM, Yasumasa Suenaga wrote: >> Hi Kim, Phil, >> >> Can I push this patch? >> It has been reviewed. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/29 2:38, Phil Race wrote: >>> On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: >>>> Hi Kim, >>>> >>>> The newest changes for jdk repos is [1]. >>>> Erik points we should use DISABLED_WARNINGS_gcc to handle unknown >>>> warning tags. [2] >>>> [1] is implemented with it. >>>> >>>> This change is already reviewed by 2d folks. >>>> So I want to merge it ASAP. >>>> >>>> Do you have any objection? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html >>>> >>>> >>>> On 2016/06/28 8:37, Kim Barrett wrote: >>>>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> This review request relates to [1]. >>>>>> >>>>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>>>> >>>>>> I fixed build error and several issues (VM crash and internal >>>>>> error) as below: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>>>> >>>>>> Does someone work for it? >>>>>> If no one works for it, I will file it to JBS and will send >>>>>> review request. >>>>>> >>>>>> For jdk repos, I've sent review request [2]. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>>>> >>>>>> [2] >>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>>>> >>>>> Having gone through these, I think all of them are arising due to >>>>> build system problems, where we seem to have lost the compiler >>>>> configuration to use explicit selection of the language standard and >>>>> some additional options. >>> >>> Do tell more about what this means. Where would this previously have >>> been seen ? >>> Different versions of Visual Studio / CLANG / GCC all emit different >>> warnings >>> and it is not always monotonically increasing with compiler version, >>> and I >>> can imagine someone might want to have different sets of flags in >>> general >>> depending on compiler version in use, but I have not seen a pattern >>> of this >>> being applied to the warnings on any of the platforms. >>> >>> in the makefile here there is just one special case of this .. >>> >>> 474 # Suppress gcc warnings like "variable might be clobbered by >>> 'longjmp' >>> 475 # or 'vfork'": this warning indicates that some variable is >>> placed to >>> 476 # a register by optimized compiler and it's value might be lost >>> on longjmp(). >>> 477 # Recommended way to avoid such warning is to declare the >>> variable as >>> 478 # volatile to prevent the optimization. However, this approach >>> does not >>> 479 # work because we have to declare all variables as volatile in >>> result. >>> 480 #ifndef CROSS_COMPILE_ARCH >>> 481 # CC_43_OR_NEWER := \ >>> 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ >>> 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) >>> 484 # ifeq ($(CC_43_OR_NEWER), 1) >>> 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered >>> 486 # endif >>> 487 #endif >>> >>> >>>>> >>>>> For now I think we should fix the build system problems, and file >>>>> additional bugs or update existing ones as needed to fix the root >>>>> causes of the problems encountered. I think many of the proposed >>>>> changes do not address the root causes, and should not be made. See >>>>> my comments for the specific bugs. >>>>> >>>>> I'm not on the mailing list where the jdk RFR was submitted. I >>>>> took a >>>>> look at them though, and >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> make/lib/Awt2dLibraries.gmk >>>>> 407 # Avoid warning for GCC 6 >>>>> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>>> 409 LCMS_CFLAGS += -Wno-misleading-indentation >>>>> 410 endif >>>>> >>>>> 926 # Avoid warning for GCC 6 >>>>> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>>> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += >>>>> -Wno-shift-negative-value >>>>> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += >>>>> -Wno-shift-negative-value >>>>> 930 endif >>>>> >>>>> The -Wmisleading-indentation and -Wshift-negative-value options are >>>>> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >>>>> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >>>>> still using older versions. So these will need to be conditionalized >>>>> on the gcc version. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >>>>> >>>>> 154 if (min < 0) min = 0; >>>>> 155 if (max < min) max = min; /* defensive coding */ >>>>> >>>>> [splitting the line] >>>>> >>>>> Seems like this would be suppressed by -Wno-misleading-indentation, >>>>> especially since the reported warning is for that. Why change both >>>>> the code and the build configuration? >>> >>> Was that something seen in the original fix ? It is not in the >>> version I reviewed. >>> The current version of the fix does not update the makefile to add this >>> .. except for LCMS - which is a different library. >>> >>> >>> -phil. >>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >>>>> >>> From kim.barrett at oracle.com Fri Jul 1 20:35:32 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Jul 2016 16:35:32 -0400 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <5776CFE6.4000206@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> <57746B6D.5030405@oracle.com> <5776CFE6.4000206@oracle.com> Message-ID: > On Jul 1, 2016, at 4:17 PM, Phil Race wrote: > > Hi, > > You have 3 reviewers (2 client, 1 build) so I am OK for this to be pushed. > If Kim comes back with some more information the a new fix can be devised .. http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ looks ok to me too. From yasuenag at gmail.com Sat Jul 2 13:35:22 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 2 Jul 2016 22:35:22 +0900 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> <57746B6D.5030405@oracle.com> <5776CFE6.4000206@oracle.com> Message-ID: <3f9789b3-2370-ac48-1f7a-2d2ab32b039b@gmail.com> Thank you for reviewing! I pushed: http://hg.openjdk.java.net/jdk9/client/jdk/rev/38185af88d22 Yasumasa On 2016/07/02 5:35, Kim Barrett wrote: >> On Jul 1, 2016, at 4:17 PM, Phil Race wrote: >> >> Hi, >> >> You have 3 reviewers (2 client, 1 build) so I am OK for this to be pushed. >> If Kim comes back with some more information the a new fix can be devised .. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ > looks ok to me too. > From david.holmes at oracle.com Sun Jul 3 21:54:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 07:54:47 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776B381.9020304@oracle.com> References: <5776AC9A.5000400@oracle.com> <5776AF8A.9040505@oracle.com> <5776B381.9020304@oracle.com> Message-ID: <692670b0-14f4-8d59-a129-d4555e0f9a00@oracle.com> On 2/07/2016 4:16 AM, Erik Joelsson wrote: > > > On 2016-07-01 19:59, Phil Race wrote: >> erik, >> >> SUPPRESS_CUSTOM_SOURCE" >> FWIW "CLOSED" implies better to me what this is about than "CUSTOM". >> Can't this be SUPPRESS_CLOSED_SOURCE ? >> > "custom" is a term that we have been using for a while now instead of > "closed" in the open parts of the build to refer to any kind of custom > addition to OpenJDK. There are quite a few instances of macros and > variables named that way, mostly in configure but also in the makefiles. > If we were to change this variable to "closed", then the other places > should go with it to match. I think that's a separate change that > require a separate discussion. Since we started supporting the oracle "closed" builds in the shared code the term we have used is CUSTOM because this was always intended to be a general customization mechanism that anyone could use to combine their own "customizations" with the OpenJDK sources. "closed" is just the Oracle name for their customizations. Cheers, David >> http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html >> >> >> Regarding all the freetype symbols in here .. they aren't used in the >> Oracle JDK, so is there another >> closed version of this file for the 'custom' source ? >> > Yes, it's in the closed review. The pattern is to have open mapfiles in > the open and OracleJDK specific mapfiles in the Oracle closed repository. >> 57 ifdef OPENJDK >> 458 BUILD_LIBJAVAJPEG_MAPFILE := >> $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers >> 459 else >> 460 BUILD_LIBJAVAJPEG_MAPFILE := >> $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers-closed >> 461 LIBJAVAJPEG_SRC += >> $(JDK_TOPDIR)/src/closed/java.desktop/share/native/libjavajpeg >> 462 endif >> 463 >> >> Where is the closed replacement for this ? In another review you will >> send out internally ? >> > Yes. >>> I have tested these changes extensively using the compare script and >>> -testset buildinfra in JPRT >> So this verifies the resulting "bits" are correct ? >> > Yes. I went through a number of iterations to iron out all the details > using this technique. It's quite powerful. >> .. and that includes the various combinations you are providing ? >> - build openjdk in presence of only openjdk >> - build oracle jdk in presence of open+closed >> - build 'openjdk-only" in presence of open+closed >> > Actually the first one is missing because of how JPRT works, but I could > run an extra round with just that. That case is the least complicated > however since it will just build what is there. > > /Erik From david.holmes at oracle.com Sun Jul 3 23:01:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 09:01:21 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776AC9A.5000400@oracle.com> References: <5776AC9A.5000400@oracle.com> Message-ID: <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> Hi Erik, On 2/07/2016 3:47 AM, Erik Joelsson wrote: > The separation between OpenJDK and Oracle's closed additions have > historically been quite messy. The build-infra project has tried to > improve on this, but failed in one regard, which was to hard code all > references to "closed" source instead of using a variable. I decided to > finally fix this. Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. That said there are still issues with trying to provide a mechanism for other customizations to use - more below. > Along the way, I found that there weren't that many > references left in open makefiles, which is a good thing. OpenJDK should > not be tainted with Oracle specific stuff unnecessarily. So then I > decided to completely remove the last references as part of fixing this > bug. With this patch, the following is now in effect: > > * There is no longer a variable named "OPENJDK". That variable was > confusing and got in the way of other people trying to add custom > additions to the OpenJDK code base. In configure there is now only > "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only > option. This variable can be read by custom extensions to configure and > should be used to disable those custom extensions. Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. > * There is no Oracle specific logic left in open makefiles. All > customizations and references to custom source should be done in custom > makefiles, included using the IncludeCustomExtension macro. I have > converted the last uses of "ifndef OPENJDK" to such constructs. Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in jdk/make/gendata/GendataBlacklistedCerts.gmk you have: GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem which allows the variable to be extended. In contrast in jdk/make/gendata/GendataFontConfig.gmk you have: GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig which allows the variable to be replaced. There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. > > I have moved all Oracle specific mapfiles out of the open jdk repository. Ok. Some specific comments: jdk/make/lib/Awt2dLibraries.gmk You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? jdk/make/mapfiles/libfontmanager/mapfile-vers Would it be better to delete the above file and hg rename mapfile- version instead? Thanks, David ----- > Specifically to 2d-dev reviewers, I have moved > jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out > of the open as well. This file has been explicitly excluded from all > open builds since forever AFAICT. I see no reason for it be in the open. > If someone would like to read the source outside of Oracle, it will > still be in the hg history. > > I have tested these changes extensively using the compare script and > -testset buildinfra in JPRT. This covers a wide variety of build > configurations so I feel pretty confident that it won't break anything. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 > Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ > > /Erik From philip.race at oracle.com Sun Jul 3 23:55:33 2016 From: philip.race at oracle.com (Phil Race) Date: Sun, 3 Jul 2016 16:55:33 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> Message-ID: <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> It is it all "extensions". It is mostly just different internal code as far as we (se client) are concerned so the word extension has entirely the wrong connotation for people in SE api land. -Phil. > On Jul 3, 2016, at 4:01 PM, David Holmes wrote: > > Hi Erik, > >> On 2/07/2016 3:47 AM, Erik Joelsson wrote: >> The separation between OpenJDK and Oracle's closed additions have >> historically been quite messy. The build-infra project has tried to >> improve on this, but failed in one regard, which was to hard code all >> references to "closed" source instead of using a variable. I decided to >> finally fix this. > > Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. > > That said there are still issues with trying to provide a mechanism for other customizations to use - more below. > >> Along the way, I found that there weren't that many >> references left in open makefiles, which is a good thing. OpenJDK should >> not be tainted with Oracle specific stuff unnecessarily. So then I >> decided to completely remove the last references as part of fixing this >> bug. With this patch, the following is now in effect: >> >> * There is no longer a variable named "OPENJDK". That variable was >> confusing and got in the way of other people trying to add custom >> additions to the OpenJDK code base. In configure there is now only >> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >> option. This variable can be read by custom extensions to configure and >> should be used to disable those custom extensions. > > Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. > >> * There is no Oracle specific logic left in open makefiles. All >> customizations and references to custom source should be done in custom >> makefiles, included using the IncludeCustomExtension macro. I have >> converted the last uses of "ifndef OPENJDK" to such constructs. > > Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. > > Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in > > jdk/make/gendata/GendataBlacklistedCerts.gmk > > you have: > > GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem > > which allows the variable to be extended. In contrast in > > jdk/make/gendata/GendataFontConfig.gmk > > you have: > > GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig > > which allows the variable to be replaced. > > There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. > >> >> I have moved all Oracle specific mapfiles out of the open jdk repository. > > Ok. > > Some specific comments: > > jdk/make/lib/Awt2dLibraries.gmk > > You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? > > jdk/make/mapfiles/libfontmanager/mapfile-vers > > Would it be better to delete the above file and hg rename mapfile- version instead? > > Thanks, > David > ----- > >> Specifically to 2d-dev reviewers, I have moved >> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >> of the open as well. This file has been explicitly excluded from all >> open builds since forever AFAICT. I see no reason for it be in the open. >> If someone would like to read the source outside of Oracle, it will >> still be in the hg history. >> >> I have tested these changes extensively using the compare script and >> -testset buildinfra in JPRT. This covers a wide variety of build >> configurations so I feel pretty confident that it won't break anything. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >> >> /Erik From philip.race at oracle.com Mon Jul 4 00:21:03 2016 From: philip.race at oracle.com (Phil Race) Date: Sun, 3 Jul 2016 17:21:03 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> Message-ID: -Phil. > On Jul 3, 2016, at 4:55 PM, Phil Race wrote: > > It is it all "extensions". That should have read : It is "not" all ... - Phil > It is mostly just different internal code as far as we (se client) are concerned so the word extension has entirely the wrong connotation for people in SE api land. > > -Phil. > >> On Jul 3, 2016, at 4:01 PM, David Holmes wrote: >> >> Hi Erik, >> >>> On 2/07/2016 3:47 AM, Erik Joelsson wrote: >>> The separation between OpenJDK and Oracle's closed additions have >>> historically been quite messy. The build-infra project has tried to >>> improve on this, but failed in one regard, which was to hard code all >>> references to "closed" source instead of using a variable. I decided to >>> finally fix this. >> >> Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. >> >> That said there are still issues with trying to provide a mechanism for other customizations to use - more below. >> >>> Along the way, I found that there weren't that many >>> references left in open makefiles, which is a good thing. OpenJDK should >>> not be tainted with Oracle specific stuff unnecessarily. So then I >>> decided to completely remove the last references as part of fixing this >>> bug. With this patch, the following is now in effect: >>> >>> * There is no longer a variable named "OPENJDK". That variable was >>> confusing and got in the way of other people trying to add custom >>> additions to the OpenJDK code base. In configure there is now only >>> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >>> option. This variable can be read by custom extensions to configure and >>> should be used to disable those custom extensions. >> >> Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >> >>> * There is no Oracle specific logic left in open makefiles. All >>> customizations and references to custom source should be done in custom >>> makefiles, included using the IncludeCustomExtension macro. I have >>> converted the last uses of "ifndef OPENJDK" to such constructs. >> >> Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. >> >> Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in >> >> jdk/make/gendata/GendataBlacklistedCerts.gmk >> >> you have: >> >> GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >> >> which allows the variable to be extended. In contrast in >> >> jdk/make/gendata/GendataFontConfig.gmk >> >> you have: >> >> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >> >> which allows the variable to be replaced. >> >> There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. >> >>> >>> I have moved all Oracle specific mapfiles out of the open jdk repository. >> >> Ok. >> >> Some specific comments: >> >> jdk/make/lib/Awt2dLibraries.gmk >> >> You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? >> >> jdk/make/mapfiles/libfontmanager/mapfile-vers >> >> Would it be better to delete the above file and hg rename mapfile- version instead? >> >> Thanks, >> David >> ----- >> >>> Specifically to 2d-dev reviewers, I have moved >>> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >>> of the open as well. This file has been explicitly excluded from all >>> open builds since forever AFAICT. I see no reason for it be in the open. >>> If someone would like to read the source outside of Oracle, it will >>> still be in the hg history. >>> >>> I have tested these changes extensively using the compare script and >>> -testset buildinfra in JPRT. This covers a wide variety of build >>> configurations so I feel pretty confident that it won't break anything. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >>> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >>> >>> /Erik > From david.holmes at oracle.com Mon Jul 4 01:02:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:02:49 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> Message-ID: <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> Fix typo ... On 4/07/2016 9:01 AM, David Holmes wrote: > Hi Erik, > > On 2/07/2016 3:47 AM, Erik Joelsson wrote: >> The separation between OpenJDK and Oracle's closed additions have >> historically been quite messy. The build-infra project has tried to >> improve on this, but failed in one regard, which was to hard code all >> references to "closed" source instead of using a variable. I decided to >> finally fix this. > > Great this is getting fixed. For the record we tried to do this > originally in the build (using "custom" variables) and in hotspot Using > ALT_SRC variables). But other parts of the sources tended to hardwire > the xxx/closed paths. > > That said there are still issues with trying to provide a mechanism for > other customizations to use - more below. > >> Along the way, I found that there weren't that many >> references left in open makefiles, which is a good thing. OpenJDK should >> not be tainted with Oracle specific stuff unnecessarily. So then I >> decided to completely remove the last references as part of fixing this >> bug. With this patch, the following is now in effect: >> >> * There is no longer a variable named "OPENJDK". That variable was >> confusing and got in the way of other people trying to add custom >> additions to the OpenJDK code base. In configure there is now only >> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >> option. This variable can be read by custom extensions to configure and >> should be used to disable those custom extensions. > > Only nit with that is the "source" tend to imply source code and of > course this "source" can be quite a range of artifacts. > SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. > >> * There is no Oracle specific logic left in open makefiles. All >> customizations and references to custom source should be done in custom >> makefiles, included using the IncludeCustomExtension macro. I have >> converted the last uses of "ifndef OPENJDK" to such constructs. > > Just an observation as this is a problem we have hit a few times with > the customization mechanism. The placement of the custom includes ( eg > IncludeCustomExtension macro) is generally dictated by the custom > extension you are trying to accommodate. So including at the > start/end/middle of a file may work well for the related Oracle > extensions, but that doesn't necessarily generalize to other > customizations. I see this is partly addressed by using a "post" variant > of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) > which seems wrong as the default seems to be pre. > > Similarly the choice of replacing or updating variables is also being > dictated by the way the Oracle extension works. For example, in > > jdk/make/gendata/GendataBlacklistedCerts.gmk > > you have: > > GENDATA_BLACKLISTED_CERTS_SRC += > $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem > > which allows the variable to be extended. In contrast in > > jdk/make/gendata/GendataFontConfig.gmk > > you have: > > GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig > > which allows the variable to be replaced. > > There is no general solution here of course - how to replace/augment > depends on which operators are used and where the custom include > location is. > >> >> I have moved all Oracle specific mapfiles out of the open jdk repository. > > Ok. > > Some specific comments: > > jdk/make/lib/Awt2dLibraries.gmk > > You seem to have lost the ability to customise the libjavajpeg mapfile. > Is that just because it is not needed on the Oracle side? > > jdk/make/mapfiles/libfontmanager/mapfile-vers > > Would it be better to delete the above file and hg rename mapfile- > version instead? ... hg rename the mapfile-vers.openjdk version instead ... David > Thanks, > David > ----- > >> Specifically to 2d-dev reviewers, I have moved >> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >> of the open as well. This file has been explicitly excluded from all >> open builds since forever AFAICT. I see no reason for it be in the open. >> If someone would like to read the source outside of Oracle, it will >> still be in the hg history. >> >> I have tested these changes extensively using the compare script and >> -testset buildinfra in JPRT. This covers a wide variety of build >> configurations so I feel pretty confident that it won't break anything. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >> >> /Erik From david.holmes at oracle.com Mon Jul 4 01:17:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:17:09 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> Message-ID: <21448444-7a1e-7a31-5fe1-058f52704f75@oracle.com> On 4/07/2016 10:21 AM, Phil Race wrote: > > > -Phil. > >> On Jul 3, 2016, at 4:55 PM, Phil Race wrote: >> >> It is it all "extensions". > That should have read : > It is "not" all ... True but they are all customizations - so SUPPRESS_CUSTOMIZATIONS instead of SUPPRESS_CUSTOM_SOURCES ? David > - Phil > >> It is mostly just different internal code as far as we (se client) are concerned so the word extension has entirely the wrong connotation for people in SE api land. >> >> -Phil. >> >>> On Jul 3, 2016, at 4:01 PM, David Holmes wrote: >>> >>> Hi Erik, >>> >>>> On 2/07/2016 3:47 AM, Erik Joelsson wrote: >>>> The separation between OpenJDK and Oracle's closed additions have >>>> historically been quite messy. The build-infra project has tried to >>>> improve on this, but failed in one regard, which was to hard code all >>>> references to "closed" source instead of using a variable. I decided to >>>> finally fix this. >>> >>> Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. >>> >>> That said there are still issues with trying to provide a mechanism for other customizations to use - more below. >>> >>>> Along the way, I found that there weren't that many >>>> references left in open makefiles, which is a good thing. OpenJDK should >>>> not be tainted with Oracle specific stuff unnecessarily. So then I >>>> decided to completely remove the last references as part of fixing this >>>> bug. With this patch, the following is now in effect: >>>> >>>> * There is no longer a variable named "OPENJDK". That variable was >>>> confusing and got in the way of other people trying to add custom >>>> additions to the OpenJDK code base. In configure there is now only >>>> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >>>> option. This variable can be read by custom extensions to configure and >>>> should be used to disable those custom extensions. >>> >>> Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >>> >>>> * There is no Oracle specific logic left in open makefiles. All >>>> customizations and references to custom source should be done in custom >>>> makefiles, included using the IncludeCustomExtension macro. I have >>>> converted the last uses of "ifndef OPENJDK" to such constructs. >>> >>> Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. >>> >>> Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in >>> >>> jdk/make/gendata/GendataBlacklistedCerts.gmk >>> >>> you have: >>> >>> GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >>> >>> which allows the variable to be extended. In contrast in >>> >>> jdk/make/gendata/GendataFontConfig.gmk >>> >>> you have: >>> >>> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >>> >>> which allows the variable to be replaced. >>> >>> There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. >>> >>>> >>>> I have moved all Oracle specific mapfiles out of the open jdk repository. >>> >>> Ok. >>> >>> Some specific comments: >>> >>> jdk/make/lib/Awt2dLibraries.gmk >>> >>> You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? >>> >>> jdk/make/mapfiles/libfontmanager/mapfile-vers >>> >>> Would it be better to delete the above file and hg rename mapfile- version instead? >>> >>> Thanks, >>> David >>> ----- >>> >>>> Specifically to 2d-dev reviewers, I have moved >>>> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >>>> of the open as well. This file has been explicitly excluded from all >>>> open builds since forever AFAICT. I see no reason for it be in the open. >>>> If someone would like to read the source outside of Oracle, it will >>>> still be in the hg history. >>>> >>>> I have tested these changes extensively using the compare script and >>>> -testset buildinfra in JPRT. This covers a wide variety of build >>>> configurations so I feel pretty confident that it won't break anything. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >>>> >>>> /Erik >> > From goetz.lindenmaier at sap.com Mon Jul 4 06:32:56 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Jul 2016 06:32:56 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8160721: Avoid deoptimizations in Font.equals. In-Reply-To: <74fd6cc4-b30d-48ce-7bea-16cc08b885b9@oracle.com> References: <74fd6cc4-b30d-48ce-7bea-16cc08b885b9@oracle.com> Message-ID: Hi, Resending this to 2d-dev. Also, I made a new webrev considering Remi's comments: http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/webrev.02/ Best regards, Goetz. > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Freitag, 1. Juli 2016 19:35 > To: Lindenmaier, Goetz ; awt- > dev at openjdk.java.net > Subject: Re: RFR(XS): 8160721: Avoid deoptimizations in > Font.equals. > > Please resend this to 2d-dev. All font related API and implementation > is part of 2D, not AWT. > > -phil. > > On 7/1/2016 6:59 AM, Lindenmaier, Goetz wrote: > > > > Hi, > > > > This small fix improves performance of the C2 compiler. > > > > We see deoptimizations due to class casts in Font.equals. > > Use instanceof check instead of catching the exception. > > > > Please review this change: > > > > http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/ > > > > > > Best regards, > > > > Goetz. > > From Sergey.Bylokhov at oracle.com Mon Jul 4 08:12:47 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 4 Jul 2016 11:12:47 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <5775AFF8.5060006@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> <5775AFF8.5060006@oracle.com> Message-ID: On 01.07.16 2:49, Jim Graham wrote: > How is it returning true? If the clip really is empty, then > intersectsQuickCheck() should never return true. Or are you saying that > an empty clip shape produces a non-empty composite clip region? This code will test such situation: BufferedImage bi = new BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); Graphics2D graphics = bi.createGraphics(); graphics.scale(1.5, 1.5); graphics.setClip(1, 1, 0, 0); System.out.println("empty = " + graphics.getClip().getBounds2D().isEmpty()); boolean hit = graphics.hitClip(1, 1, 1, 1); System.out.println("hit = " + hit); if "graphics.scale(1.5, 1.5);" will be removed then correct false will be printed. In both cases the clip will be empty but hitCLip will return different result in case of scaled SG2D. > > ...jim > > On 06/30/2016 10:02 AM, Sergey Bylokhov wrote: >> It looks strange that the empty clip became "non-empty"(at least hitClip >> reports this) when we apply transform to it, no? I guess that at the >> beginning of hitClip() we should check that the clip.isEmpty(), and we >> should return "false" in this case(I think this is not strictly related >> to this bug)? >> >> On 24.06.16 1:14, Jim Graham wrote: >>> Think of this method as asking: >>> >>> I don't want you to waste a lot of time, but tell me if it is silly for >>> me to even consider rendering something with these bounds. >>> >>> And the answer is either "Oh, yeah, it is inconceivable that those >>> bounds would be rendered", or "Not sure, maybe, just render it and >>> see". There may be some cases where it knows "I know for sure that lots >>> of stuff will render through the clip", but that is not where the >>> divining line is here in terms of when the answer becomes true - it >>> becomes true when there is a chance that it might render something. >>> >>> Arguably, the user-space comparison against the user-space clip that you >>> added here can never be accurate even if you allow for "false >>> positives". The clip is rasterized and whole pixels are chosen based on >>> various criteria that affect clip rasterization. Thus, while the >>> theoretical clip is at N.5, our rasterization choice has us render >>> anything that hits pixel N, even if the contribution of the rendered >>> primitive is only for the first half of N. That pixel might be rendered >>> if anything hits any part of it, depending on what rendering operation >>> is being done. >>> >>> So, your "fix" actually breaks the functionality because it is quite >>> possible that something with a bounding box that stops before N.5 might >>> affect pixel N and cause it to be rendered even though your new answer >>> suggested that it wouldn't happen. Your code might actually cause a >>> bug, not fix one. >>> >>> (There are also some potential theoretical failures related to how AA >>> and STROKE_CONTROL might perturb our rendering, effects which are ignore >>> by the current implementation of hitClip(), however I believe that all >>> of those effects fit within the current implementation - it's just that >>> I don't think anyone has ever proven this, or written an exhaustive test >>> suite to verify that none of our rendering hints can perturb rendering >>> by enough to create some surprises here...) >>> >>> ...jim >>> >>> On 6/23/16 3:00 PM, Jim Graham wrote: >>>> Since "return true" would be a compliant implementation of >>>> Graphics.hitClip(), this is not a bug... >>>> >>>> Read the documentation, it is allowed to use fast math that can return >>>> true when technically the answer is false... >>>> >>>> ...jim >>>> >>>> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>>>> >>>>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and >>>>> call the hitClip() with the passed rectangle [x=0, >>>>> y=0, width=5, height=5]. >>>>> >>>>> The result is false for the graphics with scale 1 and true if the >>>>> scale is floating point 1.5. >>>>> >>>>> This is because the transformed clip which has floating point >>>>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>>>> with rounded down upper-left and rounded up lower-right corners [7, >>>>> 7, 8, 8] which now intersects with the transformed >>>>> rectangle [0, 0, 7.5, 7.5]. >>>>> >>>>> The proposed fix adds additional check for the user clip and the >>>>> user rectangle intersection if the intersection with >>>>> the region clip passes. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >> >> -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Mon Jul 4 09:43:12 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 4 Jul 2016 09:43:12 +0000 (UTC) Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <577402C7.6040505@oracle.com> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> <577402C7.6040505@oracle.com> Message-ID: <205fd1cb-2765-44b1-a905-5b722bf99c96@default> Hello Everyone Good day to you. A quick follow-up on the fix for Bug ID : JDK-8152971 Title : -Xcheck:jni - WARNING in native method Thanks to Phil for his feedback. The feedback was not only detailed.. but contained important links for reference. I 've incorporated the review suggestions and have updated the webrev. Brief on changes from previous revision: 1. Once an exception has been found in an Up-call, the exception is ' not ' consumed or cleared now. . As Phil rightly said, this will pave way for the Java methods to know of the exceptions and handle them. 2. In addition to point No.1, The GDI's callback functions return zero '0' during an exception. . This will stop the subsequent enumeration of fonts & calls to registered callbacks through the APIs 3. Since exceptions are not consumed, all GDI 's callback functions are checked for pending exceptions at the entry. . On pending exceptions, the GDI's callback functions return immediately. . This prevents the functions from invoking any other JNI calls that could be un-safe during a pending exception . The callback functions merely release any local reference held before returning to caller. 4. Since we no longer support Win98, the obsolete ANSI versions of functions (~A functions) have been removed. . Functions that work with Unicode strings invoking Unicode versions of Windows APIs (~W functions) are retained. 5. The jtreg shell script has been modified to execute on all platforms after testing its execution on Windows, Linux, Mac and SunOS. . Just to re-iterate: The jtreg script fails on windows and solaris but in java.lang codebase. . A bug is already Open indicating JNI warnings in java.lang package. Hence this change does not introduce any new issues. As with any proposed webrev: . The changes were run through internal build system to ensure safe build on all supported OS versions. . JCK and JTREG test cases were run to ensure no conformance or regression failures occur. Kindly review the changes at your convenience and provide your feedback. . Updated webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.03/ Thank you for your time & effort in review Have a good day Prahalad N. ---------------------------------------------------------------------------- From: Philip Race Sent: Wednesday, June 29, 2016 10:48 PM To: Prasanta Sadhukhan Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Jayathirth D V; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#exception_handling lists DeleteLocalRef as safe to call with a pending exception. So here ... 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, 175 fmi->toLowerCaseMID, fmi->locale); 176 if ((*env)->ExceptionCheck(env)) { 177 (*env)->ExceptionClear(env); 178 /* Delete the created references */ 179 DeleteLocalReference(env, fullname); 180 return 1; 181 } ... perhaps what we should do is not clear the exception and with the goal that after returning from this function we can check in the caller for a pending exception and return from JNI to Java *without clearing it* - so that Java code gets that exception propagated. I suggest this because I think we would have a correctness issue which should be reported - not swallowed - if there ever really was one. I think this means that the GDI callbacks need to check for a pending exception on entry and bail since once we hand off to windows it may be called repeatedly. But also we should stop enumeration if we detect an error hence we should return 0 in this case, not 1 per the docs for EnumFontFamExProc --- https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs.85).aspx Return value The return value must be a nonzero value to continue enumeration; ?to stop enumeration, the return value must be zero. --- Also the "A" functions are now obsolete. No win 98 support any more :-) We should just delete them instead of updating them. And I'd prefer the test be verified on Solaris rather than excluding it -phil On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: Looks good to me. Only thing is in test script, you need to add copyright 2015, 2016 as the script is originally written in 2015 and you cannot omit the created year from the copyright. Regards Prasanta On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: Hello Everyone Good day to you. Quick follow up to fix for the Bug ?????? Bug ID???? : JDK-8152971 ?????? Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 First, Thanks to Prasanta for his review & suggestions. I 've incorporated some of the review suggestions & updated the webrev. ????? Webrev Link : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ Overview on changes from previous webrev: 1. Code Changes: As Prasanta mentioned, ?????????? The variable fontStrLC should be used in place of fontStr - The correction has been taken up. ?????????? And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. 2. With regard to deleting references held within GdiFontMapInfo struture ????????? JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass ????????? The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. ????????? Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. ??????????????? The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. ??????????????? As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. ??????????????? Hence enabling the script on windows, doesn't introduce new bug. ????????? The only OS that the script doesn't run - Solaris. ??????????????? Presently, we don't have a Solaris environment at our facility to test the script. ??????????????? Hence the original functionality on Solaris is retained. Kindly take a look at the changes at your convenience & provide the suggestions. Thank you for your review Have a good day Prahalad N. ---------------------------------------------------------------------------- From: Prasanta Sadhukhan Sent: Monday, June 27, 2016 11:51 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Cc: Philip Race; Jayathirth D V; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni I guess this method(s) should take "fontStrLC" instead of "fontStr" 650???????????? (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, ? 651????????????????????????????????????? fontStr, fileStr); ? 692???????? (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, ? 693????????????????????????????????? fontStr, fileStr); 762???????????? (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, ? 763????????????????????????????????????? fontStr, fileStr); 805???????? (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, ? 806????????????????????????????????? fontStr, fileStr); It seems this line is not needed as we have not populated fmi structure yet. 882???????? releaseGdiFontMapReferences(env, &fmi); Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID? in releaseGdiFontMapReferences()? Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. Is there any particular need to restrict solaris too? Regards Prasanta On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: Hello Everyone on Java2D Forum Good day to you. A Quick follow-up on webrev to fix the following issue ?????? Bug ID???? : JDK-8152971? / -Xcheck:jni - warning in native method ?????? Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 Updated webrev link:? http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ Description on Changes ?????? . The previous webrev contained changes to additional files which are not related to the current bug in concern. ?????? . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. Regarding Build & Test ?????? . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. ?????? . In addition, no new Jtreg failures were found with the proposed changes. Kindly review the changes at your convenience & provide your feedback. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Prahalad Kumar Narayanan Sent: Wednesday, June 22, 2016 3:20 PM To: 2d-dev at openjdk.java.net Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni Hello Everyone, on Java2D Group Good day to you. Please find herewith, webrev changes to fix the bug- ?????? Bug ID???? : JDK-8152971? / -Xcheck:jni - warning in native method ?????? Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 ?????? Webrev : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ Description on Bug: ????? 1.? Too many JNI warnings are reported in the native functions when test-code is run with VM Option:? -Xcheck:jni ????? 2.? The warnings can be classified into 2 categories ????????????????? a.? JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) ????????????????? b.? JNI warnings that are thrown due to increased usage of Local Reference objects. Description on the Fix: ????? 1.? File : FontPath.c ??????????????????? Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. ??????????????????????????? The checks are added only to the valid Up calls as per JNI spec. ??????????????????? Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. ??????????????????????????? A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. ??????????????????????????? Therefore at each callback, the count of active local references would increase. ???????????????????????????????????? Over time, the active local references would exceed the planned number of local references set by JVM. ????? 2.? File : awt_Component.cpp ??????????????????? Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. ??????????????????? Information on Jtreg test script is given below. ????? 3.? File : LoadFontsJNICheck.sh ??????????????????? The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option ??????????????????? However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. ???????????????????????????????? This way, the code changes can be checked for proper execution with test-case. 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 Mon Jul 4 11:36:38 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 4 Jul 2016 11:36:38 +0000 (UTC) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified In-Reply-To: <5776B56F.7070007@oracle.com> References: <57710D96.8010808@oracle.com> <57740C8B.10609@oracle.com> <5774F4EB.7050806@oracle.com> <57759627.5010203@oracle.com> <57760973.7070900@oracle.com> <5776B56F.7070007@oracle.com> Message-ID: Hi Prasanta, ? Changes are working fine. ? Thanks, Jay ? From: Phil Race Sent: Friday, July 01, 2016 11:55 PM To: Prasanta Sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified ? +1? ... although I am a little nervous about FP error causing false results in some cases. -phil. On 06/30/2016 11:10 PM, Prasanta Sadhukhan wrote: Hi Phil, Right. I have rectified the calculation. Please find the modified webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6789262/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.02/ Regards Prasanta On 7/1/2016 3:29 AM, Phil Race wrote: Shouldn't these all be >= and <= ? Else (eg) for X==1 in both cases you would return false when it should be true .. f ((mpa.getX(units) > mediaPrintables[i].getX(units)) && -phil. On 06/30/2016 03:31 AM, Prasanta Sadhukhan wrote: Hi Phil, I modified the method to check for "fit" rather than perfect match as you suggested. Please find the modified webrev HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6789262/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.01/ Regards Prasanta On 6/29/2016 11:29 PM, Philip Race wrote: This is actually a little subtle. The check you are deleting has been there since 2000 .. and it can't just be removed. But it need adjusting. This is the subtlety. Most of the attribute checks are yes/no. I think for this one we need to look at the actual dimensions and return true if it is "fits" So isSupportedMediaPrintableArea needs to do more than "equals" I am not 100% sure that won't surprise some other code but as far as I can think right now it seems the right thing to do. -phil. On 6/27/16, 4:27 AM, Prasanta Sadhukhan wrote: Hi All, Please review a fix for an issue where it was found that setting left margin of 2" is ignored and when we query PrinterJob.job.getPageFormat(PrintRequestAttributeSet) we get the default paper mediapritable area of x=1" instead of the set 2". Bug: https://bugs.openjdk.java.net/browse/JDK-6789262 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6789262/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.00/ This is because it was found that getPageFormat() calls Win32PrintService#isAttributeValueSupported() where we call isSupportedMediaPrintableArea() to check if the mediaprintable area is matching with the media size that has been cached. It gets the paperID by calling findPaperID() and stores the mpa of that paper in MediaPrintableArea[] I see that my printer supports 43 mediasize names (like iso_a4, iso_a5, na_letter etc) and none of the 43 mediaPrintables equals the mpa value of (50.4, 25.4, 133.8, 246.2)mm ---------------isSupportedMediaPrintableArea()--------- if (mediaPrintables != null) { ??????????? for (int i=0; i From prasanta.sadhukhan at oracle.com Tue Jul 5 05:22:02 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Jul 2016 10:52:02 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 4987884: PrinterJob carries over some values between calls to print. Message-ID: <577B43FA.5080009@oracle.com> Hi All, Please review a fix whereby it is seen that the PageRanges attribute passed to 1st print() call is inadvertently been carried forward to 2nd print if some program tries calling in this sequence ---------- /PrinterJob pj = PrinterJob.getPrinterJob();// //pj.setPageable(..)// //pj.print(..)// //pj.setPageable(..)// //pj.print(..) ------------ / Bug: https://bugs.openjdk.java.net/browse/JDK-4987884/ /webrev: http://cr.openjdk.java.net/~psadhukhan/4987884/webrev.00// /This is because no-args print() uses an internal attribute set which is presumed to carry over information not supplied by the client directly but created during a call to no-args printDialog() or during call to setPrintable() called via setAttributes(). but it apparently seems, we should not be remembering PageRange attribute between calls to print() as it will result in wrong page numbers being printed. Proposed fix to remove the PageRanges attribute from no-args print() between print() calls. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Jul 5 06:44:35 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jul 2016 08:44:35 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> Message-ID: <577B5753.9030807@oracle.com> Hello, New webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.02/ Only change is the name of the suppress variable. On 2016-07-04 03:02, David Holmes wrote: > Fix typo ... > > On 4/07/2016 9:01 AM, David Holmes wrote: >> Hi Erik, >> >> Only nit with that is the "source" tend to imply source code and of >> course this "source" can be quite a range of artifacts. >> SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >> I went with this suggestion as I like it better. >>> * There is no Oracle specific logic left in open makefiles. All >>> customizations and references to custom source should be done in custom >>> makefiles, included using the IncludeCustomExtension macro. I have >>> converted the last uses of "ifndef OPENJDK" to such constructs. >> >> Just an observation as this is a problem we have hit a few times with >> the customization mechanism. The placement of the custom includes ( eg >> IncludeCustomExtension macro) is generally dictated by the custom >> extension you are trying to accommodate. So including at the >> start/end/middle of a file may work well for the related Oracle >> extensions, but that doesn't necessarily generalize to other >> customizations. I see this is partly addressed by using a "post" variant >> of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) >> which seems wrong as the default seems to be pre. >> >> Similarly the choice of replacing or updating variables is also being >> dictated by the way the Oracle extension works. For example, in >> >> jdk/make/gendata/GendataBlacklistedCerts.gmk >> >> you have: >> >> GENDATA_BLACKLISTED_CERTS_SRC += >> $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >> >> which allows the variable to be extended. In contrast in >> >> jdk/make/gendata/GendataFontConfig.gmk >> >> you have: >> >> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >> >> which allows the variable to be replaced. >> >> There is no general solution here of course - how to replace/augment >> depends on which operators are used and where the custom include >> location is. >> This is all true. Different places have required different ways of overriding, appending or prepending with customizations. I will likely take another look at this and see if I can clean it up some at least. Perhaps unify the pre/post semantics. At least now we have captured all the current needs for customizations and gained some experience in what kind of constructs are needed. >>> >>> I have moved all Oracle specific mapfiles out of the open jdk >>> repository. >> >> Ok. >> >> Some specific comments: >> >> jdk/make/lib/Awt2dLibraries.gmk >> >> You seem to have lost the ability to customise the libjavajpeg mapfile. >> Is that just because it is not needed on the Oracle side? >> >> jdk/make/mapfiles/libfontmanager/mapfile-vers >> >> Would it be better to delete the above file and hg rename mapfile- >> version instead? > > ... hg rename the mapfile-vers.openjdk version instead ... > They are identical, which is why I just removed the logic. Historically there has been a difference but it was removed. Regarding which file we should save the history for, I'm not sure which is best. Delete-rename to the same file name can be confusing too. /Erik From david.holmes at oracle.com Tue Jul 5 07:42:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jul 2016 17:42:24 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <577B5753.9030807@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> <577B5753.9030807@oracle.com> Message-ID: <12bad63c-91c1-2cc4-69fd-2150ed54f164@oracle.com> No further comments from me Erik! Looks good. Thanks, David On 5/07/2016 4:44 PM, Erik Joelsson wrote: > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.02/ > > Only change is the name of the suppress variable. > > On 2016-07-04 03:02, David Holmes wrote: >> Fix typo ... >> >> On 4/07/2016 9:01 AM, David Holmes wrote: >>> Hi Erik, >>> >>> Only nit with that is the "source" tend to imply source code and of >>> course this "source" can be quite a range of artifacts. >>> SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >>> > I went with this suggestion as I like it better. >>>> * There is no Oracle specific logic left in open makefiles. All >>>> customizations and references to custom source should be done in custom >>>> makefiles, included using the IncludeCustomExtension macro. I have >>>> converted the last uses of "ifndef OPENJDK" to such constructs. >>> >>> Just an observation as this is a problem we have hit a few times with >>> the customization mechanism. The placement of the custom includes ( eg >>> IncludeCustomExtension macro) is generally dictated by the custom >>> extension you are trying to accommodate. So including at the >>> start/end/middle of a file may work well for the related Oracle >>> extensions, but that doesn't necessarily generalize to other >>> customizations. I see this is partly addressed by using a "post" variant >>> of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) >>> which seems wrong as the default seems to be pre. >>> >>> Similarly the choice of replacing or updating variables is also being >>> dictated by the way the Oracle extension works. For example, in >>> >>> jdk/make/gendata/GendataBlacklistedCerts.gmk >>> >>> you have: >>> >>> GENDATA_BLACKLISTED_CERTS_SRC += >>> $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >>> >>> which allows the variable to be extended. In contrast in >>> >>> jdk/make/gendata/GendataFontConfig.gmk >>> >>> you have: >>> >>> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >>> >>> which allows the variable to be replaced. >>> >>> There is no general solution here of course - how to replace/augment >>> depends on which operators are used and where the custom include >>> location is. >>> > This is all true. Different places have required different ways of > overriding, appending or prepending with customizations. I will likely > take another look at this and see if I can clean it up some at least. > Perhaps unify the pre/post semantics. At least now we have captured all > the current needs for customizations and gained some experience in what > kind of constructs are needed. >>>> >>>> I have moved all Oracle specific mapfiles out of the open jdk >>>> repository. >>> >>> Ok. >>> >>> Some specific comments: >>> >>> jdk/make/lib/Awt2dLibraries.gmk >>> >>> You seem to have lost the ability to customise the libjavajpeg mapfile. >>> Is that just because it is not needed on the Oracle side? >>> >>> jdk/make/mapfiles/libfontmanager/mapfile-vers >>> >>> Would it be better to delete the above file and hg rename mapfile- >>> version instead? >> >> ... hg rename the mapfile-vers.openjdk version instead ... >> > They are identical, which is why I just removed the logic. Historically > there has been a difference but it was removed. Regarding which file we > should save the history for, I'm not sure which is best. Delete-rename > to the same file name can be confusing too. > > /Erik > From prasanta.sadhukhan at oracle.com Tue Jul 5 09:08:47 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Jul 2016 14:38:47 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs Message-ID: <577B791F.4020900@oracle.com> Hi All, Please review a fix for an issue where it is seen "Page range (From/To) " field is not disabled for flavors such as postscript, image flavors. PageRanges attribute is supported only for Service Formatted flavors such as Pageable and Printable and so for other flavors such as postscript, image flavors page ranges fields must be disabled on the print dialog so as not to allow the user to select the same Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ Proposed fix is to check for attribute against the specified doc flavor and not against attribute category to decide whether to enable / disable it. Regards Prasanta From ajit.ghaisas at oracle.com Tue Jul 5 11:42:48 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 5 Jul 2016 04:42:48 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() In-Reply-To: <5775AE95.5070302@oracle.com> References: <5775AE95.5070302@oracle.com> Message-ID: Thanks Jim for suggesting test should have its own VM. I agree with it. Here is the updated webrev : http://cr.openjdk.java.net/~aghaisas/8160421/webrev.01/ Phil, can you please review it? Regards, Ajit -----Original Message----- From: Jim Graham Sent: Friday, July 01, 2016 5:13 AM To: Ajit Ghaisas; Philip Race; Sergey Bylokhov; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() The solution looks fine to me. I didn't run the test case, but about the only issue I can see with it is whether it should have a flag to run it in its own VM because of its interaction with System.err. Phil? ...jim On 06/30/2016 06:41 AM, Ajit Ghaisas wrote: > Hi, > > Bug : > This is regarding a NPE getting printed as stacktrace in java.awt.Toolkit.createCustomCursor() method. > The bug is described at : > https://bugs.openjdk.java.net/browse/JDK-8160421 > > Root Cause : > Fix of bug JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7. > The above fix added a RuntimeException catch & log mechanism to support a ImageFilter which was broken due to the second imageComplete() call in OffScreenImageSource.produce() method. > > Analysis: > Without the fix of JDK-8139192, java.awt.Toolkit.createCustomCursor() call results in > NullPointerException when imageComplete(ImageConsumer.STATICIMAGEDONE) call is made - but, it gets consumed silently. > Cathing RuntimeException() out of imageComplete(ImageConsumer.STATICIMAGEDONE) was added to fix JDK-8160421. > This started catching & logging the exception in case 'theConsumer' has unregistered itself as a result of call > theConsumer.imageComplete(ImageConsumer.SINGLEFRAMEDONE); > This log is undesirable as this mechanism is used in java.awt.Toolkit.createCustomCursor() and may be in other places. > > Fix : > Make the call to imageComplete(ImageConsumer.STATICIMAGEDONE) only if 'theConsumer' has not been unregistered. > > Webrev: > http://cr.openjdk.java.net/~aghaisas/8160421/webrev.00/ > > Request you to review. > > Regards, > Ajit > From philip.race at oracle.com Tue Jul 5 19:18:28 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 05 Jul 2016 12:18:28 -0700 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() In-Reply-To: References: <5775AE95.5070302@oracle.com> Message-ID: <577C0804.20908@oracle.com> I prefer meaningful test names .. the bug id is already in the @bug tag and a test can later be updated to test > 1 bug. Did you verify that you are in fact capturing stderr - even in othervm mode - when running the test under jtreg ? Even when setting up a new VM jtreg may capture this for you. -phil. On 07/05/2016 04:42 AM, Ajit Ghaisas wrote: > Thanks Jim for suggesting test should have its own VM. I agree with it. > > Here is the updated webrev : > http://cr.openjdk.java.net/~aghaisas/8160421/webrev.01/ > > Phil, can you please review it? > > Regards, > Ajit > > > -----Original Message----- > From: Jim Graham > Sent: Friday, July 01, 2016 5:13 AM > To: Ajit Ghaisas; Philip Race; Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() > > The solution looks fine to me. > > I didn't run the test case, but about the only issue I can see with it is whether it should have a flag to run it in its own VM because of its interaction with System.err. Phil? > > ...jim > > On 06/30/2016 06:41 AM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> This is regarding a NPE getting printed as stacktrace in java.awt.Toolkit.createCustomCursor() method. >> The bug is described at : >> https://bugs.openjdk.java.net/browse/JDK-8160421 >> >> Root Cause : >> Fix of bug JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7. >> The above fix added a RuntimeException catch & log mechanism to support a ImageFilter which was broken due to the second imageComplete() call in OffScreenImageSource.produce() method. >> >> Analysis: >> Without the fix of JDK-8139192, java.awt.Toolkit.createCustomCursor() call results in >> NullPointerException when imageComplete(ImageConsumer.STATICIMAGEDONE) call is made - but, it gets consumed silently. >> Cathing RuntimeException() out of imageComplete(ImageConsumer.STATICIMAGEDONE) was added to fix JDK-8160421. >> This started catching & logging the exception in case 'theConsumer' has unregistered itself as a result of call >> theConsumer.imageComplete(ImageConsumer.SINGLEFRAMEDONE); >> This log is undesirable as this mechanism is used in java.awt.Toolkit.createCustomCursor() and may be in other places. >> >> Fix : >> Make the call to imageComplete(ImageConsumer.STATICIMAGEDONE) only if 'theConsumer' has not been unregistered. >> >> Webrev: >> http://cr.openjdk.java.net/~aghaisas/8160421/webrev.00/ >> >> Request you to review. >> >> Regards, >> Ajit >> From philip.race at oracle.com Tue Jul 5 20:31:36 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 05 Jul 2016 13:31:36 -0700 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> Message-ID: <577C1928.4020803@oracle.com> It is not always clear to me what warning is being suppressed and why you have chosen a particular solution/action this next one looks like it might introduce an unused variable warning. What was it solving ? That the code was not checking a return value ? size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); //bytesWritten is unused Isn't the compiler's point here that you *should* be doing something with the result? Not just ignoring it differently ... ----- and this one ? I want Semyon to comment on what this code is trying to do in its original form since it was added for GTK3. @@ -1989,11 +2029,7 @@ static guint8 recode_color(gdouble channel) { guint16 result = (guint16)(channel * 65535); - if (result < 0) { - result = 0; - } else if (result > 65535) { - result = 65535; - } + return (guint8)( result >> 8); } ----- -phil. On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: > Hi, > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8074824 > (Resolve disabled warnings for libawt_xawt) > > As part of fixing this bug, I have - > > 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. > > 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. > > 3. Added comments in makefile for the warning suppression that cannot be fixed. > > One type of gcc warning 'deprecated-declarations' will be fixed separately (as part of JDK-8160146) > > > I have built the changes successfully on all supported platforms. > > > Webrev : > http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ > > Request you to review. > > Regards, > Ajit From alexey.ushakov at jetbrains.com Wed Jul 6 12:22:38 2016 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Wed, 6 Jul 2016 15:22:38 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8147542 Linux: ClassCastException when repainting after display resolution change Message-ID: <1D7CBE9A-9FE3-4D4E-AA0B-F0303316976D@jetbrains.com> Hello Phil and Sergey, There is one more slightly different issue causing CCE in blit code. It happens quite often in IDEA. After looking through JBS I?ve found that the problem is still relevant for all current releases. Here is the fix that I?ve marked with the most recent JBS issue that we have for some time in our custom OpenJDK based runtime. Please have a look. Bug: https://bugs.openjdk.java.net/browse/JDK-8147542 Webrev: http://cr.openjdk.java.net/~avu/JDK-8147542/webrev.00 Best Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Jul 7 04:52:58 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 7 Jul 2016 04:52:58 +0000 (UTC) Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() In-Reply-To: <577C0804.20908@oracle.com> References: <5775AE95.5070302@oracle.com> <577C0804.20908@oracle.com> Message-ID: Thanks for the review. I have corrected the test case name as per suggestion. Here is the updated webrev. http://cr.openjdk.java.net/~aghaisas/8160421/webrev.02/ Yes, the test captures the redirected contents of stderr correctly when run using jtreg - both with or without othervm specified. Regards, Ajit -----Original Message----- From: Phil Race Sent: Wednesday, July 06, 2016 12:48 AM To: Ajit Ghaisas Cc: Jim Graham; Sergey Bylokhov; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() I prefer meaningful test names .. the bug id is already in the @bug tag and a test can later be updated to test > 1 bug. Did you verify that you are in fact capturing stderr - even in othervm mode - when running the test under jtreg ? Even when setting up a new VM jtreg may capture this for you. -phil. On 07/05/2016 04:42 AM, Ajit Ghaisas wrote: > Thanks Jim for suggesting test should have its own VM. I agree with it. > > Here is the updated webrev : > http://cr.openjdk.java.net/~aghaisas/8160421/webrev.01/ > > Phil, can you please review it? > > Regards, > Ajit > > > -----Original Message----- > From: Jim Graham > Sent: Friday, July 01, 2016 5:13 AM > To: Ajit Ghaisas; Philip Race; Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: > JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() > > The solution looks fine to me. > > I didn't run the test case, but about the only issue I can see with it is whether it should have a flag to run it in its own VM because of its interaction with System.err. Phil? > > ...jim > > On 06/30/2016 06:41 AM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> This is regarding a NPE getting printed as stacktrace in java.awt.Toolkit.createCustomCursor() method. >> The bug is described at : >> https://bugs.openjdk.java.net/browse/JDK-8160421 >> >> Root Cause : >> Fix of bug JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7. >> The above fix added a RuntimeException catch & log mechanism to support a ImageFilter which was broken due to the second imageComplete() call in OffScreenImageSource.produce() method. >> >> Analysis: >> Without the fix of JDK-8139192, java.awt.Toolkit.createCustomCursor() call results in >> NullPointerException when imageComplete(ImageConsumer.STATICIMAGEDONE) call is made - but, it gets consumed silently. >> Cathing RuntimeException() out of imageComplete(ImageConsumer.STATICIMAGEDONE) was added to fix JDK-8160421. >> This started catching & logging the exception in case 'theConsumer' has unregistered itself as a result of call >> theConsumer.imageComplete(ImageConsumer.SINGLEFRAMEDONE); >> This log is undesirable as this mechanism is used in java.awt.Toolkit.createCustomCursor() and may be in other places. >> >> Fix : >> Make the call to imageComplete(ImageConsumer.STATICIMAGEDONE) only if 'theConsumer' has not been unregistered. >> >> Webrev: >> http://cr.openjdk.java.net/~aghaisas/8160421/webrev.00/ >> >> Request you to review. >> >> Regards, >> Ajit >> From goetz.lindenmaier at sap.com Thu Jul 7 07:04:31 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Jul 2016 07:04:31 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8160721: Avoid deoptimizations in Font.equals. References: <74fd6cc4-b30d-48ce-7bea-16cc08b885b9@oracle.com> Message-ID: Hi, can I consider this reviewed? Remi Forax and Phil Race had a look at this. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 4. Juli 2016 08:33 > To: 'Phil Race' ; awt-dev at openjdk.java.net; 2d-dev > <2d-dev at openjdk.java.net> > Subject: RE: RFR(XS): 8160721: Avoid deoptimizations in > Font.equals. > > Hi, > > Resending this to 2d-dev. > > Also, I made a new webrev considering Remi's comments: > http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/webrev.02/ > > Best regards, > Goetz. > > > > -----Original Message----- > > From: Phil Race [mailto:philip.race at oracle.com] > > Sent: Freitag, 1. Juli 2016 19:35 > > To: Lindenmaier, Goetz ; awt- > > dev at openjdk.java.net > > Subject: Re: RFR(XS): 8160721: Avoid deoptimizations in > > Font.equals. > > > > Please resend this to 2d-dev. All font related API and implementation > > is part of 2D, not AWT. > > > > -phil. > > > > On 7/1/2016 6:59 AM, Lindenmaier, Goetz wrote: > > > > > > Hi, > > > > > > This small fix improves performance of the C2 compiler. > > > > > > We see deoptimizations due to class casts in Font.equals. > > > Use instanceof check instead of catching the exception. > > > > > > Please review this change: > > > > > > http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/ > > > > > > > > > Best regards, > > > > > > Goetz. > > > From prasanta.sadhukhan at oracle.com Thu Jul 7 10:58:47 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 7 Jul 2016 16:28:47 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-5080830: SheetCollate is not handled properly by the cross platform print dlg Message-ID: <577E35E7.3030408@oracle.com> Hi All, Please review a fix for an issue where it is seen that SheetCollate option is enabled for flavors that do not support SheetCollate. Bug: https://bugs.openjdk.java.net/browse/JDK-5080830 webrev: http://cr.openjdk.java.net/~psadhukhan/5080830/webrev.00/ Proposed fix to check for isAttributeValueSupported() to decide whether to enable the SheetCollate option or not. Regards Prasanta From jayathirth.d.v at oracle.com Thu Jul 7 11:38:48 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 7 Jul 2016 11:38:48 +0000 (UTC) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Message-ID: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> Hi, Please review the following fix in JDK9 : Bug : https://bugs.openjdk.java.net/browse/JDK-7059970 Webrev : http://cr.openjdk.java.net/~jdv/7059970/webrev.00/ Root cause : Test case ITXtTest.java is not deleting the file it is creating(test.png). Also it is not closing ImageInputStream that it is creating in between. Fix : Close the stream and file that is used in the test case with tighter checks. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jul 7 15:01:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Jul 2016 15:01:15 +0000 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. Message-ID: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> Hi, This change is 'L' because there are changes to a lot of files, but the changes are all similar, so it's rather easy to review. Similar to 8159690 I added @key headful to another around 600 tests. I used different patterns to grep for the headful exceptions. These are now all I could find with grepping and the like. I have around 80 failing tests remaining, where a row will probably also depend on a display, but I want to look at them more closely, so I don't want to include them here. Please review this change: http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Jul 7 16:48:35 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 7 Jul 2016 16:48:35 +0000 (UTC) Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <577C1928.4020803@oracle.com> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> <577C1928.4020803@oracle.com> Message-ID: <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> Thanks Phil for the review. Please find my answers below. Semyon, can you please comment on Phil's question below? Regards, Ajit -----Original Message----- From: Phil Race Sent: Wednesday, July 06, 2016 2:02 AM To: Ajit Ghaisas Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-dev at openjdk.java.net; build-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt It is not always clear to me what warning is being suppressed and why you have chosen a particular solution/action this next one looks like it might introduce an unused variable warning. What was it solving ? That the code was not checking a return value ? size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); //bytesWritten is unused Isn't the compiler's point here that you *should* be doing something with the result? Not just ignoring it differently ... ---------------------------------------------- [Ajit] : there was a warning of type 'unused-result' for write() method. Now, I have just assigned that to a variable which fixes the warning. I think, we should have some code to do error check on bytesWritten and return it - but it is out of purview of this fix as it may introduce behavioral change. ---------------------------------------------- ----- and this one ? I want Semyon to comment on what this code is trying to do in its original form since it was added for GTK3. @@ -1989,11 +2029,7 @@ static guint8 recode_color(gdouble channel) { guint16 result = (guint16)(channel * 65535); - if (result < 0) { - result = 0; - } else if (result > 65535) { - result = 65535; - } + return (guint8)( result >> 8); } ----------------------------------------------------- [Ajit] : there was a warning about guint16 will not be less than 0 and larger than 65535. Hence I have removed code checking this range. ----------------------------------------------------- ----- -phil. On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: > Hi, > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8074824 > (Resolve disabled warnings for libawt_xawt) > > As part of fixing this bug, I have - > > 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. > > 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. > > 3. Added comments in makefile for the warning suppression that cannot be fixed. > > One type of gcc warning 'deprecated-declarations' will be fixed > separately (as part of JDK-8160146) > > > I have built the changes successfully on all supported platforms. > > > Webrev : > http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ > > Request you to review. > > Regards, > Ajit From semyon.sadetsky at oracle.com Thu Jul 7 17:25:17 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 7 Jul 2016 20:25:17 +0300 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> <577C1928.4020803@oracle.com> <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> Message-ID: <320e423b-9183-16fb-ad8a-9b1e668729d2@oracle.com> On 7/7/2016 7:48 PM, Ajit Ghaisas wrote: > Thanks Phil for the review. > Please find my answers below. > > Semyon, can you please comment on Phil's question below? I agree with this change. The check is not needed. --Semyon > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Wednesday, July 06, 2016 2:02 AM > To: Ajit Ghaisas > Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-dev at openjdk.java.net; build-dev at openjdk.java.net > Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt > > It is not always clear to me what warning is being suppressed and why you have chosen a particular solution/action > > > this next one looks like it might introduce an unused variable warning. > What was it solving ? That the code was not checking a return value ? > > size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); //bytesWritten is unused > > Isn't the compiler's point here that you *should* be doing something with the result? > Not just ignoring it differently ... > > ---------------------------------------------- > [Ajit] : there was a warning of type 'unused-result' for write() method. Now, I have just assigned that to a variable which fixes the warning. > I think, we should have some code to do error check on bytesWritten and return it - but it is out of purview of this fix as it may introduce behavioral change. > ---------------------------------------------- > > ----- > > and this one ? I want Semyon to comment on what this code is trying to do in its original form since it was added for GTK3. > > @@ -1989,11 +2029,7 @@ > static guint8 recode_color(gdouble channel) > { > guint16 result = (guint16)(channel * 65535); > - if (result < 0) { > - result = 0; > - } else if (result > 65535) { > - result = 65535; > - } > + > return (guint8)( result >> 8); > } > > ----------------------------------------------------- > [Ajit] : there was a warning about guint16 will not be less than 0 and larger than 65535. Hence I have removed code checking this range. > ----------------------------------------------------- > > ----- > > > -phil. > > On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-8074824 >> (Resolve disabled warnings for libawt_xawt) >> >> As part of fixing this bug, I have - >> >> 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. >> >> 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. >> >> 3. Added comments in makefile for the warning suppression that cannot be fixed. >> >> One type of gcc warning 'deprecated-declarations' will be fixed >> separately (as part of JDK-8160146) >> >> >> I have built the changes successfully on all supported platforms. >> >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ >> >> Request you to review. >> >> Regards, >> Ajit From brian.burkhalter at oracle.com Thu Jul 7 17:41:55 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Jul 2016 10:41:55 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> Message-ID: <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> Why not simply invoke deleteOnExit() on the file instance immediately after it is created and use try-with-resources blocks for the Image{Input,Output}Stream instances? Brian On Jul 7, 2016, at 4:38 AM, Jayathirth D V wrote: > Please review the following fix in JDK9 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-7059970 > Webrev :http://cr.openjdk.java.net/~jdv/7059970/webrev.00/ > > Root cause : Test case ITXtTest.java is not deleting the file it is creating(test.png). Also it is not closing ImageInputStream that it is creating in between. > Fix : Close the stream and file that is used in the test case with tighter checks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 7 19:27:22 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Jul 2016 12:27:22 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> Message-ID: <577EAD1A.7020009@oracle.com> you need to add the new bug to @bug .. 197 imageWriter.write(new IIOImage(src, null, m)); 198 imageOutputStream.close(); <<< 199 System.out.println("Writing done."); 200 } catch (Throwable e) { 201 if (imageOutputStream != null) { <<<< 202 imageOutputStream.close(); 203 } 204 f.delete(); 205 throw new RuntimeException("Writin maybe use finally for this instead ? something like :- imageWriter.write(new IIOImage(src, null, m)) System.out.println("Writing done."); } finally { if(imageOutputStream != null) { imageOutputStream.close(); } f.delete(); } And perhaps the same can be don in doTest() for the file.delete() rather than having so many of these calls scattered around. -phil. On 07/07/2016 04:38 AM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-7059970 > > Webrev : http://cr.openjdk.java.net/~jdv/7059970/webrev.00/ > > > Root cause : Test case ITXtTest.java is not deleting the file it is > creating(test.png). Also it is not closing ImageInputStream that it is > creating in between. > > Fix : Close the stream and file that is used in the test case with > tighter checks. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 7 19:34:02 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Jul 2016 12:34:02 -0700 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <320e423b-9183-16fb-ad8a-9b1e668729d2@oracle.com> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> <577C1928.4020803@oracle.com> <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> <320e423b-9183-16fb-ad8a-9b1e668729d2@oracle.com> Message-ID: <577EAEAA.309@oracle.com> On 07/07/2016 10:25 AM, Semyon Sadetsky wrote: > On 7/7/2016 7:48 PM, Ajit Ghaisas wrote: > >> Thanks Phil for the review. >> Please find my answers below. >> >> Semyon, can you please comment on Phil's question below? > I agree with this change. The check is not needed. Ok. so the fix overall seems fine in that case although regarding >but it is out of purview of this fix as it may introduce behavioral change. I do not entirely buy it is out of purview I won't push any further on it for now but won't be surprised if someone else reports an unused variable warning. -phil. > > --Semyon >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Phil Race >> Sent: Wednesday, July 06, 2016 2:02 AM >> To: Ajit Ghaisas >> Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-dev at openjdk.java.net; >> build-dev at openjdk.java.net >> Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for >> libawt_xawt >> >> It is not always clear to me what warning is being suppressed and why >> you have chosen a particular solution/action >> >> >> this next one looks like it might introduce an unused variable warning. >> What was it solving ? That the code was not checking a return value ? >> >> size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> //bytesWritten is unused >> >> Isn't the compiler's point here that you *should* be doing something >> with the result? >> Not just ignoring it differently ... >> >> ---------------------------------------------- >> [Ajit] : there was a warning of type 'unused-result' for write() >> method. Now, I have just assigned that to a variable which fixes the >> warning. >> I think, we should have some code to do error check on bytesWritten >> and return it - but it is out of purview of this fix as it may >> introduce behavioral change. >> ---------------------------------------------- >> >> ----- >> >> and this one ? I want Semyon to comment on what this code is trying >> to do in its original form since it was added for GTK3. >> >> @@ -1989,11 +2029,7 @@ >> static guint8 recode_color(gdouble channel) >> { >> guint16 result = (guint16)(channel * 65535); >> - if (result < 0) { >> - result = 0; >> - } else if (result > 65535) { >> - result = 65535; >> - } >> + >> return (guint8)( result >> 8); >> } >> >> ----------------------------------------------------- >> [Ajit] : there was a warning about guint16 will not be less than 0 >> and larger than 65535. Hence I have removed code checking this range. >> ----------------------------------------------------- >> >> ----- >> >> >> -phil. >> >> On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : >>> https://bugs.openjdk.java.net/browse/JDK-8074824 >>> (Resolve disabled warnings for libawt_xawt) >>> >>> As part of fixing this bug, I have - >>> >>> 1. Fixed warnings in source code after removing blanket >>> warning suppressions from makefile. >>> >>> 2. In case the warning fix is not possible, converted blanket >>> warning suppression for this library to suppression of warnings for >>> individual files. >>> >>> 3. Added comments in makefile for the warning suppression that >>> cannot be fixed. >>> >>> One type of gcc warning 'deprecated-declarations' will be fixed >>> separately (as part of JDK-8160146) >>> >>> >>> I have built the changes successfully on all supported platforms. >>> >>> >>> Webrev : >>> http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ >>> >>> Request you to review. >>> >>> Regards, >>> Ajit > From philip.race at oracle.com Thu Jul 7 20:21:46 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Jul 2016 13:21:46 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <205fd1cb-2765-44b1-a905-5b722bf99c96@default> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> <577402C7.6040505@oracle.com> <205fd1cb-2765-44b1-a905-5b722bf99c96@default> Message-ID: <577EB9DA.7070202@oracle.com> So far as I can see we can eliminate at least some of the clutter of the calls to deletelocalreference by simply doing it as soon as we are done with the reference eg 309 familyLC = (*env)->CallObjectMethod(env, fmi->family, 310 fmi->toLowerCaseMID, fmi->locale); can be immediately followed by : DeleteLocalReference(env, familyLC); .. whether or not there is a pending exception. and 343 (*env)->CallObjectMethod(env, fmi->familyToFontListMap, 344 fmi->putMID, familyLC, fmi->list); can be immediately followed by : DeleteLocalReference(env, fmi->family); DeleteLocalReference(env, fmi->list); .. whether or not there is a pending exception. and so on. releaseGdiFontMapReferences() seems to be used right before returning to Java. The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. same for the direct calls to deletelocalref. Do you get any JNI warnings if you remove these ? I could even argue that some of the ones before return (0) from the enum functions which will cause us to then exit up the call stack fall into the same bucket but if you can simplify the change as I suggest it'll be easier to sort that out as there'll be less noise. -phil. On 07/04/2016 02:43 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > A quick follow-up on the fix for > Bug ID : JDK-8152971 > Title : -Xcheck:jni - WARNING in native method > > Thanks to Phil for his feedback. > The feedback was not only detailed.. but contained important links for reference. > > I 've incorporated the review suggestions and have updated the webrev. > Brief on changes from previous revision: > > 1. Once an exception has been found in an Up-call, the exception is ' not ' consumed or cleared now. > . As Phil rightly said, this will pave way for the Java methods to know of the exceptions and handle them. > > 2. In addition to point No.1, The GDI's callback functions return zero '0' during an exception. > . This will stop the subsequent enumeration of fonts & calls to registered callbacks through the APIs > > 3. Since exceptions are not consumed, all GDI 's callback functions are checked for pending exceptions at the entry. > . On pending exceptions, the GDI's callback functions return immediately. > . This prevents the functions from invoking any other JNI calls that could be un-safe during a pending exception > . The callback functions merely release any local reference held before returning to caller. > > 4. Since we no longer support Win98, the obsolete ANSI versions of functions (~A functions) have been removed. > . Functions that work with Unicode strings invoking Unicode versions of Windows APIs (~W functions) are retained. > > 5. The jtreg shell script has been modified to execute on all platforms after testing its execution on Windows, Linux, Mac and SunOS. > . Just to re-iterate: The jtreg script fails on windows and solaris but in java.lang codebase. > . A bug is already Open indicating JNI warnings in java.lang package. Hence this change does not introduce any new issues. > > As with any proposed webrev: > . The changes were run through internal build system to ensure safe build on all supported OS versions. > . JCK and JTREG test cases were run to ensure no conformance or regression failures occur. > > Kindly review the changes at your convenience and provide your feedback. > . Updated webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.03/ > > Thank you for your time & effort in review > Have a good day > > Prahalad N. > > ---------------------------------------------------------------------------- > From: Philip Race > Sent: Wednesday, June 29, 2016 10:48 PM > To: Prasanta Sadhukhan > Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Jayathirth D V; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#exception_handling > > lists DeleteLocalRef as safe to call with a pending exception. > > So here ... > 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, > 175 fmi->toLowerCaseMID, fmi->locale); > 176 if ((*env)->ExceptionCheck(env)) { > 177 (*env)->ExceptionClear(env); > 178 /* Delete the created references */ > 179 DeleteLocalReference(env, fullname); > 180 return 1; > 181 } > > ... perhaps what we should do is not clear the exception and > with the goal that after returning from this function we can > check in the caller for a pending exception and return from > JNI to Java *without clearing it* - so that Java code gets > that exception propagated. I suggest this because I think > we would have a correctness issue which should be reported - not > swallowed - if there ever really was one. > > I think this means that the GDI callbacks need to check > for a pending exception on entry and bail since once > we hand off to windows it may be called repeatedly. > > But also we should stop enumeration if we detect an error > hence we should return 0 in this case, not 1 per the > docs for EnumFontFamExProc > > --- > https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs.85).aspx > > > Return value > > The return value must be a nonzero value to continue enumeration; > to stop enumeration, the return value must be zero. > > --- > > Also the "A" functions are now obsolete. No win 98 support any more :-) > We should just delete them instead of updating them. > > And I'd prefer the test be verified on Solaris rather than excluding it > > -phil > > > On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: > Looks good to me. Only thing is in test script, you need to add copyright 2015, 2016 as the script is originally written in 2015 and you cannot omit the created year from the copyright. > > Regards > Prasanta > On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: > > Hello Everyone > > Good day to you. > > Quick follow up to fix for the Bug > Bug ID : JDK-8152971 > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 > > First, Thanks to Prasanta for his review & suggestions. > > I 've incorporated some of the review suggestions & updated the webrev. > Webrev Link : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ > > Overview on changes from previous webrev: > > 1. Code Changes: As Prasanta mentioned, > The variable fontStrLC should be used in place of fontStr - The correction has been taken up. > And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. > > 2. With regard to deleting references held within GdiFontMapInfo struture > JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass > The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). > > 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. > Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. > The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. > As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. > Hence enabling the script on windows, doesn't introduce new bug. > The only OS that the script doesn't run - Solaris. > Presently, we don't have a Solaris environment at our facility to test the script. > Hence the original functionality on Solaris is retained. > > Kindly take a look at the changes at your convenience & provide the suggestions. > > Thank you for your review > Have a good day > > Prahalad N. > > ---------------------------------------------------------------------------- > From: Prasanta Sadhukhan > Sent: Monday, June 27, 2016 11:51 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Cc: Philip Race; Jayathirth D V; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > I guess this method(s) should take "fontStrLC" instead of "fontStr" > 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 651 fontStr, fileStr); > > 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 693 fontStr, fileStr); > > 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 763 fontStr, fileStr); > > 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 806 fontStr, fileStr); > It seems this line is not needed as we have not populated fmi structure yet. > 882 releaseGdiFontMapReferences(env, &fmi); > > Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? > > Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. > Is there any particular need to restrict solaris too? > > Regards > Prasanta > > > On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Forum > Good day to you. > A Quick follow-up on webrev to fix the following issue > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Updated webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ > Description on Changes > . The previous webrev contained changes to additional files which are not related to the current bug in concern. > . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. > Regarding Build & Test > . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. > . In addition, no new Jtreg failures were found with the proposed changes. > Kindly review the changes at your convenience & provide your feedback. > Thank you for your time in review > Have a good day > Prahalad N. > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, June 22, 2016 3:20 PM > To: 2d-dev at openjdk.java.net > Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava > Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > Hello Everyone, on Java2D Group > Good day to you. > Please find herewith, webrev changes to fix the bug- > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Webrev : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ > Description on Bug: > 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni > 2. The warnings can be classified into 2 categories > a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) > b. JNI warnings that are thrown due to increased usage of Local Reference objects. > Description on the Fix: > 1. File : FontPath.c > Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. > The checks are added only to the valid Up calls as per JNI spec. > Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. > A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. > Therefore at each callback, the count of active local references would increase. > Over time, the active local references would exceed the planned number of local references set by JVM. > 2. File : awt_Component.cpp > Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. > Information on Jtreg test script is given below. > 3. File : LoadFontsJNICheck.sh > The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option > However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. > This way, the code changes can be checked for proper execution with test-case. > 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 Thu Jul 7 20:26:35 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Jul 2016 13:26:35 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> Message-ID: <577EBAFB.1070503@oracle.com> I suppose deleteOnExit might be OK but jtreg re-uses the VM so it will not get deleted until much later - after all N thousand tests have been run .. assuming no other test crashes the VM before then. -phil. On 07/07/2016 10:41 AM, Brian Burkhalter wrote: > Why not simply invoke deleteOnExit() on the file instance immediately > after it is created and use try-with-resources blocks for the > Image{Input,Output}Stream instances? > > Brian > > On Jul 7, 2016, at 4:38 AM, Jayathirth D V > wrote: > >> Please review the following fix in JDK9 : >> Bug :https://bugs.openjdk.java.net/browse/JDK-7059970 >> Webrev :http://cr.openjdk.java.net/~jdv/7059970/webrev.00/ >> >> Root cause : Test case ITXtTest.java is not deleting the file it is >> creating(test.png). Also it is not closing ImageInputStream that it >> is creating in between. >> Fix : Close the stream and file that is used in the test case with >> tighter checks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Jul 7 20:47:09 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Jul 2016 13:47:09 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <577EBAFB.1070503@oracle.com> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> Message-ID: <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> Good point - probably better to make it explicit then. The try-with-resources should still be cleaner for closing the streams however. Brian On Jul 7, 2016, at 1:26 PM, Phil Race wrote: > I suppose deleteOnExit might be OK but jtreg re-uses the VM > so it will not get deleted until much later - after all N thousand tests have > been run .. assuming no other test crashes the VM before then. > > -phil. > > On 07/07/2016 10:41 AM, Brian Burkhalter wrote: >> Why not simply invoke deleteOnExit() on the file instance immediately after it is created and use try-with-resources blocks for the Image{Input,Output}Stream instances? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 7 23:10:21 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 07 Jul 2016 16:10:21 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8158370 Text drawn with floating pointing scale can be shifted to one pixel In-Reply-To: <1b76b6da-674c-ab62-c253-182ae12aa869@oracle.com> References: <1b76b6da-674c-ab62-c253-182ae12aa869@oracle.com> Message-ID: <577EE15D.4080106@oracle.com> Hi, This is about how to "snap" the drawing origin of text to a device pixel when the origin has been supplied as a floating point value but behind it we have some accumulated FP error. The scaling is one way to demonstrate this but it may also be demonstrable with an identity transform and the overload of drawString that accepts float. consider : (Graphics2D(g)).drawString("a", 0.5f, 10f); vs (Graphics2D(g)).drawString("a", 0.49999f, 10f); I think the thing in your test that triggers it is that the FP error in the string bounds (99.99999....) that I see - at least for the font I am using on Linux. Mileage may vary depending on font. This is arguably where the problem originates and your proposed change is an (almost) final stage compensation for that. For logic that decides precisely where to place the glyph see the setup[LCD]BlitVector function and then the FLOOR_ASSIGN macro in DrawGlyphList.c which is replicated in OGL/D3DTextRenderer.c/cpp ... the Java loops should be doing something equivalent. Basically we round where we start to the nearest device pixel and so being at 0.49999 vs 0.5000 is just enough to tickle a one device pixel difference. Also I note that you changed only *one* out of several code paths here. It isn't applied to drawChars and drawGlyphVector which each have the same two branches. Also since I believe this in principle applies to translate only too, perhaps the "else" branches need the same treatment, although that exposes the "base" case to this expensive calculation. I am not asking you to go change those .. just noting it .. Leaving aside the missing parts I am not sure about 1) whether the calculations can be made less costly, 2) whether we should try to fix this "upstream" - ie when we report bounds can we notice we are about to report N.9999 or N.0001, or 3) further downstream, in the final rendering code 4) not attempt to fix it at all and pass this on to the application. I think either of (2) or (3) might require changes in more than one code path. (3) would at least be where we are doing the "+0.5" and I think it better to keep the logic together. (3) would look like this diff --git a/src/java.desktop/share/native/libfontmanager/DrawGlyphList.c b/src/java.desktop/share/native/libfontmanager/DrawGlyphList.c --- a/src/java.desktop/share/native/libfontmanager/DrawGlyphList.c +++ b/src/java.desktop/share/native/libfontmanager/DrawGlyphList.c @@ -87,7 +87,7 @@ /* Add 0.5 to x and y and then use floor (or an equivalent operation) * to round down the glyph positions to integral pixel positions. */ - x += 0.5f; + x += 0.5001f; y += 0.5f; if (glyphPositions) { int n = -1; @@ -541,7 +541,7 @@ x += 0.1666667f; y += 0.1666667f; } else { - x += 0.5f; + x += 0.5001f; y += 0.5f; } .. maybe y needs the same ? I am not sure yet that OGL/D3D/Java loops are all consistent here in having that rounding but if they aren't that seems to be a bug and I'd have to wonder if you are going to see the behaviour you are fixing there anyway ? Have you tested to see if this is consistent (as a problem) if going through software as well as D3DTR_DrawGlyphList(..) and OGLTR_DrawGlyphList(..) ? If you weren't seeing the problem there it may be because they aren't doing the rounding they should be. This needs an audit before making any changes. Maybe the test can try to cover these scenarios ? Regarding the test, it can report "fail" even when it actually passes. I've seen this because you are not accounting for the significant probability of the LCD blending touching the pixels between the glyphs. I recommend you use DEFAULT instead. Also a test that is automated *and* draws to the screen (even if only optionally) would make it easier for a human to evaluate. BTW the test uses the FP version of drawString when it has floats .. it would be important for application code to do the same rather than cast to int. I mention this just "for the record", not because I see an improper use anywhere. -phil On 6/23/16, 1:04 PM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8158370 > webrev: http://cr.openjdk.java.net/~alexsch/8158370/webrev.00 > > Char advance in user space is calculated with float precision. That > leads that summed up char advances in user space can have small > rounding error. > > To draw a substring of a text as selected it needs to draw the > selected text from the string location plus the preceding text width. > The selected text location is close to an integer value for an > integer scale: > (textX + sum(charAdvanceInDevSpave/scale) + transformTranslate) * > scale // both textX and transformTranslate have integer value > > The situation is different for floating point scales. Now (textX + > transformTranslate) * scale can be a floating point value like N.5 > where N is some integer value. The sum(charAdvanceInDevSpave/scale) * > scale is close to an integer. > Sum of these values can be M.499.. which is rounded to M or M.500.. > which is rounded to M+1. > > Because of this a selected text can be shifted to one pixel left > from the required position. > > The proposed fix rounds the text coordinates to the closest half > integer value if it is necessary in dev space. > > Thanks, > Alexandr. > From philip.race at oracle.com Thu Jul 7 23:15:18 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 07 Jul 2016 16:15:18 -0700 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() In-Reply-To: References: <5775AE95.5070302@oracle.com> <577C0804.20908@oracle.com> Message-ID: <577EE286.4040702@oracle.com> +1 -phil. On 7/6/16, 9:52 PM, Ajit Ghaisas wrote: > Thanks for the review. > > I have corrected the test case name as per suggestion. > Here is the updated webrev. > http://cr.openjdk.java.net/~aghaisas/8160421/webrev.02/ > > Yes, the test captures the redirected contents of stderr correctly when run using jtreg - both with or without othervm specified. > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Wednesday, July 06, 2016 12:48 AM > To: Ajit Ghaisas > Cc: Jim Graham; Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() > > I prefer meaningful test names .. the bug id is already in the @bug tag and a test can later be updated to test> 1 bug. > Did you verify that you are in fact capturing stderr - even in othervm mode - when running the test under jtreg ? > Even when setting up a new VM jtreg may capture this for you. > > -phil. > > > On 07/05/2016 04:42 AM, Ajit Ghaisas wrote: >> Thanks Jim for suggesting test should have its own VM. I agree with it. >> >> Here is the updated webrev : >> http://cr.openjdk.java.net/~aghaisas/8160421/webrev.01/ >> >> Phil, can you please review it? >> >> Regards, >> Ajit >> >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, July 01, 2016 5:13 AM >> To: Ajit Ghaisas; Philip Race; Sergey Bylokhov; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: >> JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() >> >> The solution looks fine to me. >> >> I didn't run the test case, but about the only issue I can see with it is whether it should have a flag to run it in its own VM because of its interaction with System.err. Phil? >> >> ...jim >> >> On 06/30/2016 06:41 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : >>> This is regarding a NPE getting printed as stacktrace in java.awt.Toolkit.createCustomCursor() method. >>> The bug is described at : >>> https://bugs.openjdk.java.net/browse/JDK-8160421 >>> >>> Root Cause : >>> Fix of bug JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7. >>> The above fix added a RuntimeException catch& log mechanism to support a ImageFilter which was broken due to the second imageComplete() call in OffScreenImageSource.produce() method. >>> >>> Analysis: >>> Without the fix of JDK-8139192, java.awt.Toolkit.createCustomCursor() call results in >>> NullPointerException when imageComplete(ImageConsumer.STATICIMAGEDONE) call is made - but, it gets consumed silently. >>> Cathing RuntimeException() out of imageComplete(ImageConsumer.STATICIMAGEDONE) was added to fix JDK-8160421. >>> This started catching& logging the exception in case 'theConsumer' has unregistered itself as a result of call >>> theConsumer.imageComplete(ImageConsumer.SINGLEFRAMEDONE); >>> This log is undesirable as this mechanism is used in java.awt.Toolkit.createCustomCursor() and may be in other places. >>> >>> Fix : >>> Make the call to imageComplete(ImageConsumer.STATICIMAGEDONE) only if 'theConsumer' has not been unregistered. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~aghaisas/8160421/webrev.00/ >>> >>> Request you to review. >>> >>> Regards, >>> Ajit >>> From philip.race at oracle.com Thu Jul 7 23:16:02 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 07 Jul 2016 16:16:02 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <57763688.4070806@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> <57752ABC.4020406@oracle.com> <57763688.4070806@oracle.com> Message-ID: <577EE2B2.8020605@oracle.com> Ok .. +1 -phil. On 7/1/16, 2:23 AM, Prasanta Sadhukhan wrote: > Hi Phil, > > On 6/30/2016 7:50 PM, Philip Race wrote: >> Eh ? Before your change the code was calling >> isAttributeCategorySupported(), notisAttributeValueSupported() >> >> So there was not previously a possibility of that NPE, and >> my point was now you have changed that call you need that !=null check >> even more .. > Yes, I got that, right immediately after sending the below mail and > sent another email clarifying my misunderstanding. >> >> But I think there is still a problem. Now dstSupported is set only if >> the *specific* destination is supported. >> >> A malformed file: URL would not be valid but should not >> disable (grey out) the print to file checkbox which >> is what it looks like here .. can you verify this ? >> > Yes, we will grey out the checkbox for malformed url (like > files::/tmp/output.ps) as I found out. Please find modified webrev > that takes care of this problem too: > http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.02/ > > Regards > Prasanta >> >> -phil >> >> >> >> >> On 6/30/16, 12:45 AM, Prasanta Sadhukhan wrote: >>> Hi Phil, >>> >>> NPE will be thrown >>> ---------- >>> public boolean isAttributeValueSupported(Attribute attr, >>> DocFlavor flavor, >>> AttributeSet attributes) { >>> if (attr == null) { >>> throw new NullPointerException("null attribute"); >>> } >>> --------- >>> before updateInfo() will be called so I guess null check is >>> redundant there. Anyways, I have added the check back just to be safe >>> http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 6/29/2016 11:59 PM, Philip Race wrote: >>>> --- >>>> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- >>>> >>>> >>>> Throws: >>>> NullPointerException - (unchecked exception) if attrval is null. >>>> >>>> -- >>>> >>>> So why did you remove the check for null ? >>>> >>>> >>>> -phil. >>>> >>>> On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that >>>>> "Print-To-File" option is enabled even for flavors that do not >>>>> support Destination attribute >>>>> even though isAttributeValueSupported for that flavor returns false. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ >>>>> >>>>> The reason for this behaviour is in Print Dialog code, the >>>>> validation is done against isAttributeCategorySupported() which >>>>> still returns true because Pageable and Printable supports it >>>>> and therefore the "Print-to-File" option gets enabled. >>>>> >>>>> But print dialog is shown specific to a doc flavor and a print >>>>> service (selected one) and hence must validate the attribute >>>>> against the chosen doc flavor. >>>>> So, the proposed fix checks the attributevalue is supported or not >>>>> for that flavor to determine if we need to enable "Print-to-File" >>>>> option in print dialog. >>>>> >>>>> Regards >>>>> Prasanta >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 8 05:40:27 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 8 Jul 2016 11:10:27 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8160882: [PIT][TEST_BUG] a trap of java/awt/print/PrinterJob/PrintTestLexmarkIQ.java Message-ID: <577F3CCB.8000701@oracle.com> Hi All, Please review a test bug fix whereby clicking on x button of testpanel does not fail the test. Bug: https://bugs.openjdk.java.net/browse/JDK-8160882 webrev: http://cr.openjdk.java.net/~psadhukhan/8160882/webrev.00/ Handled the close button of testpanel to fail the test citing "user has not executed the test". Regards Prasanta From jayathirth.d.v at oracle.com Fri Jul 8 07:04:24 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 8 Jul 2016 07:04:24 +0000 (UTC) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> Message-ID: <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> Hi Phil and Brian, Thanks for your inputs. I have made following updates: 1) Added new bug-id in the test case. 2) Using try-with-resources for closing streams. I can't perform f.delete() in finally block of writeTo() and readFrom() because "test.png" is shared resource between the methods. So I am deleting "test.png" at places where we are throwing RumtimeException. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/7059970/webrev.01/ Thanks, Jay From: Brian Burkhalter Sent: Friday, July 08, 2016 2:17 AM To: Phil Race Cc: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Good point - probably better to make it explicit then. The try-with-resources should still be cleaner for closing the streams however. Brian On Jul 7, 2016, at 1:26 PM, Phil Race wrote: I suppose deleteOnExit might be OK but jtreg re-uses the VM so it will not get deleted until much later - after all N thousand tests have been run .. assuming no other test crashes the VM before then. -phil. On 07/07/2016 10:41 AM, Brian Burkhalter wrote: Why not simply invoke deleteOnExit() on the file instance immediately after it is created and use try-with-resources blocks for the Image{Input,Output}Stream instances? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 8 07:29:23 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 8 Jul 2016 12:59:23 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8160888: [PIT] What to expect of updated java/awt/print/PrinterJob/Margins.java Message-ID: <577F5653.1010500@oracle.com> Hi All, Please find an updation of the testcase Bug: https://bugs.openjdk.java.net/browse/JDK-8160888 webrev: http://cr.openjdk.java.net/~psadhukhan/8160888/webrev.00/ where the testcase was made automated and specifically pass mediasize=A4 as attributes so that there is no ambiguity of using "letter" vs "A4". Also, the test is made to run only on windows as the bug is not reproduced in linux/mac. Regards Prasanta From jayathirth.d.v at oracle.com Fri Jul 8 10:30:22 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 8 Jul 2016 10:30:22 +0000 (UTC) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <577EE2B2.8020605@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> <57752ABC.4020406@oracle.com> <57763688.4070806@oracle.com> <577EE2B2.8020605@oracle.com> Message-ID: <9b0db71a-59da-4531-b1e0-6622b4b244e4@default> Hi Prasanta, Since CUPS is not used in Windows, your change will not make difference if I run the test in Windows. Please add @requires tag in jtreg test case and there are some lines which are 80 character plus. Also please add null check when you create PrinterService in test case. Thanks, Jay From: Philip Race Sent: Friday, July 08, 2016 4:46 AM To: Prasanta Sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination Ok .. +1 -phil. On 7/1/16, 2:23 AM, Prasanta Sadhukhan wrote: Hi Phil, On 6/30/2016 7:50 PM, Philip Race wrote: Eh ? Before your change the code was calling isAttributeCategorySupported(), not isAttributeValueSupported() So there was not previously a possibility of that NPE, and my point was now you have changed that call you need that !=null check even more .. Yes, I got that, right immediately after sending the below mail and sent another email clarifying my misunderstanding. But I think there is still a problem. Now dstSupported is set only if the *specific* destination is supported. A malformed file: URL would not be valid but should not disable (grey out) the print to file checkbox which is what it looks like here .. can you verify this ? Yes, we will grey out the checkbox for malformed url (like files::/tmp/output.ps) as I found out. Please find modified webrev that takes care of this problem too: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5049012/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.02/ Regards Prasanta -phil On 6/30/16, 12:45 AM, Prasanta Sadhukhan wrote: Hi Phil, NPE will be thrown ---------- public boolean isAttributeValueSupported(Attribute attr, DocFlavor flavor, AttributeSet attributes) { if (attr == null) { throw new NullPointerException("null attribute"); } --------- before updateInfo() will be called so I guess null check is redundant there. Anyways, I have added the check back just to be safe HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5049012/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ Regards Prasanta On 6/29/2016 11:59 PM, Philip Race wrote: --- https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- Throws: NullPointerException - (unchecked exception) if attrval is null. -- So why did you remove the check for null ? -phil. On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: Hi All, Please review a fix for an issue where it is seen that "Print-To-File" option is enabled even for flavors that do not support Destination attribute even though isAttributeValueSupported for that flavor returns false. Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5049012/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ The reason for this behaviour is in Print Dialog code, the validation is done against isAttributeCategorySupported() which still returns true because Pageable and Printable supports it and therefore the "Print-to-File" option gets enabled. But print dialog is shown specific to a doc flavor and a print service (selected one) and hence must validate the attribute against the chosen doc flavor. So, the proposed fix checks the attributevalue is supported or not for that flavor to determine if we need to enable "Print-to-File" option in print dialog. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jul 8 11:08:54 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 8 Jul 2016 11:08:54 +0000 (UTC) Subject: [OpenJDK 2D-Dev] REG : JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java Message-ID: <29b00640-a619-4c2f-9514-8079133ab87f@default> Hi, In HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8152672"JDK-8152672 we modified skipImage() in JpegImageReader.java and added tighter checks for parsing Jpeg data. We have to find any marker,0 or EOF after we find "FF" while parsing JPEG data. But in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160943"JDK-8160943 we have gap between APP0 marker and DQT(FF DB) marker which contains data "00 FF". APP0_End -> 00 FF -> FF DB(DQT) So after we skip APP0 marker we find two bytes of data which is "FF FF". In the present code we consider this as invalid marker. Because of this HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160943"JDK-8160943 is failing. Is the length of APP0 marker not valid in the image or we should not consider "FF FF" as invalid maker? Please let me know your input. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 8 11:12:24 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 8 Jul 2016 16:42:24 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <9b0db71a-59da-4531-b1e0-6622b4b244e4@default> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> <57752ABC.4020406@oracle.com> <57763688.4070806@oracle.com> <577EE2B2.8020605@oracle.com> <9b0db71a-59da-4531-b1e0-6622b4b244e4@default> Message-ID: <577F8A98.4040301@oracle.com> Hi Jay, Thanks for pointing that out. Modified testcase to run in linux only and added check to fail if no printer service is found. http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.03/ Regards Prasanta On 7/8/2016 4:00 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Since CUPS is not used in Windows, your change will not make > difference if I run the test in Windows. > > Please add @requires tag in jtreg test case and there are some lines > which are 80 character plus. > > Also please add null check when you create PrinterService in test case. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Friday, July 08, 2016 4:46 AM > *To:* Prasanta Sadhukhan > *Cc:* 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile > option is not disabled for flavors that do not support destination > > Ok .. +1 > > -phil. > > On 7/1/16, 2:23 AM, Prasanta Sadhukhan wrote: > > Hi Phil, > > On 6/30/2016 7:50 PM, Philip Race wrote: > > Eh ? Before your change the code was calling > > isAttributeCategorySupported(), not isAttributeValueSupported() > > So there was not previously a possibility of that NPE, and > > my point was now you have changed that call you need that > !=null check > > even more .. > > Yes, I got that, right immediately after sending the below mail > and sent another email clarifying my misunderstanding. > > But I think there is still a problem. Now dstSupported is set > only if > > the *specific* destination is supported. > > A malformed file: URL would not be valid but should not > > disable (grey out) the print to file checkbox which > > is what it looks like here .. can you verify this ? > > Yes, we will grey out the checkbox for malformed url (like > files::/tmp/output.ps) as I found out. Please find modified webrev > that takes care of this problem too: > http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.02/ > > > Regards > Prasanta > > -phil > > > > On 6/30/16, 12:45 AM, Prasanta Sadhukhan wrote: > > Hi Phil, > > NPE will be thrown > ---------- > public boolean isAttributeValueSupported(Attribute attr, > DocFlavor > flavor, > AttributeSet attributes) { > if (attr == null) { > throw new NullPointerException("null attribute"); > } > --------- > before updateInfo() will be called so I guess null check > is redundant there. Anyways, I have added the check back > just to be safe > http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ > > > Regards > Prasanta > On 6/29/2016 11:59 PM, Philip Race wrote: > > --- > https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- > > > Throws: > NullPointerException - (unchecked exception) if > attrval is null. > > -- > > So why did you remove the check for null ? > > > -phil. > > On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: > > Hi All, > > Please review a fix for an issue where it is seen > that "Print-To-File" option is enabled even for > flavors that do not support Destination attribute > even though isAttributeValueSupported for that > flavor returns false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 > webrev: > http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ > > > > The reason for this behaviour is in Print Dialog > code, the validation is done against > isAttributeCategorySupported() which still returns > true because Pageable and Printable supports it > and therefore the "Print-to-File" option gets > enabled. > > But print dialog is shown specific to a doc flavor > and a print service (selected one) and hence must > validate the attribute against the chosen doc flavor. > So, the proposed fix checks the attributevalue is > supported or not for that flavor to determine if > we need to enable "Print-to-File" option in print > dialog. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jul 8 11:20:33 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 8 Jul 2016 11:20:33 +0000 (UTC) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <577F8A98.4040301@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> <57752ABC.4020406@oracle.com> <57763688.4070806@oracle.com> <577EE2B2.8020605@oracle.com> <9b0db71a-59da-4531-b1e0-6622b4b244e4@default> <577F8A98.4040301@oracle.com> Message-ID: <5ea4f9e6-2969-4516-94e0-7d34c40b2b9a@default> Hi Prasanta, Changes are fine. Thanks, Jay From: Prasanta Sadhukhan Sent: Friday, July 08, 2016 4:42 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination Hi Jay, Thanks for pointing that out. Modified testcase to run in linux only and added check to fail if no printer service is found. http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.03/ Regards Prasanta On 7/8/2016 4:00 PM, Jayathirth D V wrote: Hi Prasanta, Since CUPS is not used in Windows, your change will not make difference if I run the test in Windows. Please add @requires tag in jtreg test case and there are some lines which are 80 character plus. Also please add null check when you create PrinterService in test case. Thanks, Jay From: Philip Race Sent: Friday, July 08, 2016 4:46 AM To: Prasanta Sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination Ok .. +1 -phil. On 7/1/16, 2:23 AM, Prasanta Sadhukhan wrote: Hi Phil, On 6/30/2016 7:50 PM, Philip Race wrote: Eh ? Before your change the code was calling isAttributeCategorySupported(), not isAttributeValueSupported() So there was not previously a possibility of that NPE, and my point was now you have changed that call you need that !=null check even more .. Yes, I got that, right immediately after sending the below mail and sent another email clarifying my misunderstanding. But I think there is still a problem. Now dstSupported is set only if the *specific* destination is supported. A malformed file: URL would not be valid but should not disable (grey out) the print to file checkbox which is what it looks like here .. can you verify this ? Yes, we will grey out the checkbox for malformed url (like files::/tmp/output.ps) as I found out. Please find modified webrev that takes care of this problem too: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5049012/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.02/ Regards Prasanta -phil On 6/30/16, 12:45 AM, Prasanta Sadhukhan wrote: Hi Phil, NPE will be thrown ---------- public boolean isAttributeValueSupported(Attribute attr, DocFlavor flavor, AttributeSet attributes) { if (attr == null) { throw new NullPointerException("null attribute"); } --------- before updateInfo() will be called so I guess null check is redundant there. Anyways, I have added the check back just to be safe HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5049012/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ Regards Prasanta On 6/29/2016 11:59 PM, Philip Race wrote: --- https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- Throws: NullPointerException - (unchecked exception) if attrval is null. -- So why did you remove the check for null ? -phil. On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: Hi All, Please review a fix for an issue where it is seen that "Print-To-File" option is enabled even for flavors that do not support Destination attribute even though isAttributeValueSupported for that flavor returns false. Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5049012/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ The reason for this behaviour is in Print Dialog code, the validation is done against isAttributeCategorySupported() which still returns true because Pageable and Printable supports it and therefore the "Print-to-File" option gets enabled. But print dialog is shown specific to a doc flavor and a print service (selected one) and hence must validate the attribute against the chosen doc flavor. So, the proposed fix checks the attributevalue is supported or not for that flavor to determine if we need to enable "Print-to-File" option in print dialog. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jul 8 18:05:05 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Jul 2016 11:05:05 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> Message-ID: Hi Jay, Sorry to be picky here but in doTest() could you not instead have try { writeTo(file, src); ITXtTest dst = readFrom(file); if (dst == null || !dst.equals(src)) { throw new RuntimeException("Test failed."); } } catch (RuntimeException re) { throw re; } finally { file.delete(); } System.out.println("Test passed."); and therefore remove f.delete() from writeTo() and readFrom()? Thanks, Brian On Jul 8, 2016, at 12:04 AM, Jayathirth D V wrote: > I can?t perform f.delete() in finally block of writeTo() and readFrom() because ?test.png? is shared resource between the methods. So I am deleting ?test.png? at places where we are throwing RumtimeException. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 8 19:07:10 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 08 Jul 2016 12:07:10 -0700 Subject: [OpenJDK 2D-Dev] REG : JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: <29b00640-a619-4c2f-9514-8079133ab87f@default> References: <29b00640-a619-4c2f-9514-8079133ab87f@default> Message-ID: <577FF9DE.8070101@oracle.com> On 07/08/2016 04:08 AM, Jayathirth D V wrote: > > Hi, > > In JDK-8152672 we > modified skipImage() in JpegImageReader.java and added tighter checks > for parsing Jpeg data. > > We have to find any marker,0 or EOF after we find "FF" while parsing > JPEG data. > > But in JDK-8160943 > we have gap between APP0 marker and DQT(FF DB) marker which contains > data "00 FF". > > APP0_End -> 00 FF -> FF DB(DQT) > > So after we skip APP0 marker we find two bytes of data which is "FF > FF". In the present code we consider this as invalid marker. > See https://www.w3.org/Graphics/JPEG/itu-t81.pdf B.1.1.2 Markers Markers serve to identify the various structural parts of the compressed data formats. Most markers start marker segments containing a related group of parameters; some markers stand alone. All markers are assigned two-byte codes: an X'FF' byte followed by a byte which is not equal to 0 or X'FF' (see Table B.1). Any marker may optionally be preceded by any number of fill bytes, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ which are bytes assigned code X'FF ^^^^^^^^^^^^^^^^^^^^^^ -phil. > Because of this JDK-8160943 > is failing. > > Is the length of APP0 marker not valid in the image or we should not > consider "FF FF" as invalid maker? > > Please let me know your input. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.nesterenko at oracle.com Mon Jul 11 06:47:37 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Mon, 11 Jul 2016 09:47:37 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR 8160882: [PIT][TEST_BUG] a trap of java/awt/print/PrinterJob/PrintTestLexmarkIQ.java In-Reply-To: <577F3CCB.8000701@oracle.com> References: <577F3CCB.8000701@oracle.com> Message-ID: <57834109.1070400@oracle.com> +1 Thank you! It works. -yan On 07/08/2016 08:40 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test bug fix whereby clicking on x button of testpanel > does not fail the test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160882 > webrev: http://cr.openjdk.java.net/~psadhukhan/8160882/webrev.00/ > > Handled the close button of testpanel to fail the test citing "user has > not executed the test". > > Regards > Prasanta From prahalad.kumar.narayanan at oracle.com Mon Jul 11 19:02:44 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 11 Jul 2016 12:02:44 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <577EB9DA.7070202@oracle.com> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> <577402C7.6040505@oracle.com> <205fd1cb-2765-44b1-a905-5b722bf99c96@default> <577EB9DA.7070202@oracle.com> Message-ID: <7b6a9f76-167a-490d-ac4c-aa24e6623107@default> Hello Everyone Good day to you. A quick follow-up on the bug fix for : JDK-8152971 JNI Warning with -Xcheck:jni First, Thanks to Phil for the time in review and detailed explanation. To answer the question - "The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. same for the direct calls to deletelocalref. Do you get any JNI warnings if you remove these ? " Answer : Yes., I see the warnings if DeleteLocalRef is not invoked on objects created in the callback functions. It is in these callback functions that many objects get created without a corresponding release api. No warnings were seen when releaseGdiFontMapReferences() was taken out. This function is removed in the latest change. The behavior could be attributed to two points a. FontMap having most of its references to jObjects that are on stack (as arguments to function). b. Very few references to local objects are created in the parent JNI function ( 2 - 3 classIDs ) To Summarize the Changes . In all callback functions, the DeleteLocalRef calls have been reorganized to avoid cluttering before return statements. . releaseGdiFontMapReferences() function has been removed. The only font map reference that is released in latest code - is the reference to jClass object along with other classID references. This could be avoided but has been retained as a safe measure. The changes are available under webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.04/ Kindly review at your convenient time and provide your suggestions. Thanks for your review & feedback Have a good day Prahalad N. -----Original Message----- From: Phil Race Sent: Friday, July 08, 2016 1:52 AM To: Prahalad Kumar Narayanan Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Jayathirth D V; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni So far as I can see we can eliminate at least some of the clutter of the calls to deletelocalreference by simply doing it as soon as we are done with the reference eg 309 familyLC = (*env)->CallObjectMethod(env, fmi->family, 310 fmi->toLowerCaseMID, fmi->locale); can be immediately followed by : DeleteLocalReference(env, familyLC); .. whether or not there is a pending exception. and 343 (*env)->CallObjectMethod(env, fmi->familyToFontListMap, 344 fmi->putMID, familyLC, fmi->list); can be immediately followed by : DeleteLocalReference(env, fmi->family); DeleteLocalReference(env, fmi->list); .. whether or not there is a pending exception. and so on. releaseGdiFontMapReferences() seems to be used right before returning to Java. The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. same for the direct calls to deletelocalref. Do you get any JNI warnings if you remove these ? I could even argue that some of the ones before return (0) from the enum functions which will cause us to then exit up the call stack fall into the same bucket but if you can simplify the change as I suggest it'll be easier to sort that out as there'll be less noise. -phil. On 07/04/2016 02:43 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > A quick follow-up on the fix for > Bug ID : JDK-8152971 > Title : -Xcheck:jni - WARNING in native method > > Thanks to Phil for his feedback. > The feedback was not only detailed.. but contained important links for reference. > > I 've incorporated the review suggestions and have updated the webrev. > Brief on changes from previous revision: > > 1. Once an exception has been found in an Up-call, the exception is ' not ' consumed or cleared now. > . As Phil rightly said, this will pave way for the Java methods to know of the exceptions and handle them. > > 2. In addition to point No.1, The GDI's callback functions return zero '0' during an exception. > . This will stop the subsequent enumeration of fonts & > calls to registered callbacks through the APIs > > 3. Since exceptions are not consumed, all GDI 's callback functions are checked for pending exceptions at the entry. > . On pending exceptions, the GDI's callback functions return immediately. > . This prevents the functions from invoking any other JNI calls that could be un-safe during a pending exception > . The callback functions merely release any local reference held before returning to caller. > > 4. Since we no longer support Win98, the obsolete ANSI versions of functions (~A functions) have been removed. > . Functions that work with Unicode strings invoking Unicode versions of Windows APIs (~W functions) are retained. > > 5. The jtreg shell script has been modified to execute on all platforms after testing its execution on Windows, Linux, Mac and SunOS. > . Just to re-iterate: The jtreg script fails on windows and solaris but in java.lang codebase. > . A bug is already Open indicating JNI warnings in java.lang package. Hence this change does not introduce any new issues. > > As with any proposed webrev: > . The changes were run through internal build system to ensure safe build on all supported OS versions. > . JCK and JTREG test cases were run to ensure no conformance or regression failures occur. > > Kindly review the changes at your convenience and provide your feedback. > . Updated webrev link: > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.03/ > > Thank you for your time & effort in review Have a good day > > Prahalad N. > > ---------------------------------------------------------------------- > ------ > From: Philip Race > Sent: Wednesday, June 29, 2016 10:48 PM > To: Prasanta Sadhukhan > Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Jayathirth D V; > Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with > -Xcheck:jni > > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design > .html#exception_handling > > lists DeleteLocalRef as safe to call with a pending exception. > > So here ... > 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, > 175 fmi->toLowerCaseMID, fmi->locale); > 176 if ((*env)->ExceptionCheck(env)) { > 177 (*env)->ExceptionClear(env); > 178 /* Delete the created references */ > 179 DeleteLocalReference(env, fullname); > 180 return 1; > 181 } > > ... perhaps what we should do is not clear the exception and with the > goal that after returning from this function we can check in the > caller for a pending exception and return from JNI to Java *without > clearing it* - so that Java code gets that exception propagated. I > suggest this because I think we would have a correctness issue which > should be reported - not swallowed - if there ever really was one. > > I think this means that the GDI callbacks need to check for a pending > exception on entry and bail since once we hand off to windows it may > be called repeatedly. > > But also we should stop enumeration if we detect an error hence we > should return 0 in this case, not 1 per the docs for EnumFontFamExProc > > --- > https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs > .85).aspx > > > Return value > > The return value must be a nonzero value to continue enumeration; > to stop enumeration, the return value must be zero. > > --- > > Also the "A" functions are now obsolete. No win 98 support any more > :-) We should just delete them instead of updating them. > > And I'd prefer the test be verified on Solaris rather than excluding > it > > -phil > > > On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: > Looks good to me. Only thing is in test script, you need to add copyright 2015, 2016 as the script is originally written in 2015 and you cannot omit the created year from the copyright. > > Regards > Prasanta > On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: > > Hello Everyone > > Good day to you. > > Quick follow up to fix for the Bug > Bug ID : JDK-8152971 > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 > > First, Thanks to Prasanta for his review & suggestions. > > I 've incorporated some of the review suggestions & updated the webrev. > Webrev Link : > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ > > Overview on changes from previous webrev: > > 1. Code Changes: As Prasanta mentioned, > The variable fontStrLC should be used in place of fontStr - The correction has been taken up. > And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. > > 2. With regard to deleting references held within GdiFontMapInfo struture > JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass > The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). > > 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. > Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. > The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. > As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. > Hence enabling the script on windows, doesn't introduce new bug. > The only OS that the script doesn't run - Solaris. > Presently, we don't have a Solaris environment at our facility to test the script. > Hence the original functionality on Solaris is retained. > > Kindly take a look at the changes at your convenience & provide the suggestions. > > Thank you for your review > Have a good day > > Prahalad N. > > ---------------------------------------------------------------------- > ------ > From: Prasanta Sadhukhan > Sent: Monday, June 27, 2016 11:51 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Cc: Philip Race; Jayathirth D V; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with > -Xcheck:jni > > I guess this method(s) should take "fontStrLC" instead of "fontStr" > 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 651 fontStr, fileStr); > > 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 693 fontStr, fileStr); > > 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 763 fontStr, fileStr); > > 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 806 fontStr, fileStr); > It seems this line is not needed as we have not populated fmi structure yet. > 882 releaseGdiFontMapReferences(env, &fmi); > > Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? > > Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. > Is there any particular need to restrict solaris too? > > Regards > Prasanta > > > On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Forum > Good day to you. > A Quick follow-up on webrev to fix the following issue > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : > https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Updated webrev link: > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ > Description on Changes > . The previous webrev contained changes to additional files which are not related to the current bug in concern. > . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. > Regarding Build & Test > . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. > . In addition, no new Jtreg failures were found with the proposed changes. > Kindly review the changes at your convenience & provide your feedback. > Thank you for your time in review > Have a good day > Prahalad N. > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, June 22, 2016 3:20 PM > To: 2d-dev at openjdk.java.net > Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen > Srivastava > Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > Hello Everyone, on Java2D Group Good day to you. > Please find herewith, webrev changes to fix the bug- > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Webrev : > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ > Description on Bug: > 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni > 2. The warnings can be classified into 2 categories > a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) > b. JNI warnings that are thrown due to increased usage of Local Reference objects. > Description on the Fix: > 1. File : FontPath.c > Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. > The checks are added only to the valid Up calls as per JNI spec. > Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. > A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. > Therefore at each callback, the count of active local references would increase. > Over time, the active local references would exceed the planned number of local references set by JVM. > 2. File : awt_Component.cpp > Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. > Information on Jtreg test script is given below. > 3. File : LoadFontsJNICheck.sh > The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option > However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. > This way, the code changes can be checked for proper execution with test-case. > 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 Tue Jul 12 12:03:35 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 12 Jul 2016 05:03:35 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> Message-ID: Hi Brian, That's very good thing to do as it will remove redundant f.delete(). I have updated the webrev for review : http://cr.openjdk.java.net/~jdv/7059970/webrev.02/ Thanks, Jay From: Brian Burkhalter Sent: Friday, July 08, 2016 11:35 PM To: Jayathirth D V Cc: Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Hi Jay, Sorry to be picky here but in doTest() could you not instead have try { writeTo(file, src); ITXtTest dst = readFrom(file); if (dst == null || !dst.equals(src)) { throw new RuntimeException("Test failed."); } } catch (RuntimeException re) { throw re; } finally { file.delete(); } System.out.println("Test passed."); and therefore remove f.delete() from writeTo() and readFrom()? Thanks, Brian On Jul 8, 2016, at 12:04 AM, Jayathirth D V wrote: I can't perform f.delete() in finally block of writeTo() and readFrom() because "test.png" is shared resource between the methods. So I am deleting "test.png" at places where we are throwing RumtimeException. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jul 12 12:05:21 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 12 Jul 2016 17:35:21 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux Message-ID: <5784DD01.4040309@oracle.com> Hi All, Please review a fix for an issue where it is seen that if user sets invalid imageablearea via Paper.setImageableArea and then calls PrinterJob.validatePage() in linux, then it does not get a valid pageformat Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ Fix is to check for margin as noted via CUPS ppdPageSize() and then calculate to find the valid margin in validatePaper() similar to what we do in native validatePaper() in windows. Regards Prasanta From jayathirth.d.v at oracle.com Tue Jul 12 16:15:33 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 12 Jul 2016 09:15:33 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java Message-ID: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> Hi, Thanks for your input Phil. I have made changes just to parse "FF FF"(Like "FF 00" or any marker without length)and not consider it as an invalid marker in skipImage() of JPEGImageReader.java. Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java from ProblemList.txt as part of fix. Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 Please find webrev for review for JDK9: http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ Thanks, Jay From: Phil Race Sent: Saturday, July 09, 2016 12:37 AM To: Jayathirth D V Cc: Jim Graham; 2d-dev Subject: Re: REG : JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java On 07/08/2016 04:08 AM, Jayathirth D V wrote: Hi, In HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8152672"JDK-8152672 we modified skipImage() in JpegImageReader.java and added tighter checks for parsing Jpeg data. We have to find any marker,0 or EOF after we find "FF" while parsing JPEG data. But in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160943"JDK-8160943 we have gap between APP0 marker and DQT(FF DB) marker which contains data "00 FF". APP0_End -> 00 FF -> FF DB(DQT) So after we skip APP0 marker we find two bytes of data which is "FF FF". In the present code we consider this as invalid marker. See https://www.w3.org/Graphics/JPEG/itu-t81.pdf B.1.1.2 Markers Markers serve to identify the various structural parts of the compressed data formats. Most markers start marker segments containing a related group of parameters; some markers stand alone. All markers are assigned two-byte codes: an X'FF' byte followed by a byte which is not equal to 0 or X'FF' (see Table B.1). Any marker may optionally be preceded by any number of fill bytes, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ which are bytes assigned code X'FF ^^^^^^^^^^^^^^^^^^^^^^ -phil. Because of this HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160943"JDK-8160943 is failing. Is the length of APP0 marker not valid in the image or we should not consider "FF FF" as invalid maker? Please let me know your input. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Jul 12 16:34:55 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 12 Jul 2016 09:34:55 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> Message-ID: <9236A380-22B3-42FA-82DB-1D0759E495BA@oracle.com> Hi Jay, Looks fine to me. Thanks, Brian On Jul 12, 2016, at 5:03 AM, Jayathirth D V wrote: > That?s very good thing to do as it will remove redundant f.delete(). > I have updated the webrev for review : > http://cr.openjdk.java.net/~jdv/7059970/webrev.02/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Jul 13 01:57:16 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Jul 2016 18:57:16 -0700 Subject: [OpenJDK 2D-Dev] REG : JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: <577FF9DE.8070101@oracle.com> References: <29b00640-a619-4c2f-9514-8079133ab87f@default> <577FF9DE.8070101@oracle.com> Message-ID: That doesn't appear to be happening in this case. If you take the APP0 marker lengths at face value, there are 3 APP0 markers. The first has a length that brings you to the second one. The second one has a length that takes you 2 bytes short of the next. The intervening bytes are 00,00 which do not follow the indicated rule, but are consistent with the fact that that data block contains hundreds of triplets of "ff 00 00" in a row. The third has a length that also is 2 bytes short before the next marker and the intervening bytes in that case are 00,ff which again does not follow the indicated rule, but is again consistent with the fact that the data block is hundreds of copies of the triplet "00 00 ff". In short, it appears that the file simply has 2 APP0 markers where the utility that constructed it forgot that the 2 size bytes are included in the length of the APP field. If you add 2 to each of those lengths to account for this assumption, then the file is perfectly formed with no fill bytes. Another reference says that FF are frequently used as fill bytes, but must not appear in entropy encoded data - meaning don't just randomly spew FF bytes into data that is traversed via searching (entropy encoded data is the only data that has no length field. It follows an SOS marker which has a length for some initial data, but immediately falls into entropy encoding where you have to scan for FF markers again). I don't see any evidence that this text is meant to allow an arbitrary set of FF bytes to be just insert before markers and even if it did, the file in question (thumbimg.jpg) has bytes other than FF inserted. Where did thumbimg.jpg come from? Are we sure that it is a validly constructed JPEG file? ...jim On 7/8/16 12:07 PM, Phil Race wrote: > On 07/08/2016 04:08 AM, Jayathirth D V wrote: >> >> Hi, >> >> >> >> In JDK-8152672 we modified skipImage() in JpegImageReader.java and >> added tighter checks for parsing Jpeg data. >> >> >> >> We have to find any marker,0 or EOF after we find "FF" while parsing JPEG data. >> >> But in JDK-8160943 we have gap between APP0 marker and DQT(FF DB) >> marker which contains data ?00 FF?. >> >> >> >> APP0_End -> 00 FF -> FF DB(DQT) >> >> >> >> So after we skip APP0 marker we find two bytes of data which is ?FF FF?. In the present code we consider this as >> invalid marker. >> > > See https://www.w3.org/Graphics/JPEG/itu-t81.pdf > > B.1.1.2 Markers > Markers serve to identify the various structural parts of the compressed data formats. > Most markers start marker segments containing a related group of parameters; > some markers stand alone. All markers are assigned two-byte codes: an > X?FF? byte followed by a byte which is not equal to 0 or X?FF? (see Table B.1). > Any marker may optionally be preceded by any number of fill bytes, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > which are bytes assigned code X?FF > ^^^^^^^^^^^^^^^^^^^^^^ > > -phil. > >> Because of this JDK-8160943 is failing. >> >> >> >> Is the length of APP0 marker not valid in the image or we should not consider ?FF FF? as invalid maker? >> >> Please let me know your input. >> >> >> >> Thanks, >> >> Jay >> > From james.graham at oracle.com Wed Jul 13 02:02:28 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Jul 2016 19:02:28 -0700 Subject: [OpenJDK 2D-Dev] REG : JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: References: <29b00640-a619-4c2f-9514-8079133ab87f@default> <577FF9DE.8070101@oracle.com> Message-ID: Having said that, MacOS preview is perfectly happy with opening thumbimg.jpg and displaying a big green rectangle (is that what the file is supposed to look like?), so we should probably successfully read the image. Have we tried to open it with any other file utilities to see if it is universally considered a valid JPEG? ...jim On 7/12/16 6:57 PM, Jim Graham wrote: > That doesn't appear to be happening in this case. If you take the APP0 marker lengths at face value, there are 3 APP0 > markers. The first has a length that brings you to the second one. The second one has a length that takes you 2 bytes > short of the next. The intervening bytes are 00,00 which do not follow the indicated rule, but are consistent with the > fact that that data block contains hundreds of triplets of "ff 00 00" in a row. The third has a length that also is 2 > bytes short before the next marker and the intervening bytes in that case are 00,ff which again does not follow the > indicated rule, but is again consistent with the fact that the data block is hundreds of copies of the triplet "00 00 ff". > > In short, it appears that the file simply has 2 APP0 markers where the utility that constructed it forgot that the 2 > size bytes are included in the length of the APP field. If you add 2 to each of those lengths to account for this > assumption, then the file is perfectly formed with no fill bytes. > > Another reference says that FF are frequently used as fill bytes, but must not appear in entropy encoded data - meaning > don't just randomly spew FF bytes into data that is traversed via searching (entropy encoded data is the only data that > has no length field. It follows an SOS marker which has a length for some initial data, but immediately falls into > entropy encoding where you have to scan for FF markers again). > > I don't see any evidence that this text is meant to allow an arbitrary set of FF bytes to be just insert before markers > and even if it did, the file in question (thumbimg.jpg) has bytes other than FF inserted. > > Where did thumbimg.jpg come from? Are we sure that it is a validly constructed JPEG file? > > ...jim > > On 7/8/16 12:07 PM, Phil Race wrote: >> On 07/08/2016 04:08 AM, Jayathirth D V wrote: >>> >>> Hi, >>> >>> >>> >>> In JDK-8152672 we modified skipImage() in JpegImageReader.java and >>> added tighter checks for parsing Jpeg data. >>> >>> >>> >>> We have to find any marker,0 or EOF after we find "FF" while parsing JPEG data. >>> >>> But in JDK-8160943 we have gap between APP0 marker and DQT(FF DB) >>> marker which contains data ?00 FF?. >>> >>> >>> >>> APP0_End -> 00 FF -> FF DB(DQT) >>> >>> >>> >>> So after we skip APP0 marker we find two bytes of data which is ?FF FF?. In the present code we consider this as >>> invalid marker. >>> >> >> See https://www.w3.org/Graphics/JPEG/itu-t81.pdf >> >> B.1.1.2 Markers >> Markers serve to identify the various structural parts of the compressed data formats. >> Most markers start marker segments containing a related group of parameters; >> some markers stand alone. All markers are assigned two-byte codes: an >> X?FF? byte followed by a byte which is not equal to 0 or X?FF? (see Table B.1). >> Any marker may optionally be preceded by any number of fill bytes, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> which are bytes assigned code X?FF >> ^^^^^^^^^^^^^^^^^^^^^^ >> >> -phil. >> >>> Because of this JDK-8160943 is failing. >>> >>> >>> >>> Is the length of APP0 marker not valid in the image or we should not consider ?FF FF? as invalid maker? >>> >>> Please let me know your input. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >> From james.graham at oracle.com Wed Jul 13 02:40:32 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Jul 2016 19:40:32 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <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> Message-ID: Hi Jay, When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It looks like you copied and pasted a number of places where I wrote "{foo}" in email and just left the bare braces there, please adjust those (most of them should probably just have "@code" inserted. In ColorModel.equals(), I'd replace the entire "following properties" sentence with: * Subclasses may check additional properties, but this method * will check the following basic properties for equivalence to * determine if the target object equals this object: The text for IndexColorModel is also a little odd. I'd change it to something like: * The target object and this object will be equal iff * {@link ColorModel#equals()} returns true and the following * properties are also the same: For Packed: * The target object and this object will be equal iff * {@link ColorModel#equals()} returns true and the masks * of the color and alpha samples are the same. In terms of Joe's request, I'd add the following text to ColorModel.equals() right after we talk about all of the properties that it checks: *

* Subclasses should override this method if they have any additional * properties to compare and should use the following implementation. * Note that the base {@code ColorModel} class already ensures that * the target object is the same class as this object so the cast to * the subclass type can be assumed if {@code super.equals(obj)} returns * true. * 

*     public boolean equals(Object obj) {
*         if (!super.equals(obj)) {
*             return false;
*         }
*         MyCMClass cm = (MyCMClass) obj;
*         // test additional properties on "cm" and "this"
*     }
*
On 7/1/16 3:31 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your inputs. > I have discussed with Phil also regarding the same issue offline. > I have collated all the changes mentioned by you and Phil in the latest webrev: > http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ > > But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. > > Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, June 30, 2016 4:05 AM > 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 > > Hi Jay, > > We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: > > "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" > > Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. > > A few grammar fixes: > > In all of the classes, insert a space before any parentheses in comment text as in "the same class (and not a subclass)". (That wouldn't apply if the text in the comment is referring to code - then space it as you would actual code.) > > In CM, insert the word "the" as in "also check the following ..." > > In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". > > In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". > > ...jim > > On 06/29/2016 04:13 AM, Jayathirth D V wrote: >> Hi, >> >> Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Saturday, June 04, 2016 4:52 AM >> To: Jayathirth D V; Philip Race >> Cc: 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 >> >> That looks good to me. Has the CCC cleared yet? >> >> ...jim >> >> On 6/3/16 2:49 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Oh that's an important change. >>> Thanks for your review. >>> >>> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, June 03, 2016 2:25 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>> are missing hashCode() or equals() or both methods >>> >>> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >>> >>> Possible solutions: >>> >>> - Truncate validBits when it is accepted in the constructor >>> (validBits.and(...)) >>> - Manually compute the hash of the first N bits of validBits >>> - Not use validBits in the hash code since it is allowed to omit >>> significant data from the hash >>> >>> (Note that everything in hashcode must participate in equals(), but >>> not vice versa) >>> >>> The same is true of nBits in ColorModel. (nBits can be copied and >>> truncated with Arrays.copyOf) >>> >>> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >>> >>> ...jim >>> >>> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>>> Hi Phil, >>>> >>>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>>> Please find the updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Philip Race >>>> Sent: Wednesday, June 01, 2016 10:06 PM >>>> To: Jayathirth D V >>>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>> are missing hashCode() or equals() or both methods >>>> >>>> Please post the updated webrev. >>>> >>>> -phil. >>>> >>>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>>> Hi Phil& Jim, >>>>> >>>>> Collating all the changes needed: >>>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>>> 3) Comment section of equals() method, I will update it to : >>>>> 1449 * the target object must be the same class (and not a subclass) as this >>>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>>> >>>>> Please let me know your inputs. >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>>> To: Phil Race >>>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>> are missing hashCode() or equals() or both methods >>>>> >>>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>>> >>>>> ...jim >>>>> >>>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>>> I don't know of any design intent, so yes, I meant more as a >>>>>> practical matter. >>>>>> Unless they subclass then using equals() which I thought unlikely >>>>>> it makes no difference here. >>>>>> But it would be proof against that to use equals, unlikely to >>>>>> matter as it might be .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>>> >>>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>>> Hi Jay, >>>>>>>>> >>>>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>>>> you simply removed it from the patch. You still need to edit >>>>>>>>> it to remove the existing methods. >>>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>>>> not intentional. >>>>>>>> >>>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>>> instances >>>>>>>>> - Phil? >>>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>>> hashCode and all the predefined ones are constructed as >>>>>>>> singletons so it seems unlikely to cause problems >>>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>>> baking in the assumption that it doesn't implement equals() into >>>>>>> our implementation of the CM.equals() method. Might it some day >>>>>>> implement equals (perhaps it isn't a practical issue today, but >>>>>>> it might be in the future when we forget that it was omitted in >>>>>>> this usage we create today). >>>>>>> >>>>>>> I guess what I'm asking is if it is a design feature that >>>>>>> different objects are considered non-equal (such as an object >>>>>>> that, for instance, has only predetermined instances that are >>>>>>> shared by reference and reused). I think color spaces are sort >>>>>>> of in-between in that we define a few constants that simply get >>>>>>> used by reference in 99% of cases, but that isn't a design >>>>>>> feature, more like a practical issue... >>>>>>> >>>>>>> ...jim From james.graham at oracle.com Wed Jul 13 02:42:16 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Jul 2016 19:42:16 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> <5775AFF8.5060006@oracle.com> Message-ID: <54e2524f-2c0e-03f6-610d-ef55c27102b5@oracle.com> What does the compClip end up being in that case? ...jim On 7/4/16 1:12 AM, Sergey Bylokhov wrote: > On 01.07.16 2:49, Jim Graham wrote: >> How is it returning true? If the clip really is empty, then >> intersectsQuickCheck() should never return true. Or are you saying that >> an empty clip shape produces a non-empty composite clip region? > > > This code will test such situation: > BufferedImage bi = new BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); > Graphics2D graphics = bi.createGraphics(); > graphics.scale(1.5, 1.5); > graphics.setClip(1, 1, 0, 0); > System.out.println("empty = " + graphics.getClip().getBounds2D().isEmpty()); > boolean hit = graphics.hitClip(1, 1, 1, 1); > System.out.println("hit = " + hit); > > if "graphics.scale(1.5, 1.5);" will be removed then correct false will be printed. In both cases the clip will be empty > but hitCLip will return different result in case of scaled SG2D. > >> >> ...jim >> >> On 06/30/2016 10:02 AM, Sergey Bylokhov wrote: >>> It looks strange that the empty clip became "non-empty"(at least hitClip >>> reports this) when we apply transform to it, no? I guess that at the >>> beginning of hitClip() we should check that the clip.isEmpty(), and we >>> should return "false" in this case(I think this is not strictly related >>> to this bug)? >>> >>> On 24.06.16 1:14, Jim Graham wrote: >>>> Think of this method as asking: >>>> >>>> I don't want you to waste a lot of time, but tell me if it is silly for >>>> me to even consider rendering something with these bounds. >>>> >>>> And the answer is either "Oh, yeah, it is inconceivable that those >>>> bounds would be rendered", or "Not sure, maybe, just render it and >>>> see". There may be some cases where it knows "I know for sure that lots >>>> of stuff will render through the clip", but that is not where the >>>> divining line is here in terms of when the answer becomes true - it >>>> becomes true when there is a chance that it might render something. >>>> >>>> Arguably, the user-space comparison against the user-space clip that you >>>> added here can never be accurate even if you allow for "false >>>> positives". The clip is rasterized and whole pixels are chosen based on >>>> various criteria that affect clip rasterization. Thus, while the >>>> theoretical clip is at N.5, our rasterization choice has us render >>>> anything that hits pixel N, even if the contribution of the rendered >>>> primitive is only for the first half of N. That pixel might be rendered >>>> if anything hits any part of it, depending on what rendering operation >>>> is being done. >>>> >>>> So, your "fix" actually breaks the functionality because it is quite >>>> possible that something with a bounding box that stops before N.5 might >>>> affect pixel N and cause it to be rendered even though your new answer >>>> suggested that it wouldn't happen. Your code might actually cause a >>>> bug, not fix one. >>>> >>>> (There are also some potential theoretical failures related to how AA >>>> and STROKE_CONTROL might perturb our rendering, effects which are ignore >>>> by the current implementation of hitClip(), however I believe that all >>>> of those effects fit within the current implementation - it's just that >>>> I don't think anyone has ever proven this, or written an exhaustive test >>>> suite to verify that none of our rendering hints can perturb rendering >>>> by enough to create some surprises here...) >>>> >>>> ...jim >>>> >>>> On 6/23/16 3:00 PM, Jim Graham wrote: >>>>> Since "return true" would be a compliant implementation of >>>>> Graphics.hitClip(), this is not a bug... >>>>> >>>>> Read the documentation, it is allowed to use fast math that can return >>>>> true when technically the answer is false... >>>>> >>>>> ...jim >>>>> >>>>> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>>>>> >>>>>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and >>>>>> call the hitClip() with the passed rectangle [x=0, >>>>>> y=0, width=5, height=5]. >>>>>> >>>>>> The result is false for the graphics with scale 1 and true if the >>>>>> scale is floating point 1.5. >>>>>> >>>>>> This is because the transformed clip which has floating point >>>>>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>>>>> with rounded down upper-left and rounded up lower-right corners [7, >>>>>> 7, 8, 8] which now intersects with the transformed >>>>>> rectangle [0, 0, 7.5, 7.5]. >>>>>> >>>>>> The proposed fix adds additional check for the user clip and the >>>>>> user rectangle intersection if the intersection with >>>>>> the region clip passes. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>> >>> > > From james.graham at oracle.com Wed Jul 13 02:48:17 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Jul 2016 19:48:17 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> References: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> Message-ID: I think this is fine, but I noticed that some of the recently added comments have some grammar issues. It might be nice to change the following: 565 // markers which do not contain length data (doesn't => do not) 576 // markers which contain length data (contains => contain) I don't need to review those changes... ...jim On 7/12/16 9:15 AM, Jayathirth D V wrote: > Hi, > > > > Thanks for your input Phil. > > I have made changes just to parse ?FF FF?(Like ?FF 00? or any marker without length)and not consider it as an invalid > marker in skipImage() of JPEGImageReader.java. > > Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java from ProblemList.txt as part of fix. > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 > > > > Please find webrev for review for JDK9: > > http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ > > > > Thanks, > > Jay > > > > *From:*Phil Race > *Sent:* Saturday, July 09, 2016 12:37 AM > *To:* Jayathirth D V > *Cc:* Jim Graham; 2d-dev > *Subject:* Re: REG : JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java > > > > On 07/08/2016 04:08 AM, Jayathirth D V wrote: > > Hi, > > > > In JDK-8152672 we modified skipImage() in JpegImageReader.java > and added tighter checks for parsing Jpeg data. > > > > We have to find any marker,0 or EOF after we find "FF" while parsing JPEG data. > > But in JDK-8160943 we have gap between APP0 marker and DQT(FF DB) > marker which contains data ?00 FF?. > > > > APP0_End -> 00 FF -> FF DB(DQT) > > > > So after we skip APP0 marker we find two bytes of data which is ?FF FF?. In the present code we consider this as > invalid marker. > > > See https://www.w3.org/Graphics/JPEG/itu-t81.pdf > > B.1.1.2 Markers > Markers serve to identify the various structural parts of the compressed data formats. > Most markers start marker segments containing a related group of parameters; > some markers stand alone. All markers are assigned two-byte codes: an > X?FF? byte followed by a byte which is not equal to 0 or X?FF? (see Table B.1). > Any marker may optionally be preceded by any number of fill bytes, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > which are bytes assigned code X?FF > ^^^^^^^^^^^^^^^^^^^^^^ > > -phil. > > > Because of this JDK-8160943 is failing. > > > > Is the length of APP0 marker not valid in the image or we should not consider ?FF FF? as invalid maker? > > Please let me know your input. > > > > Thanks, > > Jay > > > From prasanta.sadhukhan at oracle.com Wed Jul 13 07:04:36 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 13 Jul 2016 12:34:36 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> Message-ID: <5785E804.7010005@oracle.com> Hi Jay, Why do we need to catch and throw RuntimeExcpn? try { } catch (RuntimeException e) { throw e; } Can't we just do try { } finally { } and let the exception be thrown naturally without being caught and rethrown? Regards Prasanta On 7/12/2016 5:33 PM, Jayathirth D V wrote: > > Hi Brian, > > That?s very good thing to do as it will remove redundant f.delete(). > > I have updated the webrev for review : > > http://cr.openjdk.java.net/~jdv/7059970/webrev.02/ > > > Thanks, > > Jay > > *From:*Brian Burkhalter > *Sent:* Friday, July 08, 2016 11:35 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test > case: javax/imageio/plugins/png/ITXtTest.java is not closing a file > > Hi Jay, > > Sorry to be picky here but in doTest() could you not instead have > > try { > > writeTo(file, src); > > ITXtTest dst = readFrom(file); > > if (dst == null || !dst.equals(src)) { > > throw new RuntimeException("Test failed."); > > } > > } catch (RuntimeException re) { > > throw re; > > } finally { > > file.delete(); > > } > > System.out.println("Test passed."); > > and therefore remove f.delete() from writeTo() and readFrom()? > > Thanks, > > Brian > > On Jul 8, 2016, at 12:04 AM, Jayathirth D V > wrote: > > > > I can?t perform f.delete() in finally block of writeTo() and > readFrom() because ?test.png? is shared resource between the > methods. So I am deleting ?test.png? at places where we are > throwing RumtimeException. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jul 13 08:53:45 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 13 Jul 2016 14:23:45 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8161264: RasterPrinterJob.updateAttributesWithPageFormat does redundant check In-Reply-To: <576AB0BD.7050506@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> <5761E7A9.1010805@oracle.com> <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> <576AB0BD.7050506@oracle.com> Message-ID: <57860199.8010208@oracle.com> Hi All, Please review a code cleanup for a redundant code introduced in the below 6601097 fix via webrev.03. Bug: https://bugs.openjdk.java.net/browse/JDK-8161264 webrev: http://cr.openjdk.java.net/~psadhukhan/8161264/webrev.00/ This code is redundant because irrespective of iw/ih being *negative* or *0*, MediaPrintableArea constructor called just after @line 692 will throw IAE which is consumed and thereafter this invalid mpa value is not propagated anymore and we will fallback to Java default paper margin of 1". So, there is no need of checking for iw/ih for negative and set it to 0 . Regards Prasanta On 6/22/2016 9:07 PM, Philip Race wrote: > +1 .. they won't get any output with a zero-width imageable area > but this is last ditch fix up of excessively bad values. > > -phil. > > On 6/16/16, 11:32 PM, prasanta sadhukhan wrote: >> >> Hi Phil, >> >> Ok. I have added a check for this case in which it will fall back to >> default values since >> if ix/iy is too large then we probably will not get anything to print >> inside printable area if we have to leave same margin on the >> right/bottom of the paper. >> validatePaper() does not check for ix/iy too large case. >> >> Modified webrev >> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.03/ >> >> Regards >> Prasanta >> On 6/16/2016 5:11 AM, Philip Race wrote: >>> I did say so long as the "ix/iy" are also valid. Which means not >>> just positive but that they >>> are not too large. Consider >>> if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); >>> >>> if we have ix = 500 and iw = -20 for a paper with width 800 this >>> will result >>> in iw = 800 - (500*2) = -200 .. >>> >>> -phil. >>> >>> On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> As discussed offline, regarding mpa modification in both >>>> setAttributes() and updateAttributesWithPageFormat, I found that >>>> updateAttributesWithPageFormat() will be called during pageDialog() >>>> and setPrintable() >>>> whereas setAttributes() will be called during print() and >>>> setAttributes() called validatePaper() to validate imageable >>>> values, so in that regard, setAttributes() has final say in >>>> validating and updating invalid mpa values. >>>> >>>> Regarding bug, I found that if we have -ve width/height, >>>> MediaPrintable constructor throws IAE if width/height is -ve so mpa >>>> values set by user will not be added to pageAttributes (even if >>>> there was valid x,y mpa values) >>>> therefore we fallback to Java default paper size and so we will get >>>> mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() >>>> so to avoid IAE and to use user-set valid values, I have modified >>>> the code to constrain iw/ih with requested ix/iy as you suggested. >>>> >>>> Please find the modified webrev: >>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ >>>> >>>> Regards >>>> Prasanta >>>> On 5/31/2016 10:12 PM, Phil Race wrote: >>>>> Well ... few printers can print on the entire paper. Photo >>>>> printers are >>>>> the ones that can do this. So Paper dimension minus the "hardware >>>>> margins" >>>>> are the maximum imageable width. >>>>> And then supposing imageable x/y is some perfectly reasonable >>>>> value like 1" each >>>>> then you've set iw/ih such that even a printer with zero hardware >>>>> margins has >>>>> an imageable area that goes off the bottom and right off the paper. >>>>> >>>>> More reasonable would be to constrain iw/ih such that they work >>>>> with the >>>>> requested ix/iy - assuming they are also valid. >>>>> >>>>> If all else fails then just using the "default" set of values as >>>>> if the application >>>>> had not set any values would be better. >>>>> >>>>> -phil. >>>>> >>>>> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> I got it rectified. >>>>>> >>>>>> Please find the modified webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >>>>>> >>>>>> Regarding using entire width/height pf paper, I thought since >>>>>> imageable width/height is invalid we should make the entire paper >>>>>> as the imageable area.For invalid x,y we were making it to >>>>>> paper's top/left. >>>>>> Else what option do we have, should we calculate >>>>>> width[height]=abs(image[width][height]) instead? >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 5/25/2016 10:07 PM, Philip Race wrote: >>>>>>> It seems to me that you are using the wrong units. >>>>>>> You have not divided by DPI to get inches. >>>>>>> >>>>>>> Also I am not sure that the *entire* width/height of the paper >>>>>>> is what you want here >>>>>>> but that is secondary to the first issue >>>>>>> >>>>>>> -phil >>>>>>> >>>>>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for jdk9 which is a continuation of the fix >>>>>>>> of JDK-6543815. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>>>>>> >>>>>>>> 6543815 fix resets the x,y to 0 if they are negative before >>>>>>>> creating a MediaPrintableArea and the platform replaces it with >>>>>>>> hardware margins when printing. >>>>>>>> This works only if x/y is negative. >>>>>>>> But, If either width/height is negative alongwith x or y, then >>>>>>>> the margin is set to the java def 1 inch margin and not >>>>>>>> hardware margins. >>>>>>>> >>>>>>>> This is because width/height -ve results in IAE in >>>>>>>> MediaPrintableArea constructor and so values are ignored. >>>>>>>> Added a check for -ve width/height to make sure width/height >>>>>>>> are set to minimum paper width/height. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ushakov at jetbrains.com Wed Jul 13 09:33:04 2016 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Wed, 13 Jul 2016 12:33:04 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8147542 Linux: ClassCastException when repainting after display resolution change In-Reply-To: <1D7CBE9A-9FE3-4D4E-AA0B-F0303316976D@jetbrains.com> References: <1D7CBE9A-9FE3-4D4E-AA0B-F0303316976D@jetbrains.com> Message-ID: <9208F9C7-4151-4C83-8BC1-4DE654ADD910@jetbrains.com> Hi, Is there any concerns about this fix? Best Regards, Alexey > On 06 Jul 2016, at 15:22, Alexey Ushakov wrote: > > Hello Phil and Sergey, > > There is one more slightly different issue causing CCE in blit code. It happens quite often in IDEA. After looking through JBS I?ve found that the problem is still relevant for all current releases. Here is the fix that I?ve marked with the most recent JBS issue that we have for some time in our custom OpenJDK based runtime. Please have a look. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147542 > Webrev: http://cr.openjdk.java.net/~avu/JDK-8147542/webrev.00 > > Best Regards, > Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jul 13 11:33:39 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 13 Jul 2016 04:33:39 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <5785E804.7010005@oracle.com> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> <5785E804.7010005@oracle.com> Message-ID: <04a477dd-6633-491a-b3cc-e678ac846d2f@default> Hi Prasanta, There is no need to capture and throw the same excpetion.I have applied changes mentioned by you. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7059970/webrev.03/ Thanks, Jay From: Prasanta Sadhukhan Sent: Wednesday, July 13, 2016 12:35 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Hi Jay, Why do we need to catch and throw RuntimeExcpn? try { } catch (RuntimeException e) { throw e; } Can't we just do try { } finally { } and let the exception be thrown naturally without being caught and rethrown? Regards Prasanta On 7/12/2016 5:33 PM, Jayathirth D V wrote: Hi Brian, That's very good thing to do as it will remove redundant f.delete(). I have updated the webrev for review : http://cr.openjdk.java.net/~jdv/7059970/webrev.02/ Thanks, Jay From: Brian Burkhalter Sent: Friday, July 08, 2016 11:35 PM To: Jayathirth D V Cc: Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Hi Jay, Sorry to be picky here but in doTest() could you not instead have try { writeTo(file, src); ITXtTest dst = readFrom(file); if (dst == null || !dst.equals(src)) { throw new RuntimeException("Test failed."); } } catch (RuntimeException re) { throw re; } finally { file.delete(); } System.out.println("Test passed."); and therefore remove f.delete() from writeTo() and readFrom()? Thanks, Brian On Jul 8, 2016, at 12:04 AM, Jayathirth D V wrote: I can't perform f.delete() in finally block of writeTo() and readFrom() because "test.png" is shared resource between the methods. So I am deleting "test.png" at places where we are throwing RumtimeException. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jul 13 11:45:56 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 13 Jul 2016 17:15:56 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <04a477dd-6633-491a-b3cc-e678ac846d2f@default> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> <5785E804.7010005@oracle.com> <04a477dd-6633-491a-b3cc-e678ac846d2f@default> Message-ID: <578629F4.8060303@oracle.com> Looks good. Onlything is, in copyright you need to add a comma after 2016. Regards Prasanta On 7/13/2016 5:03 PM, Jayathirth D V wrote: > > Hi Prasanta, > > There is no need to capture and throw the same excpetion.I have > applied changes mentioned by you. > > Please find updated webrev for review : > > http://cr.openjdk.java.net/~jdv/7059970/webrev.03/ > > > Thanks, > > Jay > > *From:*Prasanta Sadhukhan > *Sent:* Wednesday, July 13, 2016 12:35 PM > *To:* Jayathirth D V > *Cc:* 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test > case: javax/imageio/plugins/png/ITXtTest.java is not closing a file > > Hi Jay, > > Why do we need to catch and throw RuntimeExcpn? > try { > } catch (RuntimeException e) { > throw e; > } > > Can't we just do > try { > } finally { > } > and let the exception be thrown naturally without being caught and > rethrown? > > Regards > Prasanta > > On 7/12/2016 5:33 PM, Jayathirth D V wrote: > > Hi Brian, > > That?s very good thing to do as it will remove redundant f.delete(). > > I have updated the webrev for review : > > http://cr.openjdk.java.net/~jdv/7059970/webrev.02/ > > > Thanks, > > Jay > > *From:*Brian Burkhalter > *Sent:* Friday, July 08, 2016 11:35 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : > Test case: javax/imageio/plugins/png/ITXtTest.java is not closing > a file > > Hi Jay, > > Sorry to be picky here but in doTest() could you not instead have > > try { > > writeTo(file, src); > > ITXtTest dst = readFrom(file); > > if (dst == null || !dst.equals(src)) { > > throw new RuntimeException("Test failed."); > > } > > } catch (RuntimeException re) { > > throw re; > > } finally { > > file.delete(); > > } > > System.out.println("Test passed."); > > and therefore remove f.delete() from writeTo() and readFrom()? > > Thanks, > > Brian > > On Jul 8, 2016, at 12:04 AM, Jayathirth D V > > wrote: > > > > > I can?t perform f.delete() in finally block of writeTo() and > readFrom() because ?test.png? is shared resource between the > methods. So I am deleting ?test.png? at places where we are > throwing RumtimeException. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jul 13 12:03:19 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 13 Jul 2016 05:03:19 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file In-Reply-To: <578629F4.8060303@oracle.com> References: <1f78fdf3-2048-4622-b9f5-28a1b98ecba9@default> <2789305C-BED1-4A9C-9493-649AE8170748@oracle.com> <577EBAFB.1070503@oracle.com> <4D2A42A9-D58B-49CD-B817-7F1E99050C35@oracle.com> <429e0015-c16f-4c25-ad1a-b2b684b796a8@default> <5785E804.7010005@oracle.com> <04a477dd-6633-491a-b3cc-e678ac846d2f@default> <578629F4.8060303@oracle.com> Message-ID: Hi Prasanta, Please find updated webrev for reference : http://cr.openjdk.java.net/~jdv/7059970/webrev.04/ Thanks, Jay From: Prasanta Sadhukhan Sent: Wednesday, July 13, 2016 5:16 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Looks good. Onlything is, in copyright you need to add a comma after 2016. Regards Prasanta On 7/13/2016 5:03 PM, Jayathirth D V wrote: Hi Prasanta, There is no need to capture and throw the same excpetion.I have applied changes mentioned by you. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7059970/webrev.03/ Thanks, Jay From: Prasanta Sadhukhan Sent: Wednesday, July 13, 2016 12:35 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Hi Jay, Why do we need to catch and throw RuntimeExcpn? try { } catch (RuntimeException e) { throw e; } Can't we just do try { } finally { } and let the exception be thrown naturally without being caught and rethrown? Regards Prasanta On 7/12/2016 5:33 PM, Jayathirth D V wrote: Hi Brian, That's very good thing to do as it will remove redundant f.delete(). I have updated the webrev for review : http://cr.openjdk.java.net/~jdv/7059970/webrev.02/ Thanks, Jay From: Brian Burkhalter Sent: Friday, July 08, 2016 11:35 PM To: Jayathirth D V Cc: Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7059970 : Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file Hi Jay, Sorry to be picky here but in doTest() could you not instead have try { writeTo(file, src); ITXtTest dst = readFrom(file); if (dst == null || !dst.equals(src)) { throw new RuntimeException("Test failed."); } } catch (RuntimeException re) { throw re; } finally { file.delete(); } System.out.println("Test passed."); and therefore remove f.delete() from writeTo() and readFrom()? Thanks, Brian On Jul 8, 2016, at 12:04 AM, Jayathirth D V wrote: I can't perform f.delete() in finally block of writeTo() and readFrom() because "test.png" is shared resource between the methods. So I am deleting "test.png" at places where we are throwing RumtimeException. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jul 13 16:55:50 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Jul 2016 09:55:50 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <7b6a9f76-167a-490d-ac4c-aa24e6623107@default> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> <577402C7.6040505@oracle.com> <205fd1cb-2765-44b1-a905-5b722bf99c96@default> <577EB9DA.7070202@oracle.com> <7b6a9f76-167a-490d-ac4c-aa24e6623107@default> Message-ID: <57867296.7080402@oracle.com> Much cleaner .. although I also do not think we need to explicitly delete the local refs in Java_sun_awt_Win32FontManager_populateFontFileNameMap0 since the return will do that. And a little clean up .. the variable fontKeyName does not seem to be needed any more. Just directly use FONTKEY_NT. -phil. On 7/11/16, 12:02 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > A quick follow-up on the bug fix for : JDK-8152971 JNI Warning with -Xcheck:jni > > First, Thanks to Phil for the time in review and detailed explanation. > > To answer the question - > "The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. same for the direct calls to deletelocalref. Do you get any JNI warnings if you remove these ? " > Answer : > Yes., I see the warnings if DeleteLocalRef is not invoked on objects created in the callback functions. > It is in these callback functions that many objects get created without a corresponding release api. > No warnings were seen when releaseGdiFontMapReferences() was taken out. > This function is removed in the latest change. > The behavior could be attributed to two points > a. FontMap having most of its references to jObjects that are on stack (as arguments to function). > b. Very few references to local objects are created in the parent JNI function ( 2 - 3 classIDs ) > > To Summarize the Changes > . In all callback functions, the DeleteLocalRef calls have been reorganized to avoid cluttering before return statements. > . releaseGdiFontMapReferences() function has been removed. > The only font map reference that is released in latest code - is the reference to jClass object along with other classID references. This could be avoided but has been retained as a safe measure. > > The changes are available under webrev link: > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.04/ > > Kindly review at your convenient time and provide your suggestions. > > Thanks for your review& feedback > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Phil Race > Sent: Friday, July 08, 2016 1:52 AM > To: Prahalad Kumar Narayanan > Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Jayathirth D V; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > > So far as I can see we can eliminate at least some of the clutter of the calls to deletelocalreference by simply doing it as soon as we are done with the reference > > eg > > 309 familyLC = (*env)->CallObjectMethod(env, fmi->family, > 310 fmi->toLowerCaseMID, fmi->locale); > > > can be immediately followed by : > DeleteLocalReference(env, familyLC); > > > .. whether or not there is a pending exception. > > and > > 343 (*env)->CallObjectMethod(env, fmi->familyToFontListMap, > 344 fmi->putMID, familyLC, fmi->list); > > can be immediately followed by : > > DeleteLocalReference(env, fmi->family); > DeleteLocalReference(env, fmi->list); > > .. whether or not there is a pending exception. > > and so on. > > releaseGdiFontMapReferences() seems to be used right before returning to Java. > The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. > same for the direct calls to deletelocalref. > Do you get any JNI warnings if you remove these ? > > > I could even argue that some of the ones before return (0) from the enum functions which will cause us to then exit up the call stack fall into the same bucket but if you can simplify the change as I suggest it'll be easier to sort that out as there'll be less noise. > > > -phil. > > > On 07/04/2016 02:43 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> Good day to you. >> >> A quick follow-up on the fix for >> Bug ID : JDK-8152971 >> Title : -Xcheck:jni - WARNING in native method >> >> Thanks to Phil for his feedback. >> The feedback was not only detailed.. but contained important links for reference. >> >> I 've incorporated the review suggestions and have updated the webrev. >> Brief on changes from previous revision: >> >> 1. Once an exception has been found in an Up-call, the exception is ' not ' consumed or cleared now. >> . As Phil rightly said, this will pave way for the Java methods to know of the exceptions and handle them. >> >> 2. In addition to point No.1, The GDI's callback functions return zero '0' during an exception. >> . This will stop the subsequent enumeration of fonts& >> calls to registered callbacks through the APIs >> >> 3. Since exceptions are not consumed, all GDI 's callback functions are checked for pending exceptions at the entry. >> . On pending exceptions, the GDI's callback functions return immediately. >> . This prevents the functions from invoking any other JNI calls that could be un-safe during a pending exception >> . The callback functions merely release any local reference held before returning to caller. >> >> 4. Since we no longer support Win98, the obsolete ANSI versions of functions (~A functions) have been removed. >> . Functions that work with Unicode strings invoking Unicode versions of Windows APIs (~W functions) are retained. >> >> 5. The jtreg shell script has been modified to execute on all platforms after testing its execution on Windows, Linux, Mac and SunOS. >> . Just to re-iterate: The jtreg script fails on windows and solaris but in java.lang codebase. >> . A bug is already Open indicating JNI warnings in java.lang package. Hence this change does not introduce any new issues. >> >> As with any proposed webrev: >> . The changes were run through internal build system to ensure safe build on all supported OS versions. >> . JCK and JTREG test cases were run to ensure no conformance or regression failures occur. >> >> Kindly review the changes at your convenience and provide your feedback. >> . Updated webrev link: >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.03/ >> >> Thank you for your time& effort in review Have a good day >> >> Prahalad N. >> >> ---------------------------------------------------------------------- >> ------ >> From: Philip Race >> Sent: Wednesday, June 29, 2016 10:48 PM >> To: Prasanta Sadhukhan >> Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Jayathirth D V; >> Praveen Srivastava >> Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with >> -Xcheck:jni >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design >> .html#exception_handling >> >> lists DeleteLocalRef as safe to call with a pending exception. >> >> So here ... >> 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, >> 175 fmi->toLowerCaseMID, fmi->locale); >> 176 if ((*env)->ExceptionCheck(env)) { >> 177 (*env)->ExceptionClear(env); >> 178 /* Delete the created references */ >> 179 DeleteLocalReference(env, fullname); >> 180 return 1; >> 181 } >> >> ... perhaps what we should do is not clear the exception and with the >> goal that after returning from this function we can check in the >> caller for a pending exception and return from JNI to Java *without >> clearing it* - so that Java code gets that exception propagated. I >> suggest this because I think we would have a correctness issue which >> should be reported - not swallowed - if there ever really was one. >> >> I think this means that the GDI callbacks need to check for a pending >> exception on entry and bail since once we hand off to windows it may >> be called repeatedly. >> >> But also we should stop enumeration if we detect an error hence we >> should return 0 in this case, not 1 per the docs for EnumFontFamExProc >> >> --- >> https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs >> .85).aspx >> >> >> Return value >> >> The return value must be a nonzero value to continue enumeration; >> to stop enumeration, the return value must be zero. >> >> --- >> >> Also the "A" functions are now obsolete. No win 98 support any more >> :-) We should just delete them instead of updating them. >> >> And I'd prefer the test be verified on Solaris rather than excluding >> it >> >> -phil >> >> >> On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: >> Looks good to me. Only thing is in test script, you need to add copyright 2015, 2016 as the script is originally written in 2015 and you cannot omit the created year from the copyright. >> >> Regards >> Prasanta >> On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: >> >> Hello Everyone >> >> Good day to you. >> >> Quick follow up to fix for the Bug >> Bug ID : JDK-8152971 >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 >> >> First, Thanks to Prasanta for his review& suggestions. >> >> I 've incorporated some of the review suggestions& updated the webrev. >> Webrev Link : >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ >> >> Overview on changes from previous webrev: >> >> 1. Code Changes: As Prasanta mentioned, >> The variable fontStrLC should be used in place of fontStr - The correction has been taken up. >> And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. >> >> 2. With regard to deleting references held within GdiFontMapInfo struture >> JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass >> The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). >> >> 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. >> Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. >> The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. >> As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. >> Hence enabling the script on windows, doesn't introduce new bug. >> The only OS that the script doesn't run - Solaris. >> Presently, we don't have a Solaris environment at our facility to test the script. >> Hence the original functionality on Solaris is retained. >> >> Kindly take a look at the changes at your convenience& provide the suggestions. >> >> Thank you for your review >> Have a good day >> >> Prahalad N. >> >> ---------------------------------------------------------------------- >> ------ >> From: Prasanta Sadhukhan >> Sent: Monday, June 27, 2016 11:51 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Cc: Philip Race; Jayathirth D V; Praveen Srivastava >> Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with >> -Xcheck:jni >> >> I guess this method(s) should take "fontStrLC" instead of "fontStr" >> 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, >> 651 fontStr, fileStr); >> >> 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, >> 693 fontStr, fileStr); >> >> 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, >> 763 fontStr, fileStr); >> >> 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, >> 806 fontStr, fileStr); >> It seems this line is not needed as we have not populated fmi structure yet. >> 882 releaseGdiFontMapReferences(env,&fmi); >> >> Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? >> >> Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. >> Is there any particular need to restrict solaris too? >> >> Regards >> Prasanta >> >> >> On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Forum >> Good day to you. >> A Quick follow-up on webrev to fix the following issue >> Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method >> Bug Link : >> https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 >> Updated webrev link: >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ >> Description on Changes >> . The previous webrev contained changes to additional files which are not related to the current bug in concern. >> . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. >> Regarding Build& Test >> . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. >> . In addition, no new Jtreg failures were found with the proposed changes. >> Kindly review the changes at your convenience& provide your feedback. >> Thank you for your time in review >> Have a good day >> Prahalad N. >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Wednesday, June 22, 2016 3:20 PM >> To: 2d-dev at openjdk.java.net >> Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen >> Srivastava >> Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni >> Hello Everyone, on Java2D Group Good day to you. >> Please find herewith, webrev changes to fix the bug- >> Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 >> Webrev : >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ >> Description on Bug: >> 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni >> 2. The warnings can be classified into 2 categories >> a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) >> b. JNI warnings that are thrown due to increased usage of Local Reference objects. >> Description on the Fix: >> 1. File : FontPath.c >> Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. >> The checks are added only to the valid Up calls as per JNI spec. >> Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. >> A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. >> Therefore at each callback, the count of active local references would increase. >> Over time, the active local references would exceed the planned number of local references set by JVM. >> 2. File : awt_Component.cpp >> Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. >> Information on Jtreg test script is given below. >> 3. File : LoadFontsJNICheck.sh >> The shell script is already a part of JTreg test case& invokes LoadFontsJNICheck with -Xcheck:jni VM option >> However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. >> This way, the code changes can be checked for proper execution with test-case. >> Kindly review the changes at your convenience and share your feedback. >> Thank you for your time in review >> Have a good day >> Prahalad N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jul 13 17:06:00 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Jul 2016 10:06:00 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: References: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> Message-ID: <578674F8.1050905@oracle.com> Whilst looking at the reason this test was originally created https://bugs.openjdk.java.net/browse/JDK-4958271 it started to look likely that the image was (as I sort of suspected) was generated by IIO itself. I think there a couple of things we can do here 1) Open up the test (and image - although if moving it make sure no other tests in that location need the image). 2) Investigate to see if the bug such that the "bad padding" is written out is still reproducible with current IIO ... or if it was fixed sometime between when that image was created and now. -phil. On 7/12/16, 7:48 PM, Jim Graham wrote: > I think this is fine, but I noticed that some of the recently added > comments have some grammar issues. It might be nice to change the > following: > > 565 // markers which do not contain length data > (doesn't => do not) > > 576 // markers which contain length data > (contains => contain) > > I don't need to review those changes... > > ...jim > > On 7/12/16 9:15 AM, Jayathirth D V wrote: >> Hi, >> >> >> >> Thanks for your input Phil. >> >> I have made changes just to parse ?FF FF?(Like ?FF 00? or any marker >> without length)and not consider it as an invalid >> marker in skipImage() of JPEGImageReader.java. >> >> Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java >> from ProblemList.txt as part of fix. >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 >> >> >> >> Please find webrev for review for JDK9: >> >> http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ >> >> >> >> Thanks, >> >> Jay >> >> >> >> *From:*Phil Race >> *Sent:* Saturday, July 09, 2016 12:37 AM >> *To:* Jayathirth D V >> *Cc:* Jim Graham; 2d-dev >> *Subject:* Re: REG : JDK-8160943 : [PIT] new failure of >> closed/javax/imageio/ReadAllThumbnailsTest.java >> >> >> >> On 07/08/2016 04:08 AM, Jayathirth D V wrote: >> >> Hi, >> >> >> >> In JDK-8152672 >> we modified skipImage() in JpegImageReader.java >> and added tighter checks for parsing Jpeg data. >> >> >> >> We have to find any marker,0 or EOF after we find "FF" while >> parsing JPEG data. >> >> But in JDK-8160943 >> we have gap >> between APP0 marker and DQT(FF DB) >> marker which contains data ?00 FF?. >> >> >> >> APP0_End -> 00 FF -> FF DB(DQT) >> >> >> >> So after we skip APP0 marker we find two bytes of data which is >> ?FF FF?. In the present code we consider this as >> invalid marker. >> >> >> See https://www.w3.org/Graphics/JPEG/itu-t81.pdf >> >> B.1.1.2 Markers >> Markers serve to identify the various structural parts of the >> compressed data formats. >> Most markers start marker segments containing a related group of >> parameters; >> some markers stand alone. All markers are assigned two-byte codes: an >> X?FF? byte followed by a byte which is not equal to 0 or X?FF? (see >> Table B.1). >> Any marker may optionally be preceded by any number of fill bytes, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> which are bytes assigned code X?FF >> ^^^^^^^^^^^^^^^^^^^^^^ >> >> -phil. >> >> >> Because of this JDK-8160943 >> is failing. >> >> >> >> Is the length of APP0 marker not valid in the image or we should >> not consider ?FF FF? as invalid maker? >> >> Please let me know your input. >> >> >> >> Thanks, >> >> Jay >> >> >> From philip.race at oracle.com Wed Jul 13 17:22:06 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Jul 2016 10:22:06 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-5080830: SheetCollate is not handled properly by the cross platform print dlg In-Reply-To: <577E35E7.3030408@oracle.com> References: <577E35E7.3030408@oracle.com> Message-ID: <578678BE.6080609@oracle.com> +1 .. although the pattern used in the test to signal test completion is not one I've seen used before. Did you copy it from some other test ? On 7/7/16, 3:58 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that SheetCollate > option is enabled for flavors that do not support SheetCollate. > > Bug: https://bugs.openjdk.java.net/browse/JDK-5080830 > webrev: http://cr.openjdk.java.net/~psadhukhan/5080830/webrev.00/ > > Proposed fix to check for isAttributeValueSupported() to decide > whether to enable the SheetCollate option or not. > > Regards > Prasanta From philip.race at oracle.com Wed Jul 13 22:29:08 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 13 Jul 2016 15:29:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8054991 : sun.font.GlyphList uses broken double-checked locking In-Reply-To: <8477f52c-854c-480d-aa11-1ac7acfc0b1e@oracle.com> References: <574624AE.2040503@oracle.com> <8477f52c-854c-480d-aa11-1ac7acfc0b1e@oracle.com> Message-ID: <5786C0B4.60004@oracle.com> This almost got lost. I have updated the fix See http://cr.openjdk.java.net/~prr/8054991/ -phil. On 05/26/2016 05:23 AM, Alexey Ivanov wrote: > Hi Phil, > > Since reusableGL is written only once, I'm for marking the field final. > > The proposed patch is attached to JBS bug under the name 'pp'. > > Marking inUse field as volatile seems enough to fix the issue. However > the suggested patch makes code cleaner. > > > Regards, > Alexey > > On 26.05.2016 1:18, Phil Race wrote: >> bug : https://bugs.openjdk.java.net/browse/JDK-8054991 >> >> There is a comment in there about a proposed patch but I can't find it. >> However I think this will be sufficient :- >> >> diff --git a/src/java.desktop/share/classes/sun/font/GlyphList.java >> b/src/java.desktop/share/classes/sun/font/GlyphList.java >> --- a/src/java.desktop/share/classes/sun/font/GlyphList.java >> +++ b/src/java.desktop/share/classes/sun/font/GlyphList.java >> @@ -152,7 +152,7 @@ >> * created. >> */ >> private static GlyphList reusableGL = new GlyphList(); >> - private static boolean inUse; >> + private static volatile boolean inUse; >> >> -phil. > From prasanta.sadhukhan at oracle.com Thu Jul 14 05:04:07 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 14 Jul 2016 10:34:07 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-5080830: SheetCollate is not handled properly by the cross platform print dlg In-Reply-To: <578678BE.6080609@oracle.com> References: <577E35E7.3030408@oracle.com> <578678BE.6080609@oracle.com> Message-ID: <57871D47.6060704@oracle.com> On 7/13/2016 10:52 PM, Philip Race wrote: > +1 .. although the pattern used in the test to signal test > completion is not one I've seen used before. Did you copy > it from some other test ? > I noticed this pattern in one of existing JTable manual testcase when I was extending the testcase to add more subtest and have been using this for manual framework ever since. Regards Prasanta > On 7/7/16, 3:58 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that SheetCollate >> option is enabled for flavors that do not support SheetCollate. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-5080830 >> webrev: http://cr.openjdk.java.net/~psadhukhan/5080830/webrev.00/ >> >> Proposed fix to check for isAttributeValueSupported() to decide >> whether to enable the SheetCollate option or not. >> >> Regards >> Prasanta From prahalad.kumar.narayanan at oracle.com Thu Jul 14 08:34:50 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 14 Jul 2016 01:34:50 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <57867296.7080402@oracle.com> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> <577402C7.6040505@oracle.com> <205fd1cb-2765-44b1-a905-5b722bf99c96@default> <577EB9DA.7070202@oracle.com> <7b6a9f76-167a-490d-ac4c-aa24e6623107@default> <57867296.7080402@oracle.com> Message-ID: <226a855d-ac3c-4c1f-ae72-36f54e47d7a3@default> Hello Everyone Good day to you. A quick follow up on the bug fix for : JDK-8152971 First, Thanks to Phil for his time in review. I ?ve incorporated Phil ?s suggestions and the webrev with modifications are available under: Link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.05/ Quick Summary on the Changes: . Explicity deletion of local refs in Java_sun_awt_Win32FontManager_populateFontFileNameMap0 have been removed. . Since the references are not many, they will be reclaimed by JVM once JNI function returns . The variable fontKeyName has been removed and the constant string FONTKEY_NT has been used directly. Kindly review at your convenient time and share your feedback. Thanks for your time Have a good day Prahalad N. -----Original Message----- From: Philip Race Sent: Wednesday, July 13, 2016 10:26 PM To: Prahalad Kumar Narayanan Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni Much cleaner .. although I also do not think we need to explicitly delete the local refs in Java_sun_awt_Win32FontManager_populateFontFileNameMap0 since the return will do that. And a little clean up .. the variable fontKeyName does not seem to be needed any more. Just directly use FONTKEY_NT. -phil. On 7/11/16, 12:02 PM, Prahalad Kumar Narayanan wrote: Hello Everyone Good day to you. A quick follow-up on the bug fix for : JDK-8152971 JNI Warning with -Xcheck:jni First, Thanks to Phil for the time in review and detailed explanation. To answer the question - "The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. same for the direct calls to deletelocalref. Do you get any JNI warnings if you remove these ? " Answer : Yes., I see the warnings if DeleteLocalRef is not invoked on objects created in the callback functions. It is in these callback functions that many objects get created without a corresponding release api. No warnings were seen when releaseGdiFontMapReferences() was taken out. This function is removed in the latest change. The behavior could be attributed to two points a. FontMap having most of its references to jObjects that are on stack (as arguments to function). b. Very few references to local objects are created in the parent JNI function ( 2 - 3 classIDs ) To Summarize the Changes . In all callback functions, the DeleteLocalRef calls have been reorganized to avoid cluttering before return statements. . releaseGdiFontMapReferences() function has been removed. The only font map reference that is released in latest code - is the reference to jClass object along with other classID references. This could be avoided but has been retained as a safe measure. The changes are available under webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.04/ Kindly review at your convenient time and provide your suggestions. Thanks for your review & feedback Have a good day Prahalad N. -----Original Message----- From: Phil Race Sent: Friday, July 08, 2016 1:52 AM To: Prahalad Kumar Narayanan Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Jayathirth D V; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni So far as I can see we can eliminate at least some of the clutter of the calls to deletelocalreference by simply doing it as soon as we are done with the reference eg 309 familyLC = (*env)->CallObjectMethod(env, fmi->family, 310 fmi->toLowerCaseMID, fmi->locale); can be immediately followed by : DeleteLocalReference(env, familyLC); .. whether or not there is a pending exception. and 343 (*env)->CallObjectMethod(env, fmi->familyToFontListMap, 344 fmi->putMID, familyLC, fmi->list); can be immediately followed by : DeleteLocalReference(env, fmi->family); DeleteLocalReference(env, fmi->list); .. whether or not there is a pending exception. and so on. releaseGdiFontMapReferences() seems to be used right before returning to Java. The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. same for the direct calls to deletelocalref. Do you get any JNI warnings if you remove these ? I could even argue that some of the ones before return (0) from the enum functions which will cause us to then exit up the call stack fall into the same bucket but if you can simplify the change as I suggest it'll be easier to sort that out as there'll be less noise. -phil. On 07/04/2016 02:43 AM, Prahalad Kumar Narayanan wrote: Hello Everyone Good day to you. A quick follow-up on the fix for Bug ID : JDK-8152971 Title : -Xcheck:jni - WARNING in native method Thanks to Phil for his feedback. The feedback was not only detailed.. but contained important links for reference. I 've incorporated the review suggestions and have updated the webrev. Brief on changes from previous revision: 1. Once an exception has been found in an Up-call, the exception is ' not ' consumed or cleared now. . As Phil rightly said, this will pave way for the Java methods to know of the exceptions and handle them. 2. In addition to point No.1, The GDI's callback functions return zero '0' during an exception. . This will stop the subsequent enumeration of fonts & calls to registered callbacks through the APIs 3. Since exceptions are not consumed, all GDI 's callback functions are checked for pending exceptions at the entry. . On pending exceptions, the GDI's callback functions return immediately. . This prevents the functions from invoking any other JNI calls that could be un-safe during a pending exception . The callback functions merely release any local reference held before returning to caller. 4. Since we no longer support Win98, the obsolete ANSI versions of functions (~A functions) have been removed. . Functions that work with Unicode strings invoking Unicode versions of Windows APIs (~W functions) are retained. 5. The jtreg shell script has been modified to execute on all platforms after testing its execution on Windows, Linux, Mac and SunOS. . Just to re-iterate: The jtreg script fails on windows and solaris but in java.lang codebase. . A bug is already Open indicating JNI warnings in java.lang package. Hence this change does not introduce any new issues. As with any proposed webrev: . The changes were run through internal build system to ensure safe build on all supported OS versions. . JCK and JTREG test cases were run to ensure no conformance or regression failures occur. Kindly review the changes at your convenience and provide your feedback. . Updated webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.03/ Thank you for your time & effort in review Have a good day Prahalad N. ---------------------------------------------------------------------- ------ From: Philip Race Sent: Wednesday, June 29, 2016 10:48 PM To: Prasanta Sadhukhan Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Jayathirth D V; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design .html#exception_handling lists DeleteLocalRef as safe to call with a pending exception. So here ... 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, 175 fmi->toLowerCaseMID, fmi->locale); 176 if ((*env)->ExceptionCheck(env)) { 177 (*env)->ExceptionClear(env); 178 /* Delete the created references */ 179 DeleteLocalReference(env, fullname); 180 return 1; 181 } ... perhaps what we should do is not clear the exception and with the goal that after returning from this function we can check in the caller for a pending exception and return from JNI to Java *without clearing it* - so that Java code gets that exception propagated. I suggest this because I think we would have a correctness issue which should be reported - not swallowed - if there ever really was one. I think this means that the GDI callbacks need to check for a pending exception on entry and bail since once we hand off to windows it may be called repeatedly. But also we should stop enumeration if we detect an error hence we should return 0 in this case, not 1 per the docs for EnumFontFamExProc --- https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs .85).aspx Return value The return value must be a nonzero value to continue enumeration; to stop enumeration, the return value must be zero. --- Also the "A" functions are now obsolete. No win 98 support any more :-) We should just delete them instead of updating them. And I'd prefer the test be verified on Solaris rather than excluding it -phil On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: Looks good to me. Only thing is in test script, you need to add copyright 2015, 2016 as the script is originally written in 2015 and you cannot omit the created year from the copyright. Regards Prasanta On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: Hello Everyone Good day to you. Quick follow up to fix for the Bug Bug ID : JDK-8152971 Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 First, Thanks to Prasanta for his review & suggestions. I 've incorporated some of the review suggestions & updated the webrev. Webrev Link : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ Overview on changes from previous webrev: 1. Code Changes: As Prasanta mentioned, The variable fontStrLC should be used in place of fontStr - The correction has been taken up. And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. 2. With regard to deleting references held within GdiFontMapInfo struture JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. Hence enabling the script on windows, doesn't introduce new bug. The only OS that the script doesn't run - Solaris. Presently, we don't have a Solaris environment at our facility to test the script. Hence the original functionality on Solaris is retained. Kindly take a look at the changes at your convenience & provide the suggestions. Thank you for your review Have a good day Prahalad N. ---------------------------------------------------------------------- ------ From: Prasanta Sadhukhan Sent: Monday, June 27, 2016 11:51 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Cc: Philip Race; Jayathirth D V; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni I guess this method(s) should take "fontStrLC" instead of "fontStr" 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 651 fontStr, fileStr); 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 693 fontStr, fileStr); 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 763 fontStr, fileStr); 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 806 fontStr, fileStr); It seems this line is not needed as we have not populated fmi structure yet. 882 releaseGdiFontMapReferences(env, &fmi); Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. Is there any particular need to restrict solaris too? Regards Prasanta On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: Hello Everyone on Java2D Forum Good day to you. A Quick follow-up on webrev to fix the following issue Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 Updated webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ Description on Changes . The previous webrev contained changes to additional files which are not related to the current bug in concern. . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. Regarding Build & Test . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. . In addition, no new Jtreg failures were found with the proposed changes. Kindly review the changes at your convenience & provide your feedback. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Prahalad Kumar Narayanan Sent: Wednesday, June 22, 2016 3:20 PM To: 2d-dev at openjdk.java.net Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni Hello Everyone, on Java2D Group Good day to you. Please find herewith, webrev changes to fix the bug- Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 Webrev : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ Description on Bug: 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni 2. The warnings can be classified into 2 categories a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) b. JNI warnings that are thrown due to increased usage of Local Reference objects. Description on the Fix: 1. File : FontPath.c Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. The checks are added only to the valid Up calls as per JNI spec. Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. Therefore at each callback, the count of active local references would increase. Over time, the active local references would exceed the planned number of local references set by JVM. 2. File : awt_Component.cpp Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. Information on Jtreg test script is given below. 3. File : LoadFontsJNICheck.sh The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. This way, the code changes can be checked for proper execution with test-case. 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 prasanta.sadhukhan at oracle.com Thu Jul 14 09:09:38 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 14 Jul 2016 14:39:38 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4882305: StreamPrintServ.getSupportedAttributeValues returns null for Orientation attr Message-ID: <578756D2.1010801@oracle.com> Hi All, Please review a fix for an issue where it is seen that even though StreamPrintService returns OrientationRequested category as supported, when actually querying the supported attribute value with respect to the supported DocFlavors, *null* values are returned for the Orientation attributes when the DocFlavor is not either Pageable or Printable (SERVICE_FORMATTED) *BUT* we can print a jpeg iamge using StreamPrintService in LANDSCAPE mode and it worked fine so StreamPrintService should not return the supported values as null for supported DocFlavor. Bug: https://bugs.openjdk.java.net/browse/JDK-4882305 webrev: http://cr.openjdk.java.net/~psadhukhan/4882305/webrev.00/ Proposed fix is to add the image/jpeg, image/gif, image/png docflavor in addition to Pageable/Printable for Orientation attribute. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jul 14 09:44:12 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 09:44:12 +0000 Subject: [OpenJDK 2D-Dev] [ping] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. Message-ID: Hi, could someone please have a look at this? It's L, but the change is only one line in a lot of tests ... Thanks! Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 7. Juli 2016 17:01 > To: 'awt-dev at openjdk.java.net' ; swing- > dev at openjdk.java.net; '2d-dev' <2d-dev at openjdk.java.net> > Subject: RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. > > Hi, > > This change is 'L' because there are changes to a lot of files, but the changes > are all similar, so it's rather easy to review. > Similar to 8159690 I added @key headful to another around 600 tests. > I used different patterns to grep for the headful exceptions. > > These are now all I could find with grepping and the like. I have around > 80 failing tests remaining, where a row will probably also depend on > a display, but I want to look at them more closely, so I don't want > to include them here. > > Please review this change: > http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > > Best regards, > Goetz. From jayathirth.d.v at oracle.com Thu Jul 14 12:04:53 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Jul 2016 05:04:53 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-5080830: SheetCollate is not handled properly by the cross platform print dlg In-Reply-To: <57871D47.6060704@oracle.com> References: <577E35E7.3030408@oracle.com> <578678BE.6080609@oracle.com> <57871D47.6060704@oracle.com> Message-ID: Hi Prasanta, Changes are working fine. Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Thursday, July 14, 2016 10:34 AM To: Philip Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-5080830: SheetCollate is not handled properly by the cross platform print dlg On 7/13/2016 10:52 PM, Philip Race wrote: > +1 .. although the pattern used in the test to signal test > completion is not one I've seen used before. Did you copy it from some > other test ? > I noticed this pattern in one of existing JTable manual testcase when I was extending the testcase to add more subtest and have been using this for manual framework ever since. Regards Prasanta > On 7/7/16, 3:58 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that SheetCollate >> option is enabled for flavors that do not support SheetCollate. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-5080830 >> webrev: http://cr.openjdk.java.net/~psadhukhan/5080830/webrev.00/ >> >> Proposed fix to check for isAttributeValueSupported() to decide >> whether to enable the SheetCollate option or not. >> >> Regards >> Prasanta From alexey.ivanov at oracle.com Thu Jul 14 14:57:55 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 14 Jul 2016 17:57:55 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8054991 : sun.font.GlyphList uses broken double-checked locking In-Reply-To: <5786C0B4.60004@oracle.com> References: <574624AE.2040503@oracle.com> <8477f52c-854c-480d-aa11-1ac7acfc0b1e@oracle.com> <5786C0B4.60004@oracle.com> Message-ID: Looks good. Regards, Alexey On 14.07.2016 1:29, Phil Race wrote: > This almost got lost. I have updated the fix > > See http://cr.openjdk.java.net/~prr/8054991/ > > -phil. > > On 05/26/2016 05:23 AM, Alexey Ivanov wrote: >> Hi Phil, >> >> Since reusableGL is written only once, I'm for marking the field final. >> >> The proposed patch is attached to JBS bug under the name 'pp'. >> >> Marking inUse field as volatile seems enough to fix the issue. >> However the suggested patch makes code cleaner. >> >> >> Regards, >> Alexey >> >> On 26.05.2016 1:18, Phil Race wrote: >>> bug : https://bugs.openjdk.java.net/browse/JDK-8054991 >>> >>> There is a comment in there about a proposed patch but I can't find it. >>> However I think this will be sufficient :- >>> >>> diff --git a/src/java.desktop/share/classes/sun/font/GlyphList.java >>> b/src/java.desktop/share/classes/sun/font/GlyphList.java >>> --- a/src/java.desktop/share/classes/sun/font/GlyphList.java >>> +++ b/src/java.desktop/share/classes/sun/font/GlyphList.java >>> @@ -152,7 +152,7 @@ >>> * created. >>> */ >>> private static GlyphList reusableGL = new GlyphList(); >>> - private static boolean inUse; >>> + private static volatile boolean inUse; >>> >>> -phil. >> > From philip.race at oracle.com Thu Jul 14 18:04:38 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 14 Jul 2016 11:04:38 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <226a855d-ac3c-4c1f-ae72-36f54e47d7a3@default> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> <577402C7.6040505@oracle.com> <205fd1cb-2765-44b1-a905-5b722bf99c96@default> <577EB9DA.7070202@oracle.com> <7b6a9f76-167a-490d-ac4c-aa24e6623107@default> <57867296.7080402@oracle.com> <226a855d-ac3c-4c1f-ae72-36f54e47d7a3@default> Message-ID: <5787D436.3040306@oracle.com> Approved. -phil. On 07/14/2016 01:34 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > A quick follow up on the bug fix for : JDK-8152971 > > First, Thanks to Phil for his time in review. > > I ?ve incorporated Phil ?s suggestions and the webrev with modifications are available under: > Link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.05/ > > Quick Summary on the Changes: > . Explicity deletion of local refs in Java_sun_awt_Win32FontManager_populateFontFileNameMap0 have been removed. > . Since the references are not many, they will be reclaimed by JVM once JNI function returns > . The variable fontKeyName has been removed and the constant string FONTKEY_NT has been used directly. > > Kindly review at your convenient time and share your feedback. > > Thanks for your time > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Philip Race > Sent: Wednesday, July 13, 2016 10:26 PM > To: Prahalad Kumar Narayanan > Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > Much cleaner .. although I also do not think we need to explicitly > delete the local refs in > Java_sun_awt_Win32FontManager_populateFontFileNameMap0 > > since the return will do that. > > And a little clean up .. the variable fontKeyName does not > seem to be needed any more. Just directly use FONTKEY_NT. > > -phil. > > On 7/11/16, 12:02 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > A quick follow-up on the bug fix for : JDK-8152971 JNI Warning with -Xcheck:jni > > First, Thanks to Phil for the time in review and detailed explanation. > > To answer the question - > "The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. same for the direct calls to deletelocalref. Do you get any JNI warnings if you remove these ? " > Answer : > Yes., I see the warnings if DeleteLocalRef is not invoked on objects created in the callback functions. > It is in these callback functions that many objects get created without a corresponding release api. > No warnings were seen when releaseGdiFontMapReferences() was taken out. > This function is removed in the latest change. > The behavior could be attributed to two points > a. FontMap having most of its references to jObjects that are on stack (as arguments to function). > b. Very few references to local objects are created in the parent JNI function ( 2 - 3 classIDs ) > > To Summarize the Changes > . In all callback functions, the DeleteLocalRef calls have been reorganized to avoid cluttering before return statements. > . releaseGdiFontMapReferences() function has been removed. > The only font map reference that is released in latest code - is the reference to jClass object along with other classID references. This could be avoided but has been retained as a safe measure. > > The changes are available under webrev link: > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.04/ > > Kindly review at your convenient time and provide your suggestions. > > Thanks for your review & feedback > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Phil Race > Sent: Friday, July 08, 2016 1:52 AM > To: Prahalad Kumar Narayanan > Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Jayathirth D V; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > > So far as I can see we can eliminate at least some of the clutter of the calls to deletelocalreference by simply doing it as soon as we are done with the reference > > eg > > 309 familyLC = (*env)->CallObjectMethod(env, fmi->family, > 310 fmi->toLowerCaseMID, fmi->locale); > > > can be immediately followed by : > DeleteLocalReference(env, familyLC); > > > .. whether or not there is a pending exception. > > and > > 343 (*env)->CallObjectMethod(env, fmi->familyToFontListMap, > 344 fmi->putMID, familyLC, fmi->list); > > can be immediately followed by : > > DeleteLocalReference(env, fmi->family); > DeleteLocalReference(env, fmi->list); > > .. whether or not there is a pending exception. > > and so on. > > releaseGdiFontMapReferences() seems to be used right before returning to Java. > The issue with local refs is that you want to avoid too many so there is no need to do that release before return explicitly since the VM will do it for us. > same for the direct calls to deletelocalref. > Do you get any JNI warnings if you remove these ? > > > I could even argue that some of the ones before return (0) from the enum functions which will cause us to then exit up the call stack fall into the same bucket but if you can simplify the change as I suggest it'll be easier to sort that out as there'll be less noise. > > > -phil. > > > On 07/04/2016 02:43 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > A quick follow-up on the fix for > Bug ID : JDK-8152971 > Title : -Xcheck:jni - WARNING in native method > > Thanks to Phil for his feedback. > The feedback was not only detailed.. but contained important links for reference. > > I 've incorporated the review suggestions and have updated the webrev. > Brief on changes from previous revision: > > 1. Once an exception has been found in an Up-call, the exception is ' not ' consumed or cleared now. > . As Phil rightly said, this will pave way for the Java methods to know of the exceptions and handle them. > > 2. In addition to point No.1, The GDI's callback functions return zero '0' during an exception. > . This will stop the subsequent enumeration of fonts & > calls to registered callbacks through the APIs > > 3. Since exceptions are not consumed, all GDI 's callback functions are checked for pending exceptions at the entry. > . On pending exceptions, the GDI's callback functions return immediately. > . This prevents the functions from invoking any other JNI calls that could be un-safe during a pending exception > . The callback functions merely release any local reference held before returning to caller. > > 4. Since we no longer support Win98, the obsolete ANSI versions of functions (~A functions) have been removed. > . Functions that work with Unicode strings invoking Unicode versions of Windows APIs (~W functions) are retained. > > 5. The jtreg shell script has been modified to execute on all platforms after testing its execution on Windows, Linux, Mac and SunOS. > . Just to re-iterate: The jtreg script fails on windows and solaris but in java.lang codebase. > . A bug is already Open indicating JNI warnings in java.lang package. Hence this change does not introduce any new issues. > > As with any proposed webrev: > . The changes were run through internal build system to ensure safe build on all supported OS versions. > . JCK and JTREG test cases were run to ensure no conformance or regression failures occur. > > Kindly review the changes at your convenience and provide your feedback. > . Updated webrev link: > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.03/ > > Thank you for your time & effort in review Have a good day > > Prahalad N. > > ---------------------------------------------------------------------- > ------ > From: Philip Race > Sent: Wednesday, June 29, 2016 10:48 PM > To: Prasanta Sadhukhan > Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Jayathirth D V; > Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with > -Xcheck:jni > > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design > .html#exception_handling > > lists DeleteLocalRef as safe to call with a pending exception. > > So here ... > 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, > 175 fmi->toLowerCaseMID, fmi->locale); > 176 if ((*env)->ExceptionCheck(env)) { > 177 (*env)->ExceptionClear(env); > 178 /* Delete the created references */ > 179 DeleteLocalReference(env, fullname); > 180 return 1; > 181 } > > ... perhaps what we should do is not clear the exception and with the > goal that after returning from this function we can check in the > caller for a pending exception and return from JNI to Java *without > clearing it* - so that Java code gets that exception propagated. I > suggest this because I think we would have a correctness issue which > should be reported - not swallowed - if there ever really was one. > > I think this means that the GDI callbacks need to check for a pending > exception on entry and bail since once we hand off to windows it may > be called repeatedly. > > But also we should stop enumeration if we detect an error hence we > should return 0 in this case, not 1 per the docs for EnumFontFamExProc > > --- > https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs > .85).aspx > > > Return value > > The return value must be a nonzero value to continue enumeration; > to stop enumeration, the return value must be zero. > > --- > > Also the "A" functions are now obsolete. No win 98 support any more > :-) We should just delete them instead of updating them. > > And I'd prefer the test be verified on Solaris rather than excluding > it > > -phil > > > On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: > Looks good to me. Only thing is in test script, you need to add copyright 2015, 2016 as the script is originally written in 2015 and you cannot omit the created year from the copyright. > > Regards > Prasanta > On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: > > Hello Everyone > > Good day to you. > > Quick follow up to fix for the Bug > Bug ID : JDK-8152971 > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 > > First, Thanks to Prasanta for his review & suggestions. > > I 've incorporated some of the review suggestions & updated the webrev. > Webrev Link : > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ > > Overview on changes from previous webrev: > > 1. Code Changes: As Prasanta mentioned, > The variable fontStrLC should be used in place of fontStr - The correction has been taken up. > And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. > > 2. With regard to deleting references held within GdiFontMapInfo struture > JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass > The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). > > 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. > Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. > The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. > As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. > Hence enabling the script on windows, doesn't introduce new bug. > The only OS that the script doesn't run - Solaris. > Presently, we don't have a Solaris environment at our facility to test the script. > Hence the original functionality on Solaris is retained. > > Kindly take a look at the changes at your convenience & provide the suggestions. > > Thank you for your review > Have a good day > > Prahalad N. > > ---------------------------------------------------------------------- > ------ > From: Prasanta Sadhukhan > Sent: Monday, June 27, 2016 11:51 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Cc: Philip Race; Jayathirth D V; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with > -Xcheck:jni > > I guess this method(s) should take "fontStrLC" instead of "fontStr" > 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 651 fontStr, fileStr); > > 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 693 fontStr, fileStr); > > 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 763 fontStr, fileStr); > > 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 806 fontStr, fileStr); > It seems this line is not needed as we have not populated fmi structure yet. > 882 releaseGdiFontMapReferences(env, &fmi); > > Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? > > Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. > Is there any particular need to restrict solaris too? > > Regards > Prasanta > > > On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Forum > Good day to you. > A Quick follow-up on webrev to fix the following issue > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : > https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Updated webrev link: > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ > Description on Changes > . The previous webrev contained changes to additional files which are not related to the current bug in concern. > . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. > Regarding Build & Test > . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. > . In addition, no new Jtreg failures were found with the proposed changes. > Kindly review the changes at your convenience & provide your feedback. > Thank you for your time in review > Have a good day > Prahalad N. > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, June 22, 2016 3:20 PM > To: 2d-dev at openjdk.java.net > Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen > Srivastava > Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > Hello Everyone, on Java2D Group Good day to you. > Please find herewith, webrev changes to fix the bug- > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Webrev : > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ > Description on Bug: > 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni > 2. The warnings can be classified into 2 categories > a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) > b. JNI warnings that are thrown due to increased usage of Local Reference objects. > Description on the Fix: > 1. File : FontPath.c > Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. > The checks are added only to the valid Up calls as per JNI spec. > Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. > A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. > Therefore at each callback, the count of active local references would increase. > Over time, the active local references would exceed the planned number of local references set by JVM. > 2. File : awt_Component.cpp > Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. > Information on Jtreg test script is given below. > 3. File : LoadFontsJNICheck.sh > The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option > However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. > This way, the code changes can be checked for proper execution with test-case. > 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 prasanta.sadhukhan at oracle.com Fri Jul 15 05:49:32 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 15 Jul 2016 11:19:32 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <5787D436.3040306@oracle.com> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> <577402C7.6040505@oracle.com> <205fd1cb-2765-44b1-a905-5b722bf99c96@default> <577EB9DA.7070202@oracle.com> <7b6a9f76-167a-490d-ac4c-aa24e6623107@default> <57867296.7080402@oracle.com> <226a855d-ac3c-4c1f-ae72-36f54e47d7a3@default> <5787D436.3040306@oracle.com> Message-ID: <5788796C.70806@oracle.com> +1. Regards Prasanta > > On 07/14/2016 01:34 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> Good day to you. >> A quick follow up on the bug fix for : JDK-8152971 >> >> First, Thanks to Phil for his time in review. >> >> I ?ve incorporated Phil ?s suggestions and the webrev with >> modifications are available under: >> Link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.05/ >> >> Quick Summary on the Changes: >> . Explicity deletion of local refs in >> Java_sun_awt_Win32FontManager_populateFontFileNameMap0 have been >> removed. >> . Since the references are not many, they will be >> reclaimed by JVM once JNI function returns >> . The variable fontKeyName has been removed and the constant >> string FONTKEY_NT has been used directly. >> >> Kindly review at your convenient time and share your feedback. >> >> Thanks for your time >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Philip Race >> Sent: Wednesday, July 13, 2016 10:26 PM >> To: Prahalad Kumar Narayanan >> Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Praveen Srivastava >> Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with >> -Xcheck:jni >> >> Much cleaner .. although I also do not think we need to explicitly >> delete the local refs in >> Java_sun_awt_Win32FontManager_populateFontFileNameMap0 >> >> since the return will do that. >> >> And a little clean up .. the variable fontKeyName does not >> seem to be needed any more. Just directly use FONTKEY_NT. >> >> -phil. >> >> On 7/11/16, 12:02 PM, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> Good day to you. >> >> A quick follow-up on the bug fix for : JDK-8152971 JNI Warning >> with -Xcheck:jni >> >> First, Thanks to Phil for the time in review and detailed explanation. >> >> To answer the question - >> "The issue with local refs is that you want to avoid too many >> so there is no need to do that release before return explicitly since >> the VM will do it for us. same for the direct calls to >> deletelocalref. Do you get any JNI warnings if you remove these ? " >> Answer : >> Yes., I see the warnings if DeleteLocalRef is not invoked on >> objects created in the callback functions. >> It is in these callback functions that many objects >> get created without a corresponding release api. >> No warnings were seen when releaseGdiFontMapReferences() was >> taken out. >> This function is removed in the latest change. >> The behavior could be attributed to two points >> a. FontMap having most of its references to >> jObjects that are on stack (as arguments to function). >> b. Very few references to local objects are >> created in the parent JNI function ( 2 - 3 classIDs ) >> >> To Summarize the Changes >> . In all callback functions, the DeleteLocalRef calls have >> been reorganized to avoid cluttering before return statements. >> . releaseGdiFontMapReferences() function has been removed. >> The only font map reference that is released in >> latest code - is the reference to jClass object along with other >> classID references. This could be avoided but has been retained as a >> safe measure. >> >> The changes are available under webrev link: >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.04/ >> >> Kindly review at your convenient time and provide your suggestions. >> >> Thanks for your review & feedback >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Phil Race >> Sent: Friday, July 08, 2016 1:52 AM >> To: Prahalad Kumar Narayanan >> Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Jayathirth D V; >> Praveen Srivastava >> Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with >> -Xcheck:jni >> >> >> So far as I can see we can eliminate at least some of the clutter of >> the calls to deletelocalreference by simply doing it as soon as we >> are done with the reference >> >> eg >> >> 309 familyLC = (*env)->CallObjectMethod(env, fmi->family, >> 310 fmi->toLowerCaseMID, fmi->locale); >> >> >> can be immediately followed by : >> DeleteLocalReference(env, familyLC); >> >> >> .. whether or not there is a pending exception. >> >> and >> >> 343 (*env)->CallObjectMethod(env, fmi->familyToFontListMap, >> 344 fmi->putMID, familyLC, fmi->list); >> >> can be immediately followed by : >> >> DeleteLocalReference(env, fmi->family); >> DeleteLocalReference(env, fmi->list); >> >> .. whether or not there is a pending exception. >> >> and so on. >> >> releaseGdiFontMapReferences() seems to be used right before returning >> to Java. >> The issue with local refs is that you want to avoid too many so there >> is no need to do that release before return explicitly since the VM >> will do it for us. >> same for the direct calls to deletelocalref. >> Do you get any JNI warnings if you remove these ? >> >> >> I could even argue that some of the ones before return (0) from the >> enum functions which will cause us to then exit up the call stack >> fall into the same bucket but if you can simplify the change as I >> suggest it'll be easier to sort that out as there'll be less noise. >> >> >> -phil. >> >> >> On 07/04/2016 02:43 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> Good day to you. >> >> A quick follow-up on the fix for >> Bug ID : JDK-8152971 >> Title : -Xcheck:jni - WARNING in native method >> >> Thanks to Phil for his feedback. >> The feedback was not only detailed.. but contained important links >> for reference. >> >> I 've incorporated the review suggestions and have updated the webrev. >> Brief on changes from previous revision: >> >> 1. Once an exception has been found in an Up-call, the >> exception is ' not ' consumed or cleared now. >> . As Phil rightly said, this will pave way for the >> Java methods to know of the exceptions and handle them. >> >> 2. In addition to point No.1, The GDI's callback functions >> return zero '0' during an exception. >> . This will stop the subsequent enumeration of fonts & >> calls to registered callbacks through the APIs >> >> 3. Since exceptions are not consumed, all GDI 's callback >> functions are checked for pending exceptions at the entry. >> . On pending exceptions, the GDI's callback functions >> return immediately. >> . This prevents the functions from invoking >> any other JNI calls that could be un-safe during a pending exception >> . The callback functions merely release any >> local reference held before returning to caller. >> >> 4. Since we no longer support Win98, the obsolete ANSI >> versions of functions (~A functions) have been removed. >> . Functions that work with Unicode strings invoking >> Unicode versions of Windows APIs (~W functions) are retained. >> 5. The jtreg shell script has been modified to execute on >> all platforms after testing its execution on Windows, Linux, Mac and >> SunOS. >> . Just to re-iterate: The jtreg script fails on windows >> and solaris but in java.lang codebase. >> . A bug is already Open indicating JNI warnings in >> java.lang package. Hence this change does not introduce any new issues. >> >> As with any proposed webrev: >> . The changes were run through internal build system to ensure >> safe build on all supported OS versions. >> . JCK and JTREG test cases were run to ensure no conformance >> or regression failures occur. >> >> Kindly review the changes at your convenience and provide your feedback. >> . Updated webrev link: >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.03/ >> >> Thank you for your time & effort in review Have a good day >> >> Prahalad N. >> >> ---------------------------------------------------------------------- >> ------ >> From: Philip Race >> Sent: Wednesday, June 29, 2016 10:48 PM >> To: Prasanta Sadhukhan >> Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Jayathirth D V; >> Praveen Srivastava >> Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with >> -Xcheck:jni >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design >> .html#exception_handling >> >> lists DeleteLocalRef as safe to call with a pending exception. >> >> So here ... >> 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, >> 175 fmi->toLowerCaseMID, fmi->locale); >> 176 if ((*env)->ExceptionCheck(env)) { >> 177 (*env)->ExceptionClear(env); >> 178 /* Delete the created references */ >> 179 DeleteLocalReference(env, fullname); >> 180 return 1; >> 181 } >> >> ... perhaps what we should do is not clear the exception and with the >> goal that after returning from this function we can check in the >> caller for a pending exception and return from JNI to Java *without >> clearing it* - so that Java code gets that exception propagated. I >> suggest this because I think we would have a correctness issue which >> should be reported - not swallowed - if there ever really was one. >> >> I think this means that the GDI callbacks need to check for a pending >> exception on entry and bail since once we hand off to windows it may >> be called repeatedly. >> >> But also we should stop enumeration if we detect an error hence we >> should return 0 in this case, not 1 per the docs for EnumFontFamExProc >> >> --- >> https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs >> .85).aspx >> >> Return value >> >> The return value must be a nonzero value to continue enumeration; >> to stop enumeration, the return value must be zero. >> >> --- >> >> Also the "A" functions are now obsolete. No win 98 support any more >> :-) We should just delete them instead of updating them. >> >> And I'd prefer the test be verified on Solaris rather than excluding >> it >> >> -phil >> >> >> On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: >> Looks good to me. Only thing is in test script, you need to add >> copyright 2015, 2016 as the script is originally written in 2015 and >> you cannot omit the created year from the copyright. >> >> Regards >> Prasanta >> On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: >> >> Hello Everyone >> >> Good day to you. >> >> Quick follow up to fix for the Bug >> Bug ID : JDK-8152971 >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 >> >> First, Thanks to Prasanta for his review & suggestions. >> >> I 've incorporated some of the review suggestions & updated the webrev. >> Webrev Link : >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ >> >> Overview on changes from previous webrev: >> >> 1. Code Changes: As Prasanta mentioned, >> The variable fontStrLC should be used in place of >> fontStr - The correction has been taken up. >> And releaseGdiFontMapReferences call is not required >> when GdiFontMapInfo object isn't initialized - The particular >> invocation has been removed. >> >> 2. With regard to deleting references held within GdiFontMapInfo >> struture >> JNI creates local references only for objects that are >> created at the Java side - jobject, jstring and jclass >> The other FMI variables - method IDs are not references >> to objects. Hence invoking deleteLocalRef.. is not valid (may not >> compile too). >> >> 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially >> written to run only on MacOS. >> Since it addresses the bug at hand (which is on windows), >> I tested the script 's execution on Win and Linux. >> The Jtreg script passes on linux and fails on >> windows with warnings in java.lang codebase. >> As I understand, there is a JBS bug filed already >> pertaining to JNI warnings in java.lang package. >> Hence enabling the script on windows, doesn't >> introduce new bug. >> The only OS that the script doesn't run - Solaris. >> Presently, we don't have a Solaris environment at >> our facility to test the script. >> Hence the original functionality on Solaris is >> retained. >> >> Kindly take a look at the changes at your convenience & provide the >> suggestions. >> >> Thank you for your review >> Have a good day >> >> Prahalad N. >> >> ---------------------------------------------------------------------- >> ------ >> From: Prasanta Sadhukhan >> Sent: Monday, June 27, 2016 11:51 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Cc: Philip Race; Jayathirth D V; Praveen Srivastava >> Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with >> -Xcheck:jni >> >> I guess this method(s) should take "fontStrLC" instead of "fontStr" >> 650 (*env)->CallObjectMethod(env, fontToFileMap, >> fmi->putMID, >> 651 fontStr, fileStr); >> >> 692 (*env)->CallObjectMethod(env, fontToFileMap, >> fmi->putMID, >> 693 fontStr, fileStr); >> >> 762 (*env)->CallObjectMethod(env, fontToFileMap, >> fmi->putMID, >> 763 fontStr, fileStr); >> >> 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, >> 806 fontStr, fileStr); >> It seems this line is not needed as we have not populated fmi >> structure yet. >> 882 releaseGdiFontMapReferences(env, &fmi); >> >> Why aren't we deleting >> fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in >> releaseGdiFontMapReferences()? >> >> Also, it seems earlier the testscript was supposed to execute only on >> Mac but now you are extending the execution platform to windows and >> linux as well excluding only solaris. >> Is there any particular need to restrict solaris too? >> >> Regards >> Prasanta >> >> >> On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Forum >> Good day to you. >> A Quick follow-up on webrev to fix the following issue >> Bug ID : JDK-8152971 / -Xcheck:jni - warning in native >> method >> Bug Link : >> https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 >> Updated webrev link: >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ >> Description on Changes >> . The previous webrev contained changes to additional files >> which are not related to the current bug in concern. >> . Henceforth, the updated webrev limits the changes to only >> fontpath.c and a Jtreg test script to verify the change. >> Regarding Build & Test >> . Though the changes pertain to windows specific code, >> internal build system was triggered to ensure safe build on all >> supported platforms. >> . In addition, no new Jtreg failures were found with the >> proposed changes. >> Kindly review the changes at your convenience & provide your feedback. >> Thank you for your time in review >> Have a good day >> Prahalad N. >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Wednesday, June 22, 2016 3:20 PM >> To: 2d-dev at openjdk.java.net >> Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen >> Srivastava >> Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni >> Hello Everyone, on Java2D Group Good day to you. >> Please find herewith, webrev changes to fix the bug- >> Bug ID : JDK-8152971 / -Xcheck:jni - warning in native >> method >> Bug Link : >> https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 >> Webrev : >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ >> Description on Bug: >> 1. Too many JNI warnings are reported in the native >> functions when test-code is run with VM Option: -Xcheck:jni >> 2. The warnings can be classified into 2 categories >> a. JNI warnings that are thrown due to the >> missing exception checks after an Up call ( JNI function invoking >> Java method ) >> b. JNI warnings that are thrown due to increased >> usage of Local Reference objects. >> Description on the Fix: >> 1. File : FontPath.c >> Added JNIEnv->ExceptionCheck() and >> ExceptionClear() where Up call is invoked. >> The checks are added only to the valid >> Up calls as per JNI spec. >> Added JNIEnv->DeleteLocalRef where the native >> functions created Java side objects but did not delete their local >> reference after usage. >> A few of the native functions get >> invoked as Callbacks to Windows APIs following the font enumeration. >> Therefore at each callback, the count >> of active local references would increase. >> Over time, the active local >> references would exceed the planned number of local references set by >> JVM. >> 2. File : awt_Component.cpp >> Added JNIEnv->ExceptionCheck() and >> ExceptionClear() where an Up call displayed a JNI warning while >> running the Jtreg test script. >> Information on Jtreg test script is given below. >> 3. File : LoadFontsJNICheck.sh >> The shell script is already a part of JTreg >> test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option >> However, the script was configured to run only >> on Mac OS. Now, the script is modified to run on windows, linux and >> mac systems. >> This way, the code changes can be >> checked for proper execution with test-case. >> 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 prasanta.sadhukhan at oracle.com Fri Jul 15 09:36:49 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 15 Jul 2016 15:06:49 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6278300: sun.print.Win32MediaSize deserialization error Message-ID: <5788AEB1.9010709@oracle.com> Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6278300 Please review a fix for an issue where it is seen that Deserialization of a javax.print.attribute.standard.MediaPrintableArea printer attribute fails when the serialization happened in a prior invocation of the program only for a *non-standard* page size say 4"x6" It is because EnumSyntax.readResolve() tries to get the EnumSyntax[] table from Win32MediaSize when the objects are read and if the EnumSyntax table is not initialized or 0 in length, then readResolve() will find the object value being read is not in the EnumSyntax table and will throw this InvalidObjectException java.io.InvalidObjectException: Integer value = 9 not in valid range 0..-1for class class sun.print.Win32MediaSize at javax.print.attribute.EnumSyntax.readResolve(java.desktop at 9-internal/EnumSyntax.java:204) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-internal/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-internal/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-internal/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-internal/Method.java:533) at java.io.ObjectStreamClass.invokeReadResolve(java.base at 9-internal/ObjectStreamClass.java:1150) at java.io.ObjectInputStream.readOrdinaryObject(java.base at 9-internal/ObjectInputStream.java:1835) at java.io.ObjectInputStream.readObject0(java.base at 9-internal/ObjectInputStream.java:1371) at java.io.ObjectInputStream.readObject(java.base at 9-internal/ObjectInputStream.java:371) When the printDialog() is invoked, then EnumSyntax table will be initialised to the current paper ids. But, if printDIalog() is invoked AFTER objects are deserialised, we run into this problem of enumTable being 0 in length. Proposed fix is, to check if the enumtable is not initialised, then fallback to the supported media size enum table. webrev: http://cr.openjdk.java.net/~psadhukhan/6278300/webrev.00/ I made it noreg-hard as it needs a custom paper size to be added to printer media list before invoking the serialization testcase present in JBS bug entry. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Jul 15 10:08:49 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Jul 2016 12:08:49 +0200 Subject: [OpenJDK 2D-Dev] RFR(XS): 8160721: Avoid deoptimizations in Font.equals. In-Reply-To: References: <74fd6cc4-b30d-48ce-7bea-16cc08b885b9@oracle.com> Message-ID: Hi Goetz, it would be really interesting to see the use case where this has been a performance issue. But even without that I agree with your comments in the bug. Phil's fear that you introduce an extra 'instanceof' check for the positive case is unfounded. I've attached a small example program to the bug which shows that the common case is the same for both version, only the uncommon version where the paramter is not a Font object is slightly more complicated in the original version because of the extra exception handling code. So in general the change looks good! Please push it to the client repo. Regards, Volker On Thu, Jul 7, 2016 at 9:04 AM, Lindenmaier, Goetz wrote: > Hi, > > can I consider this reviewed? > Remi Forax and Phil Race had a look at this. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Montag, 4. Juli 2016 08:33 >> To: 'Phil Race' ; awt-dev at openjdk.java.net; 2d-dev >> <2d-dev at openjdk.java.net> >> Subject: RE: RFR(XS): 8160721: Avoid deoptimizations in >> Font.equals. >> >> Hi, >> >> Resending this to 2d-dev. >> >> Also, I made a new webrev considering Remi's comments: >> http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/webrev.02/ >> >> Best regards, >> Goetz. >> >> >> > -----Original Message----- >> > From: Phil Race [mailto:philip.race at oracle.com] >> > Sent: Freitag, 1. Juli 2016 19:35 >> > To: Lindenmaier, Goetz ; awt- >> > dev at openjdk.java.net >> > Subject: Re: RFR(XS): 8160721: Avoid deoptimizations in >> > Font.equals. >> > >> > Please resend this to 2d-dev. All font related API and implementation >> > is part of 2D, not AWT. >> > >> > -phil. >> > >> > On 7/1/2016 6:59 AM, Lindenmaier, Goetz wrote: >> > > >> > > Hi, >> > > >> > > This small fix improves performance of the C2 compiler. >> > > >> > > We see deoptimizations due to class casts in Font.equals. >> > > Use instanceof check instead of catching the exception. >> > > >> > > Please review this change: >> > > >> > > http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/ >> > > >> > > >> > > Best regards, >> > > >> > > Goetz. >> > > > From prasanta.sadhukhan at oracle.com Fri Jul 15 11:04:34 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 15 Jul 2016 16:34:34 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8054991 : sun.font.GlyphList uses broken double-checked locking In-Reply-To: References: <574624AE.2040503@oracle.com> <8477f52c-854c-480d-aa11-1ac7acfc0b1e@oracle.com> <5786C0B4.60004@oracle.com> Message-ID: <5788C342.3020603@oracle.com> +1. But one thing, is there any need of public static GlyphList getInstance(int sz) which is commented out. I guess we can remove this method. Regards Prasanta On 7/14/2016 8:27 PM, Alexey Ivanov wrote: > Looks good. > > > Regards, > Alexey > > On 14.07.2016 1:29, Phil Race wrote: >> This almost got lost. I have updated the fix >> >> See http://cr.openjdk.java.net/~prr/8054991/ >> >> -phil. >> >> On 05/26/2016 05:23 AM, Alexey Ivanov wrote: >>> Hi Phil, >>> >>> Since reusableGL is written only once, I'm for marking the field final. >>> >>> The proposed patch is attached to JBS bug under the name 'pp'. >>> >>> Marking inUse field as volatile seems enough to fix the issue. >>> However the suggested patch makes code cleaner. >>> >>> >>> Regards, >>> Alexey >>> >>> On 26.05.2016 1:18, Phil Race wrote: >>>> bug : https://bugs.openjdk.java.net/browse/JDK-8054991 >>>> >>>> There is a comment in there about a proposed patch but I can't find >>>> it. >>>> However I think this will be sufficient :- >>>> >>>> diff --git a/src/java.desktop/share/classes/sun/font/GlyphList.java >>>> b/src/java.desktop/share/classes/sun/font/GlyphList.java >>>> --- a/src/java.desktop/share/classes/sun/font/GlyphList.java >>>> +++ b/src/java.desktop/share/classes/sun/font/GlyphList.java >>>> @@ -152,7 +152,7 @@ >>>> * created. >>>> */ >>>> private static GlyphList reusableGL = new GlyphList(); >>>> - private static boolean inUse; >>>> + private static volatile boolean inUse; >>>> >>>> -phil. >>> >> > From goetz.lindenmaier at sap.com Mon Jul 18 06:24:43 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Jul 2016 06:24:43 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8160721: Avoid deoptimizations in Font.equals. In-Reply-To: References: <74fd6cc4-b30d-48ce-7bea-16cc08b885b9@oracle.com> Message-ID: Hi Volker, thanks for looking at this, and doing the test example! Best regards, Goetz. > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 15. Juli 2016 12:09 > To: Lindenmaier, Goetz > Cc: Phil Race ; awt-dev at openjdk.java.net; 2d-dev > <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR(XS): 8160721: Avoid > deoptimizations in Font.equals. > > Hi Goetz, > > it would be really interesting to see the use case where this has been > a performance issue. > > But even without that I agree with your comments in the bug. Phil's > fear that you introduce an extra 'instanceof' check for the positive > case is unfounded. I've attached a small example program to the bug > which shows that the common case is the same for both version, only > the uncommon version where the paramter is not a Font object is > slightly more complicated in the original version because of the extra > exception handling code. > > So in general the change looks good! > Please push it to the client repo. > > Regards, > Volker > > > On Thu, Jul 7, 2016 at 9:04 AM, Lindenmaier, Goetz > wrote: > > Hi, > > > > can I consider this reviewed? > > Remi Forax and Phil Race had a look at this. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Montag, 4. Juli 2016 08:33 > >> To: 'Phil Race' ; awt-dev at openjdk.java.net; 2d- > dev > >> <2d-dev at openjdk.java.net> > >> Subject: RE: RFR(XS): 8160721: Avoid deoptimizations in > >> Font.equals. > >> > >> Hi, > >> > >> Resending this to 2d-dev. > >> > >> Also, I made a new webrev considering Remi's comments: > >> http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/webrev.02/ > >> > >> Best regards, > >> Goetz. > >> > >> > >> > -----Original Message----- > >> > From: Phil Race [mailto:philip.race at oracle.com] > >> > Sent: Freitag, 1. Juli 2016 19:35 > >> > To: Lindenmaier, Goetz ; awt- > >> > dev at openjdk.java.net > >> > Subject: Re: RFR(XS): 8160721: Avoid deoptimizations in > >> > Font.equals. > >> > > >> > Please resend this to 2d-dev. All font related API and implementation > >> > is part of 2D, not AWT. > >> > > >> > -phil. > >> > > >> > On 7/1/2016 6:59 AM, Lindenmaier, Goetz wrote: > >> > > > >> > > Hi, > >> > > > >> > > This small fix improves performance of the C2 compiler. > >> > > > >> > > We see deoptimizations due to class casts in Font.equals. > >> > > Use instanceof check instead of catching the exception. > >> > > > >> > > Please review this change: > >> > > > >> > > http://cr.openjdk.java.net/~goetz/wr16/8160721-deoptFont/ > >> > > > >> > > > >> > > Best regards, > >> > > > >> > > Goetz. > >> > > > > From prasanta.sadhukhan at oracle.com Mon Jul 18 11:27:21 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 18 Jul 2016 16:57:21 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work Message-ID: <578CBD19.6000303@oracle.com> Hi All, Please review a fix for an issue where it is seen that Banner page in linux does not get printed despite user selecting the Banner page checkbox in Printer dialog. Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ It seems if we pass "-J " option to lpr command, it has no effect. To print Banner page, we need to pass "-o job-sheets=" Since we support only standard banner or none via a checkbox, the proposed fix passes option "-o job-sheets=standard" to lpr command to print the banner page. Regards PRasanta From philip.race at oracle.com Mon Jul 18 17:50:26 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 18 Jul 2016 10:50:26 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8161407: Provide a javadoc description for java.desktop module Message-ID: <578D16E2.6000208@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8161407 The top-level "api/index.html" provides for including a summary description of a module taken from text in module-info.java eg java.base has /** * java.base defines and exports the core APIs of the Java SE platform. */ This fix adds the same kind of summary for desktop diff --git a/src/java.desktop/share/classes/module-info.java b/src/java.desktop/share/classes/module-info.java --- a/src/java.desktop/share/classes/module-info.java +++ b/src/java.desktop/share/classes/module-info.java @@ -23,6 +23,10 @@ * questions. */ +/** + * java.desktop defines and exports the UI and graphics APIs of the + * Java SE platform. + */ module java.desktop { requires public java.datatransfer; requires public java.xml; -phil From brian.burkhalter at oracle.com Mon Jul 18 18:22:55 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 18 Jul 2016 11:22:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8161407: Provide a javadoc description for java.desktop module In-Reply-To: <578D16E2.6000208@oracle.com> References: <578D16E2.6000208@oracle.com> Message-ID: <6937629A-6C14-4DEB-8251-772484CA0E77@oracle.com> Showing my own bias, how about ?UI and graphics APIs? -> ?graphics, imaging, and user interface APIs? ? Brian On Jul 18, 2016, at 10:50 AM, Phil Race wrote: > This fix adds the same kind of summary for desktop > > diff --git a/src/java.desktop/share/classes/module-info.java b/src/java.desktop/share/classes/module-info.java > --- a/src/java.desktop/share/classes/module-info.java > +++ b/src/java.desktop/share/classes/module-info.java > @@ -23,6 +23,10 @@ > * questions. > */ > > +/** > + * java.desktop defines and exports the UI and graphics APIs of the > + * Java SE platform. > + */ > module java.desktop { > requires public java.datatransfer; > requires public java.xml; -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jul 18 18:25:11 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 18 Jul 2016 11:25:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8054991 : sun.font.GlyphList uses broken double-checked locking In-Reply-To: <5788C342.3020603@oracle.com> References: <574624AE.2040503@oracle.com> <8477f52c-854c-480d-aa11-1ac7acfc0b1e@oracle.com> <5786C0B4.60004@oracle.com> <5788C342.3020603@oracle.com> Message-ID: <578D1F07.4030803@oracle.com> It was a reminder that there is some optimisation we can do here so I chose to leave it rather than delete it. -phil On 7/15/16, 4:04 AM, Prasanta Sadhukhan wrote: > +1. But one thing, is there any need of > > public static GlyphList getInstance(int sz) > > which is commented out. I guess we can remove this method. > > Regards > Prasanta > On 7/14/2016 8:27 PM, Alexey Ivanov wrote: >> Looks good. >> >> >> Regards, >> Alexey >> >> On 14.07.2016 1:29, Phil Race wrote: >>> This almost got lost. I have updated the fix >>> >>> See http://cr.openjdk.java.net/~prr/8054991/ >>> >>> -phil. >>> >>> On 05/26/2016 05:23 AM, Alexey Ivanov wrote: >>>> Hi Phil, >>>> >>>> Since reusableGL is written only once, I'm for marking the field >>>> final. >>>> >>>> The proposed patch is attached to JBS bug under the name 'pp'. >>>> >>>> Marking inUse field as volatile seems enough to fix the issue. >>>> However the suggested patch makes code cleaner. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 26.05.2016 1:18, Phil Race wrote: >>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8054991 >>>>> >>>>> There is a comment in there about a proposed patch but I can't >>>>> find it. >>>>> However I think this will be sufficient :- >>>>> >>>>> diff --git >>>>> a/src/java.desktop/share/classes/sun/font/GlyphList.java >>>>> b/src/java.desktop/share/classes/sun/font/GlyphList.java >>>>> --- a/src/java.desktop/share/classes/sun/font/GlyphList.java >>>>> +++ b/src/java.desktop/share/classes/sun/font/GlyphList.java >>>>> @@ -152,7 +152,7 @@ >>>>> * created. >>>>> */ >>>>> private static GlyphList reusableGL = new GlyphList(); >>>>> - private static boolean inUse; >>>>> + private static volatile boolean inUse; >>>>> >>>>> -phil. >>>> >>> >> > From philip.race at oracle.com Mon Jul 18 19:11:38 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 18 Jul 2016 12:11:38 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8161407: Provide a javadoc description for java.desktop module In-Reply-To: <6937629A-6C14-4DEB-8251-772484CA0E77@oracle.com> References: <578D16E2.6000208@oracle.com> <6937629A-6C14-4DEB-8251-772484CA0E77@oracle.com> Message-ID: <578D29EA.5080506@oracle.com> Depends how fine grained we want to go. The java.base one doesn't even try to enumerate what is in there but I did think we maybe needed to say something .. right now it stands out as completely empty. If we include all 3 I think we need to start with UI :- "User interface, graphics and imaging APIs" Any objection to that ? -phil. On 07/18/2016 11:22 AM, Brian Burkhalter wrote: > Showing my own bias, how about > > ?UI and graphics APIs? -> ?graphics, imaging, and user interface APIs? ? > > Brian > > On Jul 18, 2016, at 10:50 AM, Phil Race > wrote: > >> This fix adds the same kind of summary for desktop >> >> diff --git a/src/java.desktop/share/classes/module-info.java >> b/src/java.desktop/share/classes/module-info.java >> --- a/src/java.desktop/share/classes/module-info.java >> +++ b/src/java.desktop/share/classes/module-info.java >> @@ -23,6 +23,10 @@ >> * questions. >> */ >> >> +/** >> + * java.desktop defines and exports the UI and graphics APIs of the >> + * Java SE platform. >> + */ >> module java.desktop { >> requires public java.datatransfer; >> requires public java.xml; > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Jul 18 19:31:09 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 18 Jul 2016 12:31:09 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8161407: Provide a javadoc description for java.desktop module In-Reply-To: <578D29EA.5080506@oracle.com> References: <578D16E2.6000208@oracle.com> <6937629A-6C14-4DEB-8251-772484CA0E77@oracle.com> <578D29EA.5080506@oracle.com> Message-ID: Looks fine to me. Brian On Jul 18, 2016, at 12:11 PM, Phil Race wrote: > Depends how fine grained we want to go. The java.base one doesn't even try > to enumerate what is in there but I did think we maybe needed to say something .. > right now it stands out as completely empty. > > If we include all 3 I think we need to start with UI :- > > "User interface, graphics and imaging APIs" > > Any objection to that ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Jul 19 07:00:23 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 19 Jul 2016 00:00:23 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: Message-ID: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> Hi Laurent, Some work should be done on the comments at the top of ArrayCache.java - line 38 and 42 make the same claim about 2 different thresholds. It seems silly, but in ArrayCache.getNewLargeSize(), lines 162 and 164 are both ">" tests and then the newly added test at 166 is a "<" test. It would be nice to main symmetry of the tests in that if/then/elseif sequence. As far as I can see, the buckets are: 0 - 4K 1 - 16k 2 - 64k 3 - 256k 4 - 1m 5 - 4m 6 - 8m 7 - 16m which makes MAX_ARRAY_SIZE == THRESHOLD_ARRAY_SIZE == 16m and THRESHOLD_LARGE is also 16m...? I don't have any issues with those numbers, but the way that they are calculated makes it look like they are supposed to be unique numbers and yet through the obscurity of the loops used to populate the sizes they just end up all being the same numbers - it makes me wonder if there was a mistake in there or not...? CacheStats.reset() - should totalInitial be reset as well? Also, there should be a reset method on the BucketStats class rather than just digging in and modifying its members directly from outside the class. It feels odd to have all of the cache classes import the static members of ArrayCache rather than just subclassing it. Is there a reason it wasn't just subclassed? The Dirty and Clean subclasses are nearly identical and yet they share no code simply because buried inside one of their inner classes one of them clears the data and the other does not. That seems a waste for something so trivial in the design. The various Reference.putArray() methods protect against putting the initial arrays, and you the code that calls them also makes the same check. I'd remove the code that checks for initial from the callers so that the call sites are more streamlined, but there's no functional issue with the way it is now. Also, since you never put the initial arrays, they aren't automatically cleaned...? Is the shell script only used by you to replicate changes from the Byte classes to the Int/Float classes? A shell comment at the top would be nice to explain that... The only issue above is whether or not the initial arrays are missing a clean pass on them due to the fact that they get rejected by the put methods. All of the others are simply comments to engage some discussion on the design elements... ...jim On 6/15/16 2:10 PM, Laurent Bourg?s wrote: > Hi, > > Please review this bug fix for the Marlin renderer to improve the array caches, its usages but also the renderer stats: > bug: https://bugs.openjdk.java.net/browse/JDK-8159638 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.0/ > > This patch also reduces slightly the memory footprint: 1 RendererContext represents now ~ 450K (310K on-heap / 140K > off-heap). > > Changes: > - Byte/Int/Float ArrayCache removed > - replaced by Clean[Byte/Int/Float]ArrayCache (zero-filled arrays) and Dirty[Byte/Int/Float]ArrayCache classes (dirty > arrays). These new classes provides a Reference class that wraps the initial array and acts as a proxy to the related > array cache instance (get/widen//put Array) > > - ArrayCache: increased bucket to 8 (larger retained memory but weakly referenced) + added CacheStats (and BucketStats) > > - MarlinProperties: added setiings for initial edge capacity and align array sizes to 64 (power of 2) > > - RendererContext: large cleanup + use a weak reference for the recycled Path2D instance > > - RendererStats: big refactoring to create one RendererStats instance per created RendererContext instance (thread > stats) and the new RendererStatsHolder class gathers all RendererStats instances to dump them at shutdown (very small > retained memory instead of keeping all RendererContext instances) > > Tested with current jtreg tests (+ my MapBench tests) > > Regards, > Laurent From Sergey.Bylokhov at oracle.com Tue Jul 19 14:09:35 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 19 Jul 2016 17:09:35 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8161407: Provide a javadoc description for java.desktop module In-Reply-To: <578D29EA.5080506@oracle.com> References: <578D16E2.6000208@oracle.com> <6937629A-6C14-4DEB-8251-772484CA0E77@oracle.com> <578D29EA.5080506@oracle.com> Message-ID: <46c3eb7b-cd27-eb1c-d119-8c8c4d9e820b@oracle.com> On 18.07.16 22:11, Phil Race wrote: > "User interface, graphics and imaging APIs" > > Any objection to that ? What about a11y and sound? > > -phil. > > On 07/18/2016 11:22 AM, Brian Burkhalter wrote: >> Showing my own bias, how about >> >> ?UI and graphics APIs? -> ?graphics, imaging, and user interface APIs? ? >> >> Brian >> >> On Jul 18, 2016, at 10:50 AM, Phil Race > > wrote: >> >>> This fix adds the same kind of summary for desktop >>> >>> diff --git a/src/java.desktop/share/classes/module-info.java >>> b/src/java.desktop/share/classes/module-info.java >>> --- a/src/java.desktop/share/classes/module-info.java >>> +++ b/src/java.desktop/share/classes/module-info.java >>> @@ -23,6 +23,10 @@ >>> * questions. >>> */ >>> >>> +/** >>> + * java.desktop defines and exports the UI and graphics APIs of the >>> + * Java SE platform. >>> + */ >>> module java.desktop { >>> requires public java.datatransfer; >>> requires public java.xml; >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 19 19:16:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 19 Jul 2016 22:16:56 +0300 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> Message-ID: <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Look fine to me. On 07.07.16 18:01, Lindenmaier, Goetz wrote: > Hi, > > > > This change is ?L? because there are changes to a lot of files, but the > changes > > are all similar, so it?s rather easy to review. > > Similar to 8159690 I added @key headful to another around 600 tests. > > I used different patterns to grep for the headful exceptions. > > > > These are now all I could find with grepping and the like. I have around > > 80 failing tests remaining, where a row will probably also depend on > > a display, but I want to look at them more closely, so I don?t want > > to include them here. > > > > Please review this change: > > http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > > > > Best regards, > > Goetz. > > > > > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Tue Jul 19 19:18:26 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 19 Jul 2016 12:18:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: <578674F8.1050905@oracle.com> References: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> <578674F8.1050905@oracle.com> Message-ID: <5b1abcf8-d755-4d4c-b3a8-d8cc9a89c424@default> Hi Phil, I generated Jpeg image with thumbnail as given in test case attached for https://bugs.openjdk.java.net/browse/JDK-4958271 with JDK 9. The image has only two APP0 markers and after the second marker it has "00 FF" which we can consider as "X FF" as per https://www.w3.org/Graphics/JPEG/itu-t81.pdf. But it is just continuation of pattern "00 00 FF" which we see around the end of second APP0 marker. For this new image I don't see whether we are writing improperly in JDK9(If we consider "X FF" bits between markers). So we can just apply http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ and open up the test case(after verifying whether it is the only test case which uses this particular image) with new image that I have created. Thanks, Jay -----Original Message----- From: Philip Race Sent: Wednesday, July 13, 2016 10:06 AM To: Jim Graham Cc: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java Whilst looking at the reason this test was originally created https://bugs.openjdk.java.net/browse/JDK-4958271 it started to look likely that the image was (as I sort of suspected) was generated by IIO itself. I think there a couple of things we can do here 1) Open up the test (and image - although if moving it make sure no other tests in that location need the image). 2) Investigate to see if the bug such that the "bad padding" is written out is still reproducible with current IIO ... or if it was fixed sometime between when that image was created and now. -phil. On 7/12/16, 7:48 PM, Jim Graham wrote: > I think this is fine, but I noticed that some of the recently added > comments have some grammar issues. It might be nice to change the > following: > > 565 // markers which do not contain length data > (doesn't => do not) > > 576 // markers which contain length data > (contains => contain) > > I don't need to review those changes... > > ...jim > > On 7/12/16 9:15 AM, Jayathirth D V wrote: >> Hi, >> >> >> >> Thanks for your input Phil. >> >> I have made changes just to parse "FF FF"(Like "FF 00" or any marker >> without length)and not consider it as an invalid marker in >> skipImage() of JPEGImageReader.java. >> >> Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java >> from ProblemList.txt as part of fix. >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 >> >> >> >> Please find webrev for review for JDK9: >> >> http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ >> >> >> >> Thanks, >> >> Jay >> >> >> >> *From:*Phil Race >> *Sent:* Saturday, July 09, 2016 12:37 AM >> *To:* Jayathirth D V >> *Cc:* Jim Graham; 2d-dev >> *Subject:* Re: REG : JDK-8160943 : [PIT] new failure of >> closed/javax/imageio/ReadAllThumbnailsTest.java >> >> >> >> On 07/08/2016 04:08 AM, Jayathirth D V wrote: >> >> Hi, >> >> >> >> In JDK-8152672 >> we modified skipImage() in JpegImageReader.java >> and added tighter checks for parsing Jpeg data. >> >> >> >> We have to find any marker,0 or EOF after we find "FF" while >> parsing JPEG data. >> >> But in JDK-8160943 >> we have gap >> between APP0 marker and DQT(FF DB) >> marker which contains data "00 FF". >> >> >> >> APP0_End -> 00 FF -> FF DB(DQT) >> >> >> >> So after we skip APP0 marker we find two bytes of data which is >> "FF FF". In the present code we consider this as >> invalid marker. >> >> >> See https://www.w3.org/Graphics/JPEG/itu-t81.pdf >> >> B.1.1.2 Markers >> Markers serve to identify the various structural parts of the >> compressed data formats. >> Most markers start marker segments containing a related group of >> parameters; some markers stand alone. All markers are assigned >> two-byte codes: an X'FF' byte followed by a byte which is not equal >> to 0 or X'FF' (see Table B.1). >> Any marker may optionally be preceded by any number of fill bytes, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> which are bytes assigned code X'FF >> ^^^^^^^^^^^^^^^^^^^^^^ >> >> -phil. >> >> >> Because of this JDK-8160943 >> is failing. >> >> >> >> Is the length of APP0 marker not valid in the image or we should >> not consider "FF FF" as invalid maker? >> >> Please let me know your input. >> >> >> >> Thanks, >> >> Jay >> >> >> From goetz.lindenmaier at sap.com Tue Jul 19 19:39:45 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Jul 2016 19:39:45 +0000 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Message-ID: <497eea265ad64cd2ae850b66aa98c25f@DEWDFE13DE09.global.corp.sap> Hi Sergey, thanks a lot for looking at this! Best regards, Goetz. > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Tuesday, July 19, 2016 9:17 PM > To: Lindenmaier, Goetz ; awt- > dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d- > dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more > headful tests with @key headful. > > Look fine to me. > > On 07.07.16 18:01, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > This change is 'L' because there are changes to a lot of files, but the > > changes > > > > are all similar, so it's rather easy to review. > > > > Similar to 8159690 I added @key headful to another around 600 tests. > > > > I used different patterns to grep for the headful exceptions. > > > > > > > > These are now all I could find with grepping and the like. I have around > > > > 80 failing tests remaining, where a row will probably also depend on > > > > a display, but I want to look at them more closely, so I don't want > > > > to include them here. > > > > > > > > Please review this change: > > > > http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > -- > Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Jul 20 05:33:30 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 20 Jul 2016 11:03:30 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8160888: [PIT] What to expect of updated java/awt/print/PrinterJob/Margins.java In-Reply-To: <577F5653.1010500@oracle.com> References: <577F5653.1010500@oracle.com> Message-ID: <578F0D2A.4040006@oracle.com> I have updated the webrev to remove run only on windows jtreg tag as with the fix proposed for 6574279: validatePage from PrinterJob returns argument under linux the printed margin will be of correct value and not the full imageablearea(0,0,paperwidth,paperheight) so the issue will be seen on windows & linux without 6601097 fix and not after applying 6601097 . Issue is still not reproducible in mac which prints with correct hardware margin without 6601097 fix. http://cr.openjdk.java.net/~psadhukhan/8160888/webrev.01/ Regards Prasanta On 7/8/2016 12:59 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please find an updation of the testcase > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160888 > webrev: http://cr.openjdk.java.net/~psadhukhan/8160888/webrev.00/ > > where the testcase was made automated and > specifically pass mediasize=A4 as attributes so that there is no > ambiguity of using "letter" vs "A4". > Also, the test is made to run only on windows as the bug is not > reproduced in linux/mac. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Jul 20 13:13:41 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Jul 2016 13:13:41 +0000 Subject: [OpenJDK 2D-Dev] RFR(S): 8161923: Fix two memory issues. Message-ID: <1b31ead91a874c02997770b88350ea57@DEWDFE13DE09.global.corp.sap> Hi This changes fixes two memory issues. In awt_PrintControl.cpp, a wrong pointer is freed. In LigatureSubstProc2.cpp, line 157: stack[++mm] = componentGlyph; can overwrite the stack by one element. It will write stack[nComponents], because ++mm increments before accessing the array. Fix: increase the size of the array by one. Please review this change: http://cr.openjdk.java.net/~goetz/wr16/8161923-jdkMem/webrev.01/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Jul 20 13:29:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Jul 2016 15:29:41 +0200 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Message-ID: Hi G?tz, your change looks good. Thanks a lot for cleaning up all these tests! I only found one problem which you should fix: test/java/awt/Frame/MiscUndecorated/RepaintTest.java @@ -1,6 +1,6 @@ -/* +\/* Seems like there's an extra backslash at the beginning of the first line. You may also want to '@test' on a line by itself like you've done it for all the other tests in test/javax/swing/JTable/7068740/bug7068740.java /* @test - @bug 7068740 - @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys - @author Vladislav Karnaukhov - @run main bug7068740 -*/ + * @key headful + * @bug 7068740 + * @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys + * @author Vladislav Karnaukhov + * @run main bug7068740 + */ And correctly indent in the following two cases: diff --git a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java --- a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java +++ b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java @@ -23,6 +23,7 @@ /* * @test + * @key headful * @bug 6897701 and: diff --git a/test/javax/swing/plaf/synth/7158712/bug7158712.java b/test/javax/swing/plaf/synth/7158712/bug7158712.java --- a/test/javax/swing/plaf/synth/7158712/bug7158712.java +++ b/test/javax/swing/plaf/synth/7158712/bug7158712.java @@ -21,7 +21,9 @@ * questions. */ -/* @test +/* + @test + @key headful @bug 7158712 There's no need to prepare a new webrev. I won't go through it one more time anyway :) Regards, Volker On Tue, Jul 19, 2016 at 9:16 PM, Sergey Bylokhov wrote: > Look fine to me. > > On 07.07.16 18:01, Lindenmaier, Goetz wrote: >> >> Hi, >> >> >> >> This change is ?L? because there are changes to a lot of files, but the >> changes >> >> are all similar, so it?s rather easy to review. >> >> Similar to 8159690 I added @key headful to another around 600 tests. >> >> I used different patterns to grep for the headful exceptions. >> >> >> >> These are now all I could find with grepping and the like. I have around >> >> 80 failing tests remaining, where a row will probably also depend on >> >> a display, but I want to look at them more closely, so I don?t want >> >> to include them here. >> >> >> >> Please review this change: >> >> http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ >> >> >> >> Best regards, >> >> Goetz. >> >> >> >> >> > > > -- > Best regards, Sergey. From goetz.lindenmaier at sap.com Wed Jul 20 13:53:26 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Jul 2016 13:53:26 +0000 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Message-ID: Hi Volker, thanks for that thorough review, the wrong \ is a really good catch! I did'nt upload a new webrev, but maybe the incremental diff Is useful: http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.02/incremental_fixes.patch Best regards, Goetz. > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Mittwoch, 20. Juli 2016 15:30 > To: Sergey Bylokhov > Cc: Lindenmaier, Goetz ; awt- > dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d- > dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] > Mark more headful tests with @key headful. > > Hi G?tz, > > your change looks good. Thanks a lot for cleaning up all these tests! > > I only found one problem which you should fix: > > test/java/awt/Frame/MiscUndecorated/RepaintTest.java > > @@ -1,6 +1,6 @@ > -/* > +\/* > > Seems like there's an extra backslash at the beginning of the first line. > > You may also want to '@test' on a line by itself like you've done it > for all the other tests in > test/javax/swing/JTable/7068740/bug7068740.java > > /* @test > - @bug 7068740 > - @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys > - @author Vladislav Karnaukhov > - @run main bug7068740 > -*/ > + * @key headful > + * @bug 7068740 > + * @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys > + * @author Vladislav Karnaukhov > + * @run main bug7068740 > + */ > > And correctly indent in the following two cases: > > diff --git a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > --- a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > +++ b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > @@ -23,6 +23,7 @@ > > /* > * @test > + * @key headful > * @bug 6897701 > > and: > > diff --git a/test/javax/swing/plaf/synth/7158712/bug7158712.java > b/test/javax/swing/plaf/synth/7158712/bug7158712.java > --- a/test/javax/swing/plaf/synth/7158712/bug7158712.java > +++ b/test/javax/swing/plaf/synth/7158712/bug7158712.java > @@ -21,7 +21,9 @@ > * questions. > */ > > -/* @test > +/* > + @test > + @key headful > @bug 7158712 > > > There's no need to prepare a new webrev. I won't go through it one > more time anyway :) > > Regards, > Volker > > > On Tue, Jul 19, 2016 at 9:16 PM, Sergey Bylokhov > wrote: > > Look fine to me. > > > > On 07.07.16 18:01, Lindenmaier, Goetz wrote: > >> > >> Hi, > >> > >> > >> > >> This change is ?L? because there are changes to a lot of files, but the > >> changes > >> > >> are all similar, so it?s rather easy to review. > >> > >> Similar to 8159690 I added @key headful to another around 600 tests. > >> > >> I used different patterns to grep for the headful exceptions. > >> > >> > >> > >> These are now all I could find with grepping and the like. I have around > >> > >> 80 failing tests remaining, where a row will probably also depend on > >> > >> a display, but I want to look at them more closely, so I don?t want > >> > >> to include them here. > >> > >> > >> > >> Please review this change: > >> > >> http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > >> > >> > >> > >> Best regards, > >> > >> Goetz. > >> > >> > >> > >> > >> > > > > > > -- > > Best regards, Sergey. From philip.race at oracle.com Wed Jul 20 15:10:32 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 20 Jul 2016 08:10:32 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8161264: RasterPrinterJob.updateAttributesWithPageFormat does redundant check In-Reply-To: <57860199.8010208@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> <5761E7A9.1010805@oracle.com> <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> <576AB0BD.7050506@oracle.com> <57860199.8010208@oracle.com> Message-ID: <578F9468.6020805@oracle.com> By that logic all the rest of it is unneeded too ... and the original bug was not a bug or the fix was not quite right. This is not adding up to me. -phil On 7/13/16, 1:53 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a code cleanup for a redundant code introduced in the > below 6601097 fix via webrev.03. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161264 > webrev: http://cr.openjdk.java.net/~psadhukhan/8161264/webrev.00/ > > This code is redundant because irrespective of iw/ih being *negative* > or *0*, MediaPrintableArea constructor called just after @line 692 > will throw IAE which is consumed > and thereafter this invalid mpa value is not propagated anymore and we > will fallback to Java default paper margin of 1". > So, there is no need of checking for iw/ih for negative and set it to 0 . > > Regards > Prasanta > On 6/22/2016 9:07 PM, Philip Race wrote: >> +1 .. they won't get any output with a zero-width imageable area >> but this is last ditch fix up of excessively bad values. >> >> -phil. >> >> On 6/16/16, 11:32 PM, prasanta sadhukhan wrote: >>> >>> Hi Phil, >>> >>> Ok. I have added a check for this case in which it will fall back to >>> default values since >>> if ix/iy is too large then we probably will not get anything to >>> print inside printable area if we have to leave same margin on the >>> right/bottom of the paper. >>> validatePaper() does not check for ix/iy too large case. >>> >>> Modified webrev >>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.03/ >>> >>> Regards >>> Prasanta >>> On 6/16/2016 5:11 AM, Philip Race wrote: >>>> I did say so long as the "ix/iy" are also valid. Which means not >>>> just positive but that they >>>> are not too large. Consider >>>> if (iw<= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); >>>> >>>> if we have ix = 500 and iw = -20 for a paper with width 800 this >>>> will result >>>> in iw = 800 - (500*2) = -200 .. >>>> >>>> -phil. >>>> >>>> On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> As discussed offline, regarding mpa modification in both >>>>> setAttributes() and updateAttributesWithPageFormat, I found that >>>>> updateAttributesWithPageFormat() will be called during >>>>> pageDialog() and setPrintable() >>>>> whereas setAttributes() will be called during print() and >>>>> setAttributes() called validatePaper() to validate imageable >>>>> values, so in that regard, setAttributes() has final say in >>>>> validating and updating invalid mpa values. >>>>> >>>>> Regarding bug, I found that if we have -ve width/height, >>>>> MediaPrintable constructor throws IAE if width/height is -ve so >>>>> mpa values set by user will not be added to pageAttributes (even >>>>> if there was valid x,y mpa values) >>>>> therefore we fallback to Java default paper size and so we will >>>>> get mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() >>>>> so to avoid IAE and to use user-set valid values, I have modified >>>>> the code to constrain iw/ih with requested ix/iy as you suggested. >>>>> >>>>> Please find the modified webrev: >>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 5/31/2016 10:12 PM, Phil Race wrote: >>>>>> Well ... few printers can print on the entire paper. Photo >>>>>> printers are >>>>>> the ones that can do this. So Paper dimension minus the "hardware >>>>>> margins" >>>>>> are the maximum imageable width. >>>>>> And then supposing imageable x/y is some perfectly reasonable >>>>>> value like 1" each >>>>>> then you've set iw/ih such that even a printer with zero hardware >>>>>> margins has >>>>>> an imageable area that goes off the bottom and right off the paper. >>>>>> >>>>>> More reasonable would be to constrain iw/ih such that they work >>>>>> with the >>>>>> requested ix/iy - assuming they are also valid. >>>>>> >>>>>> If all else fails then just using the "default" set of values as >>>>>> if the application >>>>>> had not set any values would be better. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> I got it rectified. >>>>>>> >>>>>>> Please find the modified webrev >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >>>>>>> >>>>>>> Regarding using entire width/height pf paper, I thought since >>>>>>> imageable width/height is invalid we should make the entire >>>>>>> paper as the imageable area.For invalid x,y we were making it to >>>>>>> paper's top/left. >>>>>>> Else what option do we have, should we calculate >>>>>>> width[height]=abs(image[width][height]) instead? >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 5/25/2016 10:07 PM, Philip Race wrote: >>>>>>>> It seems to me that you are using the wrong units. >>>>>>>> You have not divided by DPI to get inches. >>>>>>>> >>>>>>>> Also I am not sure that the *entire* width/height of the paper >>>>>>>> is what you want here >>>>>>>> but that is secondary to the first issue >>>>>>>> >>>>>>>> -phil >>>>>>>> >>>>>>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review a fix for jdk9 which is a continuation of the >>>>>>>>> fix of JDK-6543815. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>>>>>>> >>>>>>>>> 6543815 fix resets the x,y to 0 if they are negative before >>>>>>>>> creating a MediaPrintableArea and the platform replaces it >>>>>>>>> with hardware margins when printing. >>>>>>>>> This works only if x/y is negative. >>>>>>>>> But, If either width/height is negative alongwith x or y, then >>>>>>>>> the margin is set to the java def 1 inch margin and not >>>>>>>>> hardware margins. >>>>>>>>> >>>>>>>>> This is because width/height -ve results in IAE in >>>>>>>>> MediaPrintableArea constructor and so values are ignored. >>>>>>>>> Added a check for -ve width/height to make sure width/height >>>>>>>>> are set to minimum paper width/height. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jul 20 15:14:08 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 20 Jul 2016 08:14:08 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4882305: StreamPrintServ.getSupportedAttributeValues returns null for Orientation attr In-Reply-To: <578756D2.1010801@oracle.com> References: <578756D2.1010801@oracle.com> Message-ID: <578F9540.1090601@oracle.com> +1 -phil. On 7/14/16, 2:09 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that > even though StreamPrintService returns OrientationRequested category > as supported, when actually querying the supported attribute value > with respect to the supported DocFlavors, > *null* values are returned for the Orientation attributes when the > DocFlavor is not either Pageable or Printable (SERVICE_FORMATTED) > *BUT* we can print a jpeg iamge using StreamPrintService in LANDSCAPE > mode and it worked fine so StreamPrintService should not return the > supported values as null for supported DocFlavor. > > Bug: https://bugs.openjdk.java.net/browse/JDK-4882305 > webrev: http://cr.openjdk.java.net/~psadhukhan/4882305/webrev.00/ > > Proposed fix is to add the image/jpeg, image/gif, image/png docflavor > in addition to Pageable/Printable for Orientation attribute. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jul 20 15:26:42 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 20 Jul 2016 08:26:42 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <578CBD19.6000303@oracle.com> References: <578CBD19.6000303@oracle.com> Message-ID: <578F9832.1080906@oracle.com> In my evaluation of that bug (which was 9 yrs ago so I do not have any memory of it :-)), I note that we first need to check that job-sheets is supported .. you are not doing that .. what happens if we pass an unsupported option ? "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. Also -J (job-title) is something you can see in the queue when you do lpq. I don't know why it is tied to banner here but removing it seems wrong. Perhaps this should be renamed from "banner" and "BANNER" to jobTitle ?? Please examine this. In fact you seem to be conflicting with the -o nobanner. So in general we have some lack of clarity around job title and banner page (aka job sheet). Also we have PSPrinterJob and UnixPrinterJob with similar code. Please examine it to make sure no similar case is going missed. -phil. On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that Banner page in > linux does not get printed despite user selecting the Banner page > checkbox in Printer dialog. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 > webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ > > It seems if we pass "-J " option to lpr command, it has no > effect. > To print Banner page, we need to pass > "-o job-sheets= "standard", "topsecret", or "unclassified">" > > Since we support only standard banner or none via a checkbox, > the proposed fix passes option "-o job-sheets=standard" to lpr command > to print the banner page. > > Regards > PRasanta From vadim.pakhnushev at oracle.com Wed Jul 20 15:36:28 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 20 Jul 2016 18:36:28 +0300 Subject: [OpenJDK 2D-Dev] RFR(S): 8161923: Fix two memory issues. In-Reply-To: <1b31ead91a874c02997770b88350ea57@DEWDFE13DE09.global.corp.sap> References: <1b31ead91a874c02997770b88350ea57@DEWDFE13DE09.global.corp.sap> Message-ID: <5c34aec2-2f6e-817a-6128-8d37e0a54422@oracle.com> Hi Goetz, Maybe instead of increasing the stack size we could move the increment from the assignment to the previous if statement where we check for the overwrite possibility? There are similar code patterns in this file. Also there is almost identical file LigatureSubstProc.cpp which also contains similar code. Thanks, Vadim On 20.07.2016 16:13, Lindenmaier, Goetz wrote: > > Hi > > This changes fixes two memory issues. > > In awt_PrintControl.cpp, a wrong pointer is freed. > > In LigatureSubstProc2.cpp, line 157: > > stack[++mm] = componentGlyph; > > can overwrite the stack by one element. It will write > > stack[nComponents], because ++mm increments before > > accessing the array. > > Fix: increase the size of the array by one. > > Please review this change: > > http://cr.openjdk.java.net/~goetz/wr16/8161923-jdkMem/webrev.01/ > > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jul 20 16:18:57 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 20 Jul 2016 21:48:57 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8161264: RasterPrinterJob.updateAttributesWithPageFormat does redundant check In-Reply-To: <578F9468.6020805@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> <5761E7A9.1010805@oracle.com> <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> <576AB0BD.7050506@oracle.com> <57860199.8010208@oracle.com> <578F9468.6020805@oracle.com> Message-ID: <578FA471.3090106@oracle.com> No, rest of it is needed as if iw/ih is -ve, then if we do not have this lines if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); if (ih <= 0) ih = (float)(page.getPaper().getHeight()/DPI) - (iy*2); then MediaPrintable constructor will throw IAE ((ignoring valid ix/iy) and we end up with Java default 1" margin without even trying to rectify iw/ih. So, what we did was to TRY to rectify the -eve iw/ih to proper value first time and even after that, if iw/ih is -ve then this webrev says that no need to reset to 0 as having iw/ih as -ve OR 0 will result in IAE. Regards Prasanta On 7/20/2016 8:40 PM, Philip Race wrote: > By that logic all the rest of it is unneeded too ... and > the original bug was not a bug or the fix was not quite right. > This is not adding up to me. > > -phil > > On 7/13/16, 1:53 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a code cleanup for a redundant code introduced in the >> below 6601097 fix via webrev.03. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161264 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8161264/webrev.00/ >> >> This code is redundant because irrespective of iw/ih being *negative* >> or *0*, MediaPrintableArea constructor called just after @line 692 >> will throw IAE which is consumed >> and thereafter this invalid mpa value is not propagated anymore and >> we will fallback to Java default paper margin of 1". >> So, there is no need of checking for iw/ih for negative and set it to 0 . >> >> Regards >> Prasanta >> On 6/22/2016 9:07 PM, Philip Race wrote: >>> +1 .. they won't get any output with a zero-width imageable area >>> but this is last ditch fix up of excessively bad values. >>> >>> -phil. >>> >>> On 6/16/16, 11:32 PM, prasanta sadhukhan wrote: >>>> >>>> Hi Phil, >>>> >>>> Ok. I have added a check for this case in which it will fall back >>>> to default values since >>>> if ix/iy is too large then we probably will not get anything to >>>> print inside printable area if we have to leave same margin on the >>>> right/bottom of the paper. >>>> validatePaper() does not check for ix/iy too large case. >>>> >>>> Modified webrev >>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.03/ >>>> >>>> Regards >>>> Prasanta >>>> On 6/16/2016 5:11 AM, Philip Race wrote: >>>>> I did say so long as the "ix/iy" are also valid. Which means not >>>>> just positive but that they >>>>> are not too large. Consider >>>>> if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); >>>>> >>>>> if we have ix = 500 and iw = -20 for a paper with width 800 this >>>>> will result >>>>> in iw = 800 - (500*2) = -200 .. >>>>> >>>>> -phil. >>>>> >>>>> On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> As discussed offline, regarding mpa modification in both >>>>>> setAttributes() and updateAttributesWithPageFormat, I found that >>>>>> updateAttributesWithPageFormat() will be called during >>>>>> pageDialog() and setPrintable() >>>>>> whereas setAttributes() will be called during print() and >>>>>> setAttributes() called validatePaper() to validate imageable >>>>>> values, so in that regard, setAttributes() has final say in >>>>>> validating and updating invalid mpa values. >>>>>> >>>>>> Regarding bug, I found that if we have -ve width/height, >>>>>> MediaPrintable constructor throws IAE if width/height is -ve so >>>>>> mpa values set by user will not be added to pageAttributes (even >>>>>> if there was valid x,y mpa values) >>>>>> therefore we fallback to Java default paper size and so we will >>>>>> get mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() >>>>>> so to avoid IAE and to use user-set valid values, I have modified >>>>>> the code to constrain iw/ih with requested ix/iy as you suggested. >>>>>> >>>>>> Please find the modified webrev: >>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 5/31/2016 10:12 PM, Phil Race wrote: >>>>>>> Well ... few printers can print on the entire paper. Photo >>>>>>> printers are >>>>>>> the ones that can do this. So Paper dimension minus the >>>>>>> "hardware margins" >>>>>>> are the maximum imageable width. >>>>>>> And then supposing imageable x/y is some perfectly reasonable >>>>>>> value like 1" each >>>>>>> then you've set iw/ih such that even a printer with zero >>>>>>> hardware margins has >>>>>>> an imageable area that goes off the bottom and right off the paper. >>>>>>> >>>>>>> More reasonable would be to constrain iw/ih such that they work >>>>>>> with the >>>>>>> requested ix/iy - assuming they are also valid. >>>>>>> >>>>>>> If all else fails then just using the "default" set of values as >>>>>>> if the application >>>>>>> had not set any values would be better. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> I got it rectified. >>>>>>>> >>>>>>>> Please find the modified webrev >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >>>>>>>> >>>>>>>> Regarding using entire width/height pf paper, I thought since >>>>>>>> imageable width/height is invalid we should make the entire >>>>>>>> paper as the imageable area.For invalid x,y we were making it >>>>>>>> to paper's top/left. >>>>>>>> Else what option do we have, should we calculate >>>>>>>> width[height]=abs(image[width][height]) instead? >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 5/25/2016 10:07 PM, Philip Race wrote: >>>>>>>>> It seems to me that you are using the wrong units. >>>>>>>>> You have not divided by DPI to get inches. >>>>>>>>> >>>>>>>>> Also I am not sure that the *entire* width/height of the paper >>>>>>>>> is what you want here >>>>>>>>> but that is secondary to the first issue >>>>>>>>> >>>>>>>>> -phil >>>>>>>>> >>>>>>>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for jdk9 which is a continuation of the >>>>>>>>>> fix of JDK-6543815. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>>>>>>>> >>>>>>>>>> 6543815 fix resets the x,y to 0 if they are negative before >>>>>>>>>> creating a MediaPrintableArea and the platform replaces it >>>>>>>>>> with hardware margins when printing. >>>>>>>>>> This works only if x/y is negative. >>>>>>>>>> But, If either width/height is negative alongwith x or y, >>>>>>>>>> then the margin is set to the java def 1 inch margin and not >>>>>>>>>> hardware margins. >>>>>>>>>> >>>>>>>>>> This is because width/height -ve results in IAE in >>>>>>>>>> MediaPrintableArea constructor and so values are ignored. >>>>>>>>>> Added a check for -ve width/height to make sure width/height >>>>>>>>>> are set to minimum paper width/height. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jul 20 16:53:39 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 20 Jul 2016 09:53:39 -0700 (PDT) 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> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <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> Message-ID: Hi Jim, Thanks for your input. I have updated specification of ColorModel and its subclasses. Please find new webrev for review: http://cr.openjdk.java.net/~jdv/7107905/webrev.13/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, July 12, 2016 7:41 PM To: Jayathirth D V; Philip Race Cc: 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 Hi Jay, When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It looks like you copied and pasted a number of places where I wrote "{foo}" in email and just left the bare braces there, please adjust those (most of them should probably just have "@code" inserted. In ColorModel.equals(), I'd replace the entire "following properties" sentence with: * Subclasses may check additional properties, but this method * will check the following basic properties for equivalence to * determine if the target object equals this object: The text for IndexColorModel is also a little odd. I'd change it to something like: * The target object and this object will be equal iff * {@link ColorModel#equals()} returns true and the following * properties are also the same: For Packed: * The target object and this object will be equal iff * {@link ColorModel#equals()} returns true and the masks * of the color and alpha samples are the same. In terms of Joe's request, I'd add the following text to ColorModel.equals() right after we talk about all of the properties that it checks: *

* Subclasses should override this method if they have any additional * properties to compare and should use the following implementation. * Note that the base {@code ColorModel} class already ensures that * the target object is the same class as this object so the cast to * the subclass type can be assumed if {@code super.equals(obj)} returns * true. * 

*     public boolean equals(Object obj) {
*         if (!super.equals(obj)) {
*             return false;
*         }
*         MyCMClass cm = (MyCMClass) obj;
*         // test additional properties on "cm" and "this"
*     }
*
On 7/1/16 3:31 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your inputs. > I have discussed with Phil also regarding the same issue offline. > I have collated all the changes mentioned by you and Phil in the latest webrev: > http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ > > But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. > > Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, June 30, 2016 4:05 AM > 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 > > Hi Jay, > > We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: > > "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" > > Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. > > A few grammar fixes: > > In all of the classes, insert a space before any parentheses in > comment text as in "the same class (and not a subclass)". (That > wouldn't apply if the text in the comment is referring to code - then > space it as you would actual code.) > > In CM, insert the word "the" as in "also check the following ..." > > In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". > > In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". > > ...jim > > On 06/29/2016 04:13 AM, Jayathirth D V wrote: >> Hi, >> >> Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Saturday, June 04, 2016 4:52 AM >> To: Jayathirth D V; Philip Race >> Cc: 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 >> >> That looks good to me. Has the CCC cleared yet? >> >> ...jim >> >> On 6/3/16 2:49 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Oh that's an important change. >>> Thanks for your review. >>> >>> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, June 03, 2016 2:25 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>> are missing hashCode() or equals() or both methods >>> >>> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >>> >>> Possible solutions: >>> >>> - Truncate validBits when it is accepted in the constructor >>> (validBits.and(...)) >>> - Manually compute the hash of the first N bits of validBits >>> - Not use validBits in the hash code since it is allowed to omit >>> significant data from the hash >>> >>> (Note that everything in hashcode must participate in equals(), but >>> not vice versa) >>> >>> The same is true of nBits in ColorModel. (nBits can be copied and >>> truncated with Arrays.copyOf) >>> >>> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >>> >>> ...jim >>> >>> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>>> Hi Phil, >>>> >>>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>>> Please find the updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Philip Race >>>> Sent: Wednesday, June 01, 2016 10:06 PM >>>> To: Jayathirth D V >>>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>> are missing hashCode() or equals() or both methods >>>> >>>> Please post the updated webrev. >>>> >>>> -phil. >>>> >>>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>>> Hi Phil& Jim, >>>>> >>>>> Collating all the changes needed: >>>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>>> 3) Comment section of equals() method, I will update it to : >>>>> 1449 * the target object must be the same class (and not a subclass) as this >>>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>>> >>>>> Please let me know your inputs. >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>>> To: Phil Race >>>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>> are missing hashCode() or equals() or both methods >>>>> >>>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>>> >>>>> ...jim >>>>> >>>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>>> I don't know of any design intent, so yes, I meant more as a >>>>>> practical matter. >>>>>> Unless they subclass then using equals() which I thought unlikely >>>>>> it makes no difference here. >>>>>> But it would be proof against that to use equals, unlikely to >>>>>> matter as it might be .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>>> >>>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>>> Hi Jay, >>>>>>>>> >>>>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>>>> you simply removed it from the patch. You still need to edit >>>>>>>>> it to remove the existing methods. >>>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>>>> not intentional. >>>>>>>> >>>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>>> instances >>>>>>>>> - Phil? >>>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>>> hashCode and all the predefined ones are constructed as >>>>>>>> singletons so it seems unlikely to cause problems >>>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>>> baking in the assumption that it doesn't implement equals() into >>>>>>> our implementation of the CM.equals() method. Might it some day >>>>>>> implement equals (perhaps it isn't a practical issue today, but >>>>>>> it might be in the future when we forget that it was omitted in >>>>>>> this usage we create today). >>>>>>> >>>>>>> I guess what I'm asking is if it is a design feature that >>>>>>> different objects are considered non-equal (such as an object >>>>>>> that, for instance, has only predetermined instances that are >>>>>>> shared by reference and reused). I think color spaces are sort >>>>>>> of in-between in that we define a few constants that simply get >>>>>>> used by reference in 99% of cases, but that isn't a design >>>>>>> feature, more like a practical issue... >>>>>>> >>>>>>> ...jim From bourges.laurent at gmail.com Thu Jul 21 13:56:55 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 21 Jul 2016 15:56:55 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> Message-ID: Dear Jim, Thanks for your review, I'll answer your questions in the text below and will later propose a new webrev: 2016-07-19 9:00 GMT+02:00 Jim Graham : > > Some work should be done on the comments at the top of ArrayCache.java - > line 38 and 42 make the same claim about 2 different thresholds. I agree THRESHOLD_LARGE_ARRAY_SIZE can be removed as THRESHOLD_ARRAY_SIZE = THRESHOLD_LARGE_ARRAY_SIZE now ! > It seems silly, but in ArrayCache.getNewLargeSize(), lines 162 and 164 are > both ">" tests and then the newly added test at 166 is a "<" test. It > would be nice to main symmetry of the tests in that if/then/elseif sequence. > Will do. > As far as I can see, the buckets are: > > 0 - 4K > 1 - 16k > 2 - 64k > 3 - 256k > 4 - 1m > 5 - 4m > 6 - 8m > 7 - 16m > > which makes MAX_ARRAY_SIZE == THRESHOLD_ARRAY_SIZE == 16m and > THRESHOLD_LARGE is also 16m...? > As theses values are all equals now, I will only keep MAX_ARRAY_SIZE (= maximum size of cached array in buckets) and fix the getNewSize() and getNewLargeSize() to use that value as the threshold. > I don't have any issues with those numbers, but the way that they are > calculated makes it look like they are supposed to be unique numbers and > yet through the obscurity of the loops used to populate the sizes they just > end up all being the same numbers - it makes me wonder if there was a > mistake in there or not...? > Initially these values have different values / meanings but it can be simplified now. > CacheStats.reset() - should totalInitial be reset as well? Also, there > should be a reset method on the BucketStats class rather than just digging > in and modifying its members directly from outside the class. > Initial arrays are allocated by the Reference constructor so totalInitial must not be reset to give the total memory allocated by initial arrays. Will add the BucketStats.reset() method. > It feels odd to have all of the cache classes import the static members of > ArrayCache rather than just subclassing it. Is there a reason it wasn't > just subclassed? > As all the members are static, I prefer having an explicit static import instead of subclasses. Moreover, I deliberately avoided any class inheritance to avoid the performance penalty of bimorphic / megamorphic method calls (abstract or overriden methods). > The Dirty and Clean subclasses are nearly identical and yet they share no > code simply because buried inside one of their inner classes one of them > clears the data and the other does not. That seems a waste for something > so trivial in the design. > The only reason is performance: I want to ensure straightforward method calls ie no bimorphic or virtual calls to be inlined by hotspot. Maybe such fear or approach is too conservative i.e. the performance penalty is too small to consider such optimization. I made many tests with jmh (in june) but I agree the design can be simpler: - abstract [Byte/Int/Float]ArrayCache (where putArray() is abstract) - Clean[Byte/Int/Float]ArrayCache and Dirty[Byte/Int/Float]ArrayCache implements properly the putArray method but also the createArray() method (new array or Unsafe.allocateUninitializedArray) I could try again but I prefer the current design as it is (overly) strongly typed. Please propose an alternative / simpler design ! > The various Reference.putArray() methods protect against putting the > initial arrays, and you the code that calls them also makes the same > check. I'd remove the code that checks for initial from the callers so > that the call sites are more streamlined, but there's no functional issue > with the way it is now. > I will improve that and that will save several tests / lines. FYI I adopted the double-checks to promote the initial array case as the fast path whereas the array cache is the slow path (less probable / exceptional). Typically hotspot optimizes very well such code when only initial arrays are in use (general use case). > Also, since you never put the initial arrays, they aren't automatically > cleaned...? > Exactly: initial arrays are allocated by the Reference class and directly used by callers (fill / clean) and the XxxArrayCache never touch them. Only CleanIntArrayCache.Reference are used by Marlin: - MarlinCache 116: touchedTile_ref = rdrCtx.newCleanIntArrayRef(INITIAL_ARRAY); // 1K = 1 tile line - Renderer 549: edgeBuckets_ref = rdrCtx.newCleanIntArrayRef(INITIAL_BUCKET_ARRAY); // 64K 550: edgeBucketCounts_ref = rdrCtx.newCleanIntArrayRef(INITIAL_BUCKET_ARRAY); // 64K 556: alphaLine_ref = rdrCtx.newCleanIntArrayRef(INITIAL_AA_ARRAY); // 8K 571: blkFlags_ref = rdrCtx.newCleanIntArrayRef(INITIAL_ARRAY); // 1K = 1 tile line All cases are manually cleaned in MarlinCache.resetTileLine(), Renderer.dispose() and MarlinCache.copyAARowNoRLE...() for alphaLine and blkFlags arrays with several cleanup patterns (optimized and performance-critical). > Is the shell script only used by you to replicate changes from the Byte > classes to the Int/Float classes? A shell comment at the top would be nice > to explain that... > Yes. Will do. > The only issue above is whether or not the initial arrays are missing a > clean pass on them due to the fact that they get rejected by the put > methods. All of the others are simply comments to engage some discussion > on the design elements... > Please give me your feedback and discuss the design (with performance considerations in mind). Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 21 16:57:24 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 21 Jul 2016 09:57:24 -0700 Subject: [OpenJDK 2D-Dev] RFR (urgent) 8162097: [PIT] A series of closed tests about SunFontManager throw NPE on Windows Message-ID: <5790FEF4.1010904@oracle.com> http://cr.openjdk.java.net/~prr/8162097/ I have an urgent RFR which is blocking PIT. The fix : https://bugs.openjdk.java.net/browse/JDK-8152971 to eliminate some JNI warnings. is prematurely deleting a local ref which is used in a callback function. As as result we get many NPEs in Java code. The fix is to move the (normal case) delete to after we've done with the callback. The tests which failed before this fix now pass. Also the JNI check test is not seeing "new" issues .. there are already JNI warnings that it finds in other code. -phil. From jayathirth.d.v at oracle.com Thu Jul 21 17:15:14 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 21 Jul 2016 10:15:14 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4882305: StreamPrintServ.getSupportedAttributeValues returns null for Orientation attr In-Reply-To: <578F9540.1090601@oracle.com> References: <578756D2.1010801@oracle.com> <578F9540.1090601@oracle.com> Message-ID: <587675a0-9ea3-458e-8418-0994e57dccef@default> Hi Prasanta, ? You have many lines of commented code in test case, which is not needed. Also there are cases of null pointer dereferencing at line 68 & 70 in test case. Please add checks for the same. And you can add bug evaluation in JBS for the same. ? Thanks, Jay ? From: Philip Race Sent: Wednesday, July 20, 2016 8:14 AM To: Prasanta Sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4882305: StreamPrintServ.getSupportedAttributeValues returns null for Orientation attr ? +1 -phil. On 7/14/16, 2:09 AM, Prasanta Sadhukhan wrote: Hi All, Please review a fix for an issue where it is seen that even though StreamPrintService returns OrientationRequested category as supported, when actually querying the supported attribute value with respect to the supported DocFlavors, null values are returned for the Orientation attributes when the DocFlavor is not either Pageable or Printable (SERVICE_FORMATTED) BUT we can print a jpeg iamge using StreamPrintService in LANDSCAPE mode and it worked fine so StreamPrintService should not return the supported values as null for supported DocFlavor. Bug: https://bugs.openjdk.java.net/browse/JDK-4882305 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/4882305/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/4882305/webrev.00/ Proposed fix is to add the image/jpeg, image/gif, image/png docflavor in addition to Pageable/Printable for Orientation attribute. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Jul 21 17:54:13 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Jul 2016 10:54:13 -0700 Subject: [OpenJDK 2D-Dev] RFR (urgent) 8162097: [PIT] A series of closed tests about SunFontManager throw NPE on Windows In-Reply-To: <5790FEF4.1010904@oracle.com> References: <5790FEF4.1010904@oracle.com> Message-ID: This looks fine as far as I can see. Brian On Jul 21, 2016, at 9:57 AM, Phil Race wrote: > http://cr.openjdk.java.net/~prr/8162097/ > > I have an urgent RFR which is blocking PIT. > > The fix : https://bugs.openjdk.java.net/browse/JDK-8152971 to eliminate some JNI warnings. > > is prematurely deleting a local ref which is used in a callback function. > As as result we get many NPEs in Java code. > The fix is to move the (normal case) delete to after we've done with the callback. > > The tests which failed before this fix now pass. > Also the JNI check test is not seeing "new" issues .. there are already JNI warnings > that it finds in other code. > > -phil. From philip.race at oracle.com Thu Jul 21 21:01:25 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 21 Jul 2016 14:01:25 -0700 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> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <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> Message-ID: <57913825.4090609@oracle.com> OK by me. -phil. On 07/20/2016 09:53 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your input. > I have updated specification of ColorModel and its subclasses. > Please find new webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.13/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, July 12, 2016 7:41 PM > To: Jayathirth D V; Philip Race > Cc: 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 > > Hi Jay, > > When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It looks like you copied and pasted a number of places where I wrote "{foo}" in email and just left the bare braces there, please adjust those (most of them should probably just have "@code" inserted. > > In ColorModel.equals(), I'd replace the entire "following properties" sentence with: > > * Subclasses may check additional properties, but this method > * will check the following basic properties for equivalence to > * determine if the target object equals this object: > > The text for IndexColorModel is also a little odd. I'd change it to something like: > > * The target object and this object will be equal iff > * {@link ColorModel#equals()} returns true and the following > * properties are also the same: > > For Packed: > > * The target object and this object will be equal iff > * {@link ColorModel#equals()} returns true and the masks > * of the color and alpha samples are the same. > > In terms of Joe's request, I'd add the following text to ColorModel.equals() right after we talk about all of the properties that it checks: > > *

> * Subclasses should override this method if they have any additional > * properties to compare and should use the following implementation. > * Note that the base {@code ColorModel} class already ensures that > * the target object is the same class as this object so the cast to > * the subclass type can be assumed if {@code super.equals(obj)} returns > * true. > * 

> *     public boolean equals(Object obj) {
> *         if (!super.equals(obj)) {
> *             return false;
> *         }
> *         MyCMClass cm = (MyCMClass) obj;
> *         // test additional properties on "cm" and "this"
> *     }
> *
> > > On 7/1/16 3:31 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your inputs. >> I have discussed with Phil also regarding the same issue offline. >> I have collated all the changes mentioned by you and Phil in the latest webrev: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ >> >> But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. >> >> Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, June 30, 2016 4:05 AM >> 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 >> >> Hi Jay, >> >> We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: >> >> "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" >> >> Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. >> >> A few grammar fixes: >> >> In all of the classes, insert a space before any parentheses in >> comment text as in "the same class (and not a subclass)". (That >> wouldn't apply if the text in the comment is referring to code - then >> space it as you would actual code.) >> >> In CM, insert the word "the" as in "also check the following ..." >> >> In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". >> >> In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". >> >> ...jim >> >> On 06/29/2016 04:13 AM, Jayathirth D V wrote: >>> Hi, >>> >>> Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, June 04, 2016 4:52 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 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 >>> >>> That looks good to me. Has the CCC cleared yet? >>> >>> ...jim >>> >>> On 6/3/16 2:49 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> Oh that's an important change. >>>> Thanks for your review. >>>> >>>> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, June 03, 2016 2:25 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>> are missing hashCode() or equals() or both methods >>>> >>>> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >>>> >>>> Possible solutions: >>>> >>>> - Truncate validBits when it is accepted in the constructor >>>> (validBits.and(...)) >>>> - Manually compute the hash of the first N bits of validBits >>>> - Not use validBits in the hash code since it is allowed to omit >>>> significant data from the hash >>>> >>>> (Note that everything in hashcode must participate in equals(), but >>>> not vice versa) >>>> >>>> The same is true of nBits in ColorModel. (nBits can be copied and >>>> truncated with Arrays.copyOf) >>>> >>>> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >>>> >>>> ...jim >>>> >>>> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>>>> Hi Phil, >>>>> >>>>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>>>> Please find the updated webrev for review: >>>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Philip Race >>>>> Sent: Wednesday, June 01, 2016 10:06 PM >>>>> To: Jayathirth D V >>>>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>> are missing hashCode() or equals() or both methods >>>>> >>>>> Please post the updated webrev. >>>>> >>>>> -phil. >>>>> >>>>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>>>> Hi Phil& Jim, >>>>>> >>>>>> Collating all the changes needed: >>>>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>>>> 3) Comment section of equals() method, I will update it to : >>>>>> 1449 * the target object must be the same class (and not a subclass) as this >>>>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>>>> >>>>>> Please let me know your inputs. >>>>>> >>>>>> Thanks, >>>>>> Jay >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jim Graham >>>>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>>>> To: Phil Race >>>>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>>> are missing hashCode() or equals() or both methods >>>>>> >>>>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>>>> I don't know of any design intent, so yes, I meant more as a >>>>>>> practical matter. >>>>>>> Unless they subclass then using equals() which I thought unlikely >>>>>>> it makes no difference here. >>>>>>> But it would be proof against that to use equals, unlikely to >>>>>>> matter as it might be .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>>>> Hi Jay, >>>>>>>>>> >>>>>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>>>>> you simply removed it from the patch. You still need to edit >>>>>>>>>> it to remove the existing methods. >>>>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>>>>> not intentional. >>>>>>>>> >>>>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>>>> instances >>>>>>>>>> - Phil? >>>>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>>>> hashCode and all the predefined ones are constructed as >>>>>>>>> singletons so it seems unlikely to cause problems >>>>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>>>> baking in the assumption that it doesn't implement equals() into >>>>>>>> our implementation of the CM.equals() method. Might it some day >>>>>>>> implement equals (perhaps it isn't a practical issue today, but >>>>>>>> it might be in the future when we forget that it was omitted in >>>>>>>> this usage we create today). >>>>>>>> >>>>>>>> I guess what I'm asking is if it is a design feature that >>>>>>>> different objects are considered non-equal (such as an object >>>>>>>> that, for instance, has only predetermined instances that are >>>>>>>> shared by reference and reused). I think color spaces are sort >>>>>>>> of in-between in that we define a few constants that simply get >>>>>>>> used by reference in 99% of cases, but that isn't a design >>>>>>>> feature, more like a practical issue... >>>>>>>> >>>>>>>> ...jim From james.graham at oracle.com Thu Jul 21 21:21:59 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 21 Jul 2016 14:21:59 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: <5b1abcf8-d755-4d4c-b3a8-d8cc9a89c424@default> References: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> <578674F8.1050905@oracle.com> <5b1abcf8-d755-4d4c-b3a8-d8cc9a89c424@default> Message-ID: <7e16e9c9-2ddd-0f9f-ab1d-d77f830cc08c@oracle.com> Hi Jay, How did you generate that image with thumbnail? With ImageIO? ...jim On 07/19/2016 12:18 PM, Jayathirth D V wrote: > Hi Phil, > > I generated Jpeg image with thumbnail as given in test case attached for https://bugs.openjdk.java.net/browse/JDK-4958271 with JDK 9. > The image has only two APP0 markers and after the second marker it has "00 FF" which we can consider as "X FF" as per https://www.w3.org/Graphics/JPEG/itu-t81.pdf. But it is just continuation of pattern "00 00 FF" which we see around the end of second APP0 marker. > > For this new image I don't see whether we are writing improperly in JDK9(If we consider "X FF" bits between markers). > So we can just apply http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ and open up the test case(after verifying whether it is the only test case which uses this particular image) with new image that I have created. > > Thanks, > Jay > > -----Original Message----- > From: Philip Race > Sent: Wednesday, July 13, 2016 10:06 AM > To: Jim Graham > Cc: Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java > > Whilst looking at the reason this test was originally created > https://bugs.openjdk.java.net/browse/JDK-4958271 > it started to look likely that the image was (as I sort of suspected) was generated by IIO itself. > > I think there a couple of things we can do here > 1) Open up the test (and image - although if moving it make sure no other tests in that location need the image). > 2) Investigate to see if the bug such that the "bad padding" is written out is still reproducible with current IIO ... or if it was fixed sometime between when that image was created and now. > > -phil. > > On 7/12/16, 7:48 PM, Jim Graham wrote: >> I think this is fine, but I noticed that some of the recently added >> comments have some grammar issues. It might be nice to change the >> following: >> >> 565 // markers which do not contain length data >> (doesn't => do not) >> >> 576 // markers which contain length data >> (contains => contain) >> >> I don't need to review those changes... >> >> ...jim >> >> On 7/12/16 9:15 AM, Jayathirth D V wrote: >>> Hi, >>> >>> >>> >>> Thanks for your input Phil. >>> >>> I have made changes just to parse "FF FF"(Like "FF 00" or any marker >>> without length)and not consider it as an invalid marker in >>> skipImage() of JPEGImageReader.java. >>> >>> Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java >>> from ProblemList.txt as part of fix. >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 >>> >>> >>> >>> Please find webrev for review for JDK9: >>> >>> http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> >>> *From:*Phil Race >>> *Sent:* Saturday, July 09, 2016 12:37 AM >>> *To:* Jayathirth D V >>> *Cc:* Jim Graham; 2d-dev >>> *Subject:* Re: REG : JDK-8160943 : [PIT] new failure of >>> closed/javax/imageio/ReadAllThumbnailsTest.java >>> >>> >>> >>> On 07/08/2016 04:08 AM, Jayathirth D V wrote: >>> >>> Hi, >>> >>> >>> >>> In JDK-8152672 >>> we modified skipImage() in JpegImageReader.java >>> and added tighter checks for parsing Jpeg data. >>> >>> >>> >>> We have to find any marker,0 or EOF after we find "FF" while >>> parsing JPEG data. >>> >>> But in JDK-8160943 >>> we have gap >>> between APP0 marker and DQT(FF DB) >>> marker which contains data "00 FF". >>> >>> >>> >>> APP0_End -> 00 FF -> FF DB(DQT) >>> >>> >>> >>> So after we skip APP0 marker we find two bytes of data which is >>> "FF FF". In the present code we consider this as >>> invalid marker. >>> >>> >>> See https://www.w3.org/Graphics/JPEG/itu-t81.pdf >>> >>> B.1.1.2 Markers >>> Markers serve to identify the various structural parts of the >>> compressed data formats. >>> Most markers start marker segments containing a related group of >>> parameters; some markers stand alone. All markers are assigned >>> two-byte codes: an X'FF' byte followed by a byte which is not equal >>> to 0 or X'FF' (see Table B.1). >>> Any marker may optionally be preceded by any number of fill bytes, >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> which are bytes assigned code X'FF >>> ^^^^^^^^^^^^^^^^^^^^^^ >>> >>> -phil. >>> >>> >>> Because of this JDK-8160943 >>> is failing. >>> >>> >>> >>> Is the length of APP0 marker not valid in the image or we should >>> not consider "FF FF" as invalid maker? >>> >>> Please let me know your input. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> From james.graham at oracle.com Thu Jul 21 21:41:34 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 21 Jul 2016 14:41:34 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> Message-ID: <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> Hi Laurent, On 07/21/2016 06:56 AM, Laurent Bourg?s wrote: > I don't have any issues with those numbers, but the way that they > are calculated makes it look like they are supposed to be unique > numbers and yet through the obscurity of the loops used to populate > the sizes they just end up all being the same numbers - it makes me > wonder if there was a mistake in there or not...? > > > Initially these values have different values / meanings but it can be > simplified now. To be clear, I wasn't complaining about the multitude of thresholds, but rather that the way they were apportioned - sort of as a side effect of the computations in a loop - ended up accidentally squashing a couple of them out of existence. Another option would be to make sure that the thresholds make sense, but keep all 4 threshold ranges, but you are the one who knows the details of how these sizes impact performance... > It feels odd to have all of the cache classes import the static > members of ArrayCache rather than just subclassing it. Is there a > reason it wasn't just subclassed? > > > As all the members are static, I prefer having an explicit static import > instead of subclasses. > Moreover, I deliberately avoided any class inheritance to avoid the > performance penalty of bimorphic / megamorphic method calls (abstract or > overriden methods). First, I would have expected MumbleArrayCache classes to be a subclass of the ArrayCache class in the first place. If it is not going to be the base class then it should have the name "ArrayCacheUtils" or "Const" or something. Second, wildcard imports are recommended against. Finally, if you are going to use static methods from another class I would much rather see explicit naming rather than importing them. While static imports work for methods as well as constants, they are typically used for constants and it is confusing to apply them to methods. > The only reason is performance: I want to ensure straightforward method > calls ie no bimorphic or virtual calls to be inlined by hotspot. Maybe > such fear or approach is too conservative i.e. the performance penalty > is too small to consider such optimization. I made many tests with jmh > (in june) but I agree the design can be simpler: > - abstract [Byte/Int/Float]ArrayCache (where putArray() is abstract) > - Clean[Byte/Int/Float]ArrayCache and Dirty[Byte/Int/Float]ArrayCache > implements properly the putArray method but also the createArray() > method (new array or Unsafe.allocateUninitializedArray) > > I could try again but I prefer the current design as it is (overly) > strongly typed. > Please propose an alternative / simpler design ! That's something that can be investigated later as it would be a big disruption for the current task. Generally, though, as long as the leaf classes are final and the cache classes are strongly typed then HS should inline freely. > Also, since you never put the initial arrays, they aren't > automatically cleaned...? > > Exactly: initial arrays are allocated by the Reference class and > directly used by callers (fill / clean) and the XxxArrayCache never > touch them. What I was getting at was that this was potentially a bug? If you carry over use of an initial array in a clean setting without calling to the cache object, then who clears the used portion? > All cases are manually cleaned in MarlinCache.resetTileLine(), > Renderer.dispose() and MarlinCache.copyAARowNoRLE...() for alphaLine and > blkFlags arrays with several cleanup patterns (optimized and > performance-critical). I see. Is this really a noticeable performance issue to rely on the cache to do the cleaning and have much more readable code? ...jim From james.graham at oracle.com Thu Jul 21 21:45:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 21 Jul 2016 14:45:26 -0700 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> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <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> Message-ID: <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> Looks good to me... ...jim On 07/20/2016 09:53 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your input. > I have updated specification of ColorModel and its subclasses. > Please find new webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.13/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, July 12, 2016 7:41 PM > To: Jayathirth D V; Philip Race > Cc: 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 > > Hi Jay, > > When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It looks like you copied and pasted a number of places where I wrote "{foo}" in email and just left the bare braces there, please adjust those (most of them should probably just have "@code" inserted. > > In ColorModel.equals(), I'd replace the entire "following properties" sentence with: > > * Subclasses may check additional properties, but this method > * will check the following basic properties for equivalence to > * determine if the target object equals this object: > > The text for IndexColorModel is also a little odd. I'd change it to something like: > > * The target object and this object will be equal iff > * {@link ColorModel#equals()} returns true and the following > * properties are also the same: > > For Packed: > > * The target object and this object will be equal iff > * {@link ColorModel#equals()} returns true and the masks > * of the color and alpha samples are the same. > > In terms of Joe's request, I'd add the following text to ColorModel.equals() right after we talk about all of the properties that it checks: > > *

> * Subclasses should override this method if they have any additional > * properties to compare and should use the following implementation. > * Note that the base {@code ColorModel} class already ensures that > * the target object is the same class as this object so the cast to > * the subclass type can be assumed if {@code super.equals(obj)} returns > * true. > * 

> *     public boolean equals(Object obj) {
> *         if (!super.equals(obj)) {
> *             return false;
> *         }
> *         MyCMClass cm = (MyCMClass) obj;
> *         // test additional properties on "cm" and "this"
> *     }
> *
> > > On 7/1/16 3:31 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your inputs. >> I have discussed with Phil also regarding the same issue offline. >> I have collated all the changes mentioned by you and Phil in the latest webrev: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ >> >> But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. >> >> Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, June 30, 2016 4:05 AM >> 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 >> >> Hi Jay, >> >> We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: >> >> "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" >> >> Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. >> >> A few grammar fixes: >> >> In all of the classes, insert a space before any parentheses in >> comment text as in "the same class (and not a subclass)". (That >> wouldn't apply if the text in the comment is referring to code - then >> space it as you would actual code.) >> >> In CM, insert the word "the" as in "also check the following ..." >> >> In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". >> >> In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". >> >> ...jim >> >> On 06/29/2016 04:13 AM, Jayathirth D V wrote: >>> Hi, >>> >>> Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, June 04, 2016 4:52 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 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 >>> >>> That looks good to me. Has the CCC cleared yet? >>> >>> ...jim >>> >>> On 6/3/16 2:49 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> Oh that's an important change. >>>> Thanks for your review. >>>> >>>> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, June 03, 2016 2:25 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>> are missing hashCode() or equals() or both methods >>>> >>>> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >>>> >>>> Possible solutions: >>>> >>>> - Truncate validBits when it is accepted in the constructor >>>> (validBits.and(...)) >>>> - Manually compute the hash of the first N bits of validBits >>>> - Not use validBits in the hash code since it is allowed to omit >>>> significant data from the hash >>>> >>>> (Note that everything in hashcode must participate in equals(), but >>>> not vice versa) >>>> >>>> The same is true of nBits in ColorModel. (nBits can be copied and >>>> truncated with Arrays.copyOf) >>>> >>>> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >>>> >>>> ...jim >>>> >>>> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>>>> Hi Phil, >>>>> >>>>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>>>> Please find the updated webrev for review: >>>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Philip Race >>>>> Sent: Wednesday, June 01, 2016 10:06 PM >>>>> To: Jayathirth D V >>>>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>> are missing hashCode() or equals() or both methods >>>>> >>>>> Please post the updated webrev. >>>>> >>>>> -phil. >>>>> >>>>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>>>> Hi Phil& Jim, >>>>>> >>>>>> Collating all the changes needed: >>>>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>>>> 3) Comment section of equals() method, I will update it to : >>>>>> 1449 * the target object must be the same class (and not a subclass) as this >>>>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>>>> >>>>>> Please let me know your inputs. >>>>>> >>>>>> Thanks, >>>>>> Jay >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jim Graham >>>>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>>>> To: Phil Race >>>>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>>> are missing hashCode() or equals() or both methods >>>>>> >>>>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>>>> I don't know of any design intent, so yes, I meant more as a >>>>>>> practical matter. >>>>>>> Unless they subclass then using equals() which I thought unlikely >>>>>>> it makes no difference here. >>>>>>> But it would be proof against that to use equals, unlikely to >>>>>>> matter as it might be .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>>>> >>>>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>>>> Hi Jay, >>>>>>>>>> >>>>>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>>>>> you simply removed it from the patch. You still need to edit >>>>>>>>>> it to remove the existing methods. >>>>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>>>>> not intentional. >>>>>>>>> >>>>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>>>> instances >>>>>>>>>> - Phil? >>>>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>>>> hashCode and all the predefined ones are constructed as >>>>>>>>> singletons so it seems unlikely to cause problems >>>>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>>>> baking in the assumption that it doesn't implement equals() into >>>>>>>> our implementation of the CM.equals() method. Might it some day >>>>>>>> implement equals (perhaps it isn't a practical issue today, but >>>>>>>> it might be in the future when we forget that it was omitted in >>>>>>>> this usage we create today). >>>>>>>> >>>>>>>> I guess what I'm asking is if it is a design feature that >>>>>>>> different objects are considered non-equal (such as an object >>>>>>>> that, for instance, has only predetermined instances that are >>>>>>>> shared by reference and reused). I think color spaces are sort >>>>>>>> of in-between in that we define a few constants that simply get >>>>>>>> used by reference in 99% of cases, but that isn't a design >>>>>>>> feature, more like a practical issue... >>>>>>>> >>>>>>>> ...jim From jayathirth.d.v at oracle.com Thu Jul 21 21:46:20 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 21 Jul 2016 14:46:20 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: <7e16e9c9-2ddd-0f9f-ab1d-d77f830cc08c@oracle.com> References: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> <578674F8.1050905@oracle.com> <5b1abcf8-d755-4d4c-b3a8-d8cc9a89c424@default> <7e16e9c9-2ddd-0f9f-ab1d-d77f830cc08c@oracle.com> Message-ID: <63fe6280-4b04-4d0d-9a38-0ff9b667e131@default> Hi Jim, I just ran the test case attached in https://bugs.openjdk.java.net/browse/JDK-4958271 . It is actually generating an image and using it to do reader.readAll(). Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, July 21, 2016 2:22 PM To: Jayathirth D V; Philip Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java Hi Jay, How did you generate that image with thumbnail? With ImageIO? ...jim On 07/19/2016 12:18 PM, Jayathirth D V wrote: > Hi Phil, > > I generated Jpeg image with thumbnail as given in test case attached for https://bugs.openjdk.java.net/browse/JDK-4958271 with JDK 9. > The image has only two APP0 markers and after the second marker it has "00 FF" which we can consider as "X FF" as per https://www.w3.org/Graphics/JPEG/itu-t81.pdf. But it is just continuation of pattern "00 00 FF" which we see around the end of second APP0 marker. > > For this new image I don't see whether we are writing improperly in JDK9(If we consider "X FF" bits between markers). > So we can just apply http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ and open up the test case(after verifying whether it is the only test case which uses this particular image) with new image that I have created. > > Thanks, > Jay > > -----Original Message----- > From: Philip Race > Sent: Wednesday, July 13, 2016 10:06 AM > To: Jim Graham > Cc: Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] > new failure of closed/javax/imageio/ReadAllThumbnailsTest.java > > Whilst looking at the reason this test was originally created > https://bugs.openjdk.java.net/browse/JDK-4958271 > it started to look likely that the image was (as I sort of suspected) was generated by IIO itself. > > I think there a couple of things we can do here > 1) Open up the test (and image - although if moving it make sure no other tests in that location need the image). > 2) Investigate to see if the bug such that the "bad padding" is written out is still reproducible with current IIO ... or if it was fixed sometime between when that image was created and now. > > -phil. > > On 7/12/16, 7:48 PM, Jim Graham wrote: >> I think this is fine, but I noticed that some of the recently added >> comments have some grammar issues. It might be nice to change the >> following: >> >> 565 // markers which do not contain length data >> (doesn't => do not) >> >> 576 // markers which contain length data >> (contains => contain) >> >> I don't need to review those changes... >> >> ...jim >> >> On 7/12/16 9:15 AM, Jayathirth D V wrote: >>> Hi, >>> >>> >>> >>> Thanks for your input Phil. >>> >>> I have made changes just to parse "FF FF"(Like "FF 00" or any marker >>> without length)and not consider it as an invalid marker in >>> skipImage() of JPEGImageReader.java. >>> >>> Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java >>> from ProblemList.txt as part of fix. >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 >>> >>> >>> >>> Please find webrev for review for JDK9: >>> >>> http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> >>> *From:*Phil Race >>> *Sent:* Saturday, July 09, 2016 12:37 AM >>> *To:* Jayathirth D V >>> *Cc:* Jim Graham; 2d-dev >>> *Subject:* Re: REG : JDK-8160943 : [PIT] new failure of >>> closed/javax/imageio/ReadAllThumbnailsTest.java >>> >>> >>> >>> On 07/08/2016 04:08 AM, Jayathirth D V wrote: >>> >>> Hi, >>> >>> >>> >>> In JDK-8152672 >>> >>> we modified skipImage() in JpegImageReader.java >>> and added tighter checks for parsing Jpeg data. >>> >>> >>> >>> We have to find any marker,0 or EOF after we find "FF" while >>> parsing JPEG data. >>> >>> But in JDK-8160943 >>> we have gap >>> between APP0 marker and DQT(FF DB) >>> marker which contains data "00 FF". >>> >>> >>> >>> APP0_End -> 00 FF -> FF DB(DQT) >>> >>> >>> >>> So after we skip APP0 marker we find two bytes of data which is >>> "FF FF". In the present code we consider this as >>> invalid marker. >>> >>> >>> See https://www.w3.org/Graphics/JPEG/itu-t81.pdf >>> >>> B.1.1.2 Markers >>> Markers serve to identify the various structural parts of the >>> compressed data formats. >>> Most markers start marker segments containing a related group of >>> parameters; some markers stand alone. All markers are assigned >>> two-byte codes: an X'FF' byte followed by a byte which is not equal >>> to 0 or X'FF' (see Table B.1). >>> Any marker may optionally be preceded by any number of fill bytes, >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> which are bytes assigned code X'FF >>> ^^^^^^^^^^^^^^^^^^^^^^ >>> >>> -phil. >>> >>> >>> Because of this JDK-8160943 >>> is failing. >>> >>> >>> >>> Is the length of APP0 marker not valid in the image or we should >>> not consider "FF FF" as invalid maker? >>> >>> Please let me know your input. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> From Sergey.Bylokhov at oracle.com Thu Jul 21 21:55:31 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 Jul 2016 00:55:31 +0300 Subject: [OpenJDK 2D-Dev] RFR (urgent) 8162097: [PIT] A series of closed tests about SunFontManager throw NPE on Windows In-Reply-To: References: <5790FEF4.1010904@oracle.com> Message-ID: <534e34bc-0700-ac3d-7052-ded733862ded@oracle.com> +1 On 21.07.16 20:54, Brian Burkhalter wrote: > This looks fine as far as I can see. > > Brian > > On Jul 21, 2016, at 9:57 AM, Phil Race wrote: > >> http://cr.openjdk.java.net/~prr/8162097/ >> >> I have an urgent RFR which is blocking PIT. >> >> The fix : https://bugs.openjdk.java.net/browse/JDK-8152971 to eliminate some JNI warnings. >> >> is prematurely deleting a local ref which is used in a callback function. >> As as result we get many NPEs in Java code. >> The fix is to move the (normal case) delete to after we've done with the callback. >> >> The tests which failed before this fix now pass. >> Also the JNI check test is not seeing "new" issues .. there are already JNI warnings >> that it finds in other code. >> >> -phil. > -- Best regards, Sergey. From philip.race at oracle.com Thu Jul 21 22:53:11 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 21 Jul 2016 15:53:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: 7175487: Cannot customize font configuration on Linux Message-ID: <57915257.2090708@oracle.com> https://bugs.openjdk.java.net/browse/JDK-7175487 http://cr.openjdk.java.net/~prr/7175487/ As I note in the bug eval the probable issue here is that the file was found but rejected. I've made the code more forgiving by removing the test that the file have references to font files. The XLFD pattern for locating the files will work if they are missing (I did some manual testing). Also the reference to OpenSolaris here is obsolete. There's more clean up that could be done around that but for this fix I wanted to keep it about this Linux issue except for cleaning up the overall if (..) logic -phil. From alexey.ushakov at jetbrains.com Fri Jul 22 09:20:19 2016 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Fri, 22 Jul 2016 12:20:19 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8147542 Linux: ClassCastException when repainting after display resolution change In-Reply-To: <9208F9C7-4151-4C83-8BC1-4DE654ADD910@jetbrains.com> References: <1D7CBE9A-9FE3-4D4E-AA0B-F0303316976D@jetbrains.com> <9208F9C7-4151-4C83-8BC1-4DE654ADD910@jetbrains.com> Message-ID: <6F170584-87CA-4525-9954-77CC946E3F21@jetbrains.com> Friendly reminder :) Best Regards, Alexey > On 13 Jul 2016, at 12:33, Alexey Ushakov wrote: > > Hi, > > Is there any concerns about this fix? > > Best Regards, > Alexey > >> On 06 Jul 2016, at 15:22, Alexey Ushakov > wrote: >> >> Hello Phil and Sergey, >> >> There is one more slightly different issue causing CCE in blit code. It happens quite often in IDEA. After looking through JBS I?ve found that the problem is still relevant for all current releases. Here is the fix that I?ve marked with the most recent JBS issue that we have for some time in our custom OpenJDK based runtime. Please have a look. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147542 >> Webrev: http://cr.openjdk.java.net/~avu/JDK-8147542/webrev.00 >> >> Best Regards, >> Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 22 10:56:55 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 22 Jul 2016 16:26:55 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <578F9832.1080906@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> Message-ID: <5791FBF7.2050800@oracle.com> Hi Phil, I have modified the code to check if job-sheets is supported and then only proceed to print the banner page. Also, rectified the jobTitle and banner confusion by adding jobsheet check. Also added the same code in UnixPrintJob even though I found its printExecCmd() does not get executed in linux and solaris PSPrinterJob's printExecCmd() is executed instead. In mac, neither UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets executed. Tested on ubuntu and solaris 11 with the fix and banner page is printed with the fix. In mac, cover page gets printed without any change. http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ Regards Prasanta On 7/20/2016 8:56 PM, Philip Race wrote: > In my evaluation of that bug (which was 9 yrs ago so I do not have > any memory of it :-)), I note that we first need to check > that job-sheets is supported .. you are not doing that .. > what happens if we pass an unsupported option ? > "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. > > Also -J (job-title) is something you can see in the queue when > you do lpq. I don't know why it is tied to banner here but > removing it seems wrong. Perhaps this should be renamed from > "banner" and "BANNER" to jobTitle ?? Please examine this. > > In fact you seem to be conflicting with the -o nobanner. > > So in general we have some lack of clarity around job title and banner > page > (aka job sheet). > > Also we have PSPrinterJob and UnixPrinterJob with similar code. > Please examine it to make sure no similar case is going missed. > > -phil. > > On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that Banner page in >> linux does not get printed despite user selecting the Banner page >> checkbox in Printer dialog. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >> >> It seems if we pass "-J " option to lpr command, it has >> no effect. >> To print Banner page, we need to pass >> "-o job-sheets=> "standard", "topsecret", or "unclassified">" >> >> Since we support only standard banner or none via a checkbox, >> the proposed fix passes option "-o job-sheets=standard" to lpr >> command to print the banner page. >> >> Regards >> PRasanta From ajit.ghaisas at oracle.com Fri Jul 22 11:09:23 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 22 Jul 2016 04:09:23 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4882305: StreamPrintServ.getSupportedAttributeValues returns null for Orientation attr In-Reply-To: <578F9540.1090601@oracle.com> References: <578756D2.1010801@oracle.com> <578F9540.1090601@oracle.com> Message-ID: <257792cb-61b2-403b-997d-468e35dfda47@default> Hi Prasanta, ? 1.?????? The test contains commented code ? that needs to be removed 2.?????? The test only tests for image/jpeg docFlavor ? what about image/gif and image/png docflavors testing? 3.?????? The year in banner at the top of PSStreamPrintService.java can be updated ? Regards, Ajit ? From: Philip Race Sent: Wednesday, July 20, 2016 8:44 PM To: Prasanta Sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4882305: StreamPrintServ.getSupportedAttributeValues returns null for Orientation attr ? +1 -phil. On 7/14/16, 2:09 AM, Prasanta Sadhukhan wrote: Hi All, Please review a fix for an issue where it is seen that even though StreamPrintService returns OrientationRequested category as supported, when actually querying the supported attribute value with respect to the supported DocFlavors, null values are returned for the Orientation attributes when the DocFlavor is not either Pageable or Printable (SERVICE_FORMATTED) BUT we can print a jpeg iamge using StreamPrintService in LANDSCAPE mode and it worked fine so StreamPrintService should not return the supported values as null for supported DocFlavor. Bug: https://bugs.openjdk.java.net/browse/JDK-4882305 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/4882305/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/4882305/webrev.00/ Proposed fix is to add the image/jpeg, image/gif, image/png docflavor in addition to Pageable/Printable for Orientation attribute. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.walsh at oracle.com Fri Jul 22 13:54:01 2016 From: martin.walsh at oracle.com (Martin Walsh) Date: Fri, 22 Jul 2016 14:54:01 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160664 JVM crashed with font manager on Solaris 12 Message-ID: <57922579.5050709@oracle.com> Hi, Could I get a review for the simple fix for https://bugs.openjdk.java.net/browse/JDK-8160664 A webrev of the change is available here: http://cr.openjdk.java.net/~aivanov/martin.walsh/8160664/jdk9/webrev.00/ Thanks, Martin From philip.race at oracle.com Fri Jul 22 16:59:21 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 09:59:21 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160664 JVM crashed with font manager on Solaris 12 In-Reply-To: <57922579.5050709@oracle.com> References: <57922579.5050709@oracle.com> Message-ID: <579250E9.30505@oracle.com> Hi, That looks reasonable .. but before an OK I would like to see the results of running the test case in the bug report after that fix. Run the test case with -Dsun.java2d.debugfonts=true so we can see what the JDK is doing internally. You can add the log to the bug report. Basically fontconfig is also likely to be subsequently invoked to build the list of real fonts underlying the logical font names (eg JDK sansserif which is the equivalent of fontconfig's sans). I suspect they will all end up just falling back to the Lucida Sans Regular font shipped with JDK. But for OpenJDK that won't be there .. so you may also want to see what happens if you then delete (move elsewhere) that font from jdk/lib/fonts. Maybe not a VM crash but a Java NPE perhaps as no fonts at all is not a supportable configuration. So yes, that does mean I think that although avoiding a crash is good, running graphics tests on a system that has no font is an unsupported and unsupportable configuration. Put another way Java even as *headless* has a *hard* requirement on the fonts being installed and Solaris 12 not installing any by default means it does not satisfy the requirements of Java and that decision should be revisited .. else (and I really, really, mean this) we can't support Solaris 12. -phil. On 07/22/2016 06:54 AM, Martin Walsh wrote: > Hi, > > Could I get a review for the simple fix for > > https://bugs.openjdk.java.net/browse/JDK-8160664 > > A webrev of the change is available here: > > http://cr.openjdk.java.net/~aivanov/martin.walsh/8160664/jdk9/webrev.00/ > > > Thanks, > > Martin From philip.race at oracle.com Fri Jul 22 17:16:33 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 10:16:33 -0700 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8147542 Linux: ClassCastException when repainting after display resolution change In-Reply-To: <6F170584-87CA-4525-9954-77CC946E3F21@jetbrains.com> References: <1D7CBE9A-9FE3-4D4E-AA0B-F0303316976D@jetbrains.com> <9208F9C7-4151-4C83-8BC1-4DE654ADD910@jetbrains.com> <6F170584-87CA-4525-9954-77CC946E3F21@jetbrains.com> Message-ID: <579254F1.4050808@oracle.com> This is OK by me. -phil. On 07/22/2016 02:20 AM, Alexey Ushakov wrote: > Friendly reminder :) > > Best Regards, > Alexey > >> On 13 Jul 2016, at 12:33, Alexey Ushakov >> > >> wrote: >> >> Hi, >> >> Is there any concerns about this fix? >> >> Best Regards, >> Alexey >> >>> On 06 Jul 2016, at 15:22, Alexey Ushakov >>> > >>> wrote: >>> >>> Hello Phil and Sergey, >>> >>> There is one more slightly different issue causing CCE in blit code. >>> It happens quite often in IDEA. After looking through JBS I?ve found >>> that the problem is still relevant for all current releases. Here is >>> the fix that I?ve marked with the most recent JBS issue that we have >>> for some time in our custom OpenJDK based runtime. Please have a look. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147542 >>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8147542/webrev.00 >>> >>> >>> Best Regards, >>> Alexey >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jul 22 17:50:38 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Jul 2016 10:50:38 -0700 Subject: [OpenJDK 2D-Dev] RFR 8149016: Misleading IllegalArgumentException message when a type that is neither LONG nor IFD pointer is supplied to TIFFField constructor Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8149016 Patch: http://cr.openjdk.java.net/~bpb/8149016/webrev.00/ The problem is that the constructor TIFFField(TIFFTag tag, int type, long offset, TIFFDirectory dir) {} begins with an invocation of the constructor TIFFField(TIFFTag tag, int type, int count, Object data) {} which performs some checks not documented for the former constructor nor for that matter necessary. The fix is to change the former constructor to perform directly the actions for which it was previously relying on the latter constructor. As an aside, some " ? HTML entities were removed from ?{@code}? tags wherein they are not interpreted during javadoc generation. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 22 17:57:57 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 10:57:57 -0700 Subject: [OpenJDK 2D-Dev] RFR 8149016: Misleading IllegalArgumentException message when a type that is neither LONG nor IFD pointer is supplied to TIFFField constructor In-Reply-To: References: Message-ID: <57925EA5.9080306@oracle.com> two cases of missing spaces between if and ( .. else if(type < TIFFTag.MIN_DATATYPE || type > TIFFTag.MAX_DATATYPE) { 722 throw new IllegalArgumentException("Unknown data type "+type); 723 } else if(!tag.isDataTypeOK(type)) { Fix before pushing. Otherwise fine. -phil. On 07/22/2016 10:50 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8149016 > Patch:http://cr.openjdk.java.net/~bpb/8149016/webrev.00/ > > > The problem is that the constructor > > TIFFField(TIFFTag tag, int type, long offset, TIFFDirectory dir) {} > > begins with an invocation of the constructor > > TIFFField(TIFFTag tag, int type, int count, Object data) {} > > which performs some checks not documented for the former constructor > nor for that matter necessary. The fix is to change the former > constructor to perform directly the actions for which it was > previously relying on the latter constructor. > > As an aside, some " ? HTML entities were removed from ?{@code}? > tags wherein they are not interpreted during javadoc generation. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 22 19:04:44 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 12:04:44 -0700 Subject: [OpenJDK 2D-Dev] RFR 8140314: Verify IIOMetadataFormat class on loading Message-ID: <57926E4C.20906@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8140314 http://cr.openjdk.java.net/~prr/8140314.1/ This code was refactored a fair amount in preparation for jigsaw and was failing at one point when Class.forName(Module, String) did not work for the un-named module. Now the residual issue is that we should verify it is actually the right type before we return and get a CCE in the calling code. I ran all imageio regression and tests and there were no (new) failures. -phil. From jayathirth.d.v at oracle.com Fri Jul 22 19:11:51 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 22 Jul 2016 12:11:51 -0700 (PDT) Subject: [OpenJDK 2D-Dev] RFR 8161902: [PIT][TEST_BUG]sun/awt/image/OffScreenImageSource/ImageConsumerUnregisterTest.java compilation fails Message-ID: Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8161902 Webrev : http://cr.openjdk.java.net/~jdv/8161902/webrev.00/ Root cause : Invalid class name used while constructing the object. Solution : Use proper class-name for constructor(In this test case to create a component). Also updated test case to comply with 80 characters per line guideline. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 22 19:08:04 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 12:08:04 -0700 Subject: [OpenJDK 2D-Dev] RFR 8161902: [PIT][TEST_BUG]sun/awt/image/OffScreenImageSource/ImageConsumerUnregisterTest.java compilation fails In-Reply-To: References: Message-ID: <57926F14.3040402@oracle.com> +1 -phil. On 07/22/2016 12:11 PM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8161902 > > Webrev : http://cr.openjdk.java.net/~jdv/8161902/webrev.00/ > > > Root cause : Invalid class name used while constructing the object. > > Solution : Use proper class-name for constructor(In this test case to > create a component). Also updated test case to comply with 80 > characters per line guideline. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Jul 22 19:16:20 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Jul 2016 19:16:20 +0000 Subject: [OpenJDK 2D-Dev] RFR(S): 8161923: Fix two memory issues. In-Reply-To: <22bc792b-652e-88bd-0719-02d00a03fa48@oracle.com> References: <1b31ead91a874c02997770b88350ea57@DEWDFE13DE09.global.corp.sap> <5c34aec2-2f6e-817a-6128-8d37e0a54422@oracle.com> <578FADA3.9000904@oracle.com> <1c14e487b7c041f1a363b176574bb514@DEWDFE13DE09.global.corp.sap> <578FEAEF.5070301@oracle.com> <579145E4.4070300@oracle.com> <22bc792b-652e-88bd-0719-02d00a03fa48@oracle.com> Message-ID: <4cd5960851a04ce18d480573216ac0e6@DEWDFE13DE09.global.corp.sap> Hi, now we have a row of solutions ... I would like to finish this up, please. Could I just keep the version right now? Or which one? Also we lost the mailinglists for some reason. For the records: I had posted webrev02: http://cr.openjdk.java.net/~goetz/wr16/8161923-jdkMem/webrev.02/ Best regards, Goetz. > -----Original Message----- > From: Vadim Pakhnushev [mailto:vadim.pakhnushev at oracle.com] > Sent: Friday, July 22, 2016 9:09 AM > To: Phil Race ; Lindenmaier, Goetz > > Subject: Re: [OpenJDK 2D-Dev] RFR(S): 8161923: Fix two memory > issues. > > I'd do similar to what is already in the file: > > if (++m >= nComponents) { > m = 0; > } > componentStack[m] = currGlyph; > > So in this case: > > if (++mm == nComponents) { > LE_DEBUG_BAD_FONT("exceeded nComponents"); > mm--; // don't overrun the stack. > // or mm = nComponents-1; > } > stack[mm] = componentGlyph; > > Vadim > > On 22.07.2016 1:00, Phil Race wrote: > > On 07/21/2016 02:40 AM, Lindenmaier, Goetz wrote: > >> Hi Phil, > >> > >> actually I must say that I (and a colleague of mine) had to look at what > >> you propose quite a while to see it's correct. > > > > Hmm .. surprising. Vadim, which do you think is clearer ? > > > > -phil. > > > > > >> Not so with the mm++ > >> before the check. The extra increment/decrement should be optimized > >> by the C++ compiler I guess. > >> But both require a comment that says that the last stack element > >> is overvritten in case of overflow, I think. > >> > >> Yes, these fixes originally stem from a Coverity run. > >> But that was a run on jdk8 when we released that. Currently, another > >> colleague of mine is moving our fixes from jdk8 to jdk9. There > >> he spotted these two issues, and we thought they would be useful > >> for the open community. > >> > >> Best regards, > >> Goetz. > >> > >> > >>> -----Original Message----- > >>> From: Phil Race [mailto:philip.race at oracle.com] > >>> Sent: Mittwoch, 20. Juli 2016 23:20 > >>> To: Lindenmaier, Goetz > >>> Cc: 'Vadim Pakhnushev' > >>> Subject: Re: [OpenJDK 2D-Dev] RFR(S): 8161923: Fix two > memory > >>> issues. > >>> > >>> If we are going to refactor this why not make it more > >>> straightforward :- > >>> > >>> > >>> if (m+1 >= nComponents) { > >>> LE_DEBUG_BAD_FONT("exceeded nComponents"); > >>> } else { > >>> m++; > >>> } > >>> stack[mm] = componentGlyph; > >>> > >>> > >>> > >>> Out of curiousity ... I was aware of the other file too .. and was > >>> surprised a bit > >>> that there > >>> was an update to one file and not the other since I supposed this was > >>> discovered > >>> by a tool which would catch the pattern in both cases. > >>> > >>> But only catching one seems like "by eye" .. except that seems hard to > >>> believe. > >>> > >>> So I am concluding it was a tool that found this as an actual > >>> runtime overflow > >>> and only the one code path was executed .. which is not that > >>> surprising since > >>> only the "2" path is taken by all modern fonts. But only Apple make > >>> such > >>> fonts > >>> which suggest you were running on OS X > >>> > >>> So how and where was it found ? > >>> > >>> > >>> The windows one is interesting .. I am a bit surprised that hasn't > >>> caused a > >>> crash and > >>> I suppose windows is smart enough to know its wrong and ignore it. > >>> > >>> > >>> -phil. > >>> > >>> > >>> > >>> On 07/20/2016 01:45 PM, Lindenmaier, Goetz wrote: > >>> > >>> > >>> Hi Vadim and Phil, > >>> > >>> > >>> > >>> thanks for looking at this. > >>> > >>> > >>> > >>> Yes Vadim, what you say is how I uunderstand it. > >>> > >>> > >>> > >>> Basically the code is like this, let's assume mm==nComponents > >>> > >>> if (mm==nComponents) { // true > >>> > >>> LE_DEBUG_BAD_FONT("exceeded nComponents"); > >>> > >>> mm--; // don't overrun the stack. // mm = > >>> (nComponents-1) > >>> > >>> } > >>> > >>> ++mm; // mm = > >>> (nComponents-1)+1 = > >>> nComponents > >>> > >>> stack[mm] = componentGlyph; // stack[nComponents] > >>> > >>> > >>> > >>> Changing the if as you propose, Vadim, should work. But actually, I > >>> would > >>> > >>> move the ++mm into a line of it's own, obviously it's hard to > >>> understand > >>> > >>> if it's in the condition. > >>> > >>> > >>> > >>> New webrev, also fixing the other file: > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/8161923- > >>> jdkMem/webrev.02/ > >>> jdkMem/webrev.02/> > >>> > >>> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> > >>> > >>> > >>> From: Vadim Pakhnushev [mailto:vadim.pakhnushev at oracle.com] > >>> Sent: Wednesday, July 20, 2016 7:14 PM > >>> To: Philip Race > >>> ; Lindenmaier, Goetz > >>> > >>> Subject: Re: [OpenJDK 2D-Dev] RFR(S): 8161923: Fix two > >>> memory issues. > >>> > >>> > >>> > >>> Phil, > >>> > >>> I was wondering the same, but after looking more closely I realized > >>> that if mm equals nComponents it would be decremented and then > >>> preincremented and the stack would be written at index nComponents. > >>> > >>> My suggestion is to move increment here: > >>> if(++mm==nComponents) { > >>> ... > >>> stack[mm] = componentGlyph; > >>> > >>> Thanks, > >>> Vadim > >>> > >>> On 20.07.2016 19:58, Philip Race wrote: > >>> > >>> Goetz, > >>> > >>> Can you illustrate exactly how this overwrite can occur ? > >>> I see checks that ensure that if mm==nComponents it is reset > >>> .. > >>> > >>> -phil. > >>> > >>> On 7/20/16, 8:36 AM, Vadim Pakhnushev wrote: > >>> > >>> Hi Goetz, > >>> > >>> Maybe instead of increasing the stack size we could > >>> move the increment from the assignment to the previous if statement > >>> where we check for the overwrite possibility? > >>> There are similar code patterns in this file. > >>> Also there is almost identical file > >>> LigatureSubstProc.cpp which also contains similar code. > >>> > >>> Thanks, > >>> Vadim > >>> > >>> On 20.07.2016 16:13, Lindenmaier, Goetz wrote: > >>> > >>> Hi > >>> > >>> > >>> > >>> This changes fixes two memory issues. > >>> > >>> > >>> > >>> In awt_PrintControl.cpp, a wrong pointer is > >>> freed. > >>> > >>> In LigatureSubstProc2.cpp, line 157: > >>> > >>> stack[++mm] = componentGlyph; > >>> > >>> can overwrite the stack by one element. It will > >>> write > >>> > >>> stack[nComponents], because ++mm > >>> increments before > >>> > >>> accessing the array. > >>> > >>> > >>> > >>> Fix: increase the size of the array by one. > >>> > >>> > >>> > >>> Please review this change: > >>> > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/8161923- > >>> jdkMem/webrev.01/ > >>> jdkMem/webrev.01/> > >>> > >>> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> > >>> > >>> > >>> > >>> > > From brian.burkhalter at oracle.com Fri Jul 22 19:56:22 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Jul 2016 12:56:22 -0700 Subject: [OpenJDK 2D-Dev] RFR 8140314: Verify IIOMetadataFormat class on loading In-Reply-To: <57926E4C.20906@oracle.com> References: <57926E4C.20906@oracle.com> Message-ID: <738936CB-ED91-4ED4-81CA-166422CD759C@oracle.com> Looks reasonable to me. Brian On Jul 22, 2016, at 12:04 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8140314 > http://cr.openjdk.java.net/~prr/8140314.1/ > > This code was refactored a fair amount in preparation for jigsaw and was failing > at one point when Class.forName(Module, String) did not work for the un-named module. > > Now the residual issue is that we should verify it is actually the right type before > we return and get a CCE in the calling code. > > I ran all imageio regression and tests and there were no (new) failures. > > -phil. From philip.race at oracle.com Fri Jul 22 20:02:57 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 13:02:57 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162429: Clean up obsolete font preferences for JDS. Message-ID: <57927BF1.5080003@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8162429 http://cr.openjdk.java.net/~prr/8162429/ Clean up some now obsolete font code. -phil. From james.graham at oracle.com Fri Jul 22 20:20:47 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 22 Jul 2016 13:20:47 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java In-Reply-To: <63fe6280-4b04-4d0d-9a38-0ff9b667e131@default> References: <305512b1-3eb4-42e3-8e78-337f0ee12438@default> <578674F8.1050905@oracle.com> <5b1abcf8-d755-4d4c-b3a8-d8cc9a89c424@default> <7e16e9c9-2ddd-0f9f-ab1d-d77f830cc08c@oracle.com> <63fe6280-4b04-4d0d-9a38-0ff9b667e131@default> Message-ID: I found it. The bug is still there. ImageIO has been writing out bad length fields for APP0/JFXX thumbnails for years now. When we write a JFXX APP0 marker in JFIFMarkerSegment.java, we write out the length as: LENGTH_SIZE + DATA_SIZE + thumb.getLength() LENGTH_SIZE is 2 which accounts for the APP0 size field so we are good there. DATA_SIZE is 6 which accounts for the "JFXX\0" and the 0x13 marker that defines this as an RGB thumbnail (both of which are written out by the code that computed the size above). thumb.getLength() is (w * h * 3) which accounts for the pixels in the thumbnail. But, nobody accounts for the 2 bytes for the w,h of the thumbnail, so the length field is written out 2 bytes short of the correct total. The "thumb" object is responsible for writing out that w,h so it should probably include them in its return value for its length I imagin, but the length only accounts for the RGB triples in the actual pixels. There are other Thumbnail classes which I believe also omit the 2 bytes for the w,h from their getLength() field (the w,h are written by super.write() in all cases so they are computing the bytes that they themselves write and ignoring what their superclass writes). There is also some JFIF thumbnail writing code in the same file which I think does its math correctly, but we should write a test and see... ...jim On 07/21/2016 02:46 PM, Jayathirth D V wrote: > Hi Jim, > > I just ran the test case attached in https://bugs.openjdk.java.net/browse/JDK-4958271 . > It is actually generating an image and using it to do reader.readAll(). > > Thanks, > Jay > -----Original Message----- > From: Jim Graham > Sent: Thursday, July 21, 2016 2:22 PM > To: Jayathirth D V; Philip Race > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java > > Hi Jay, > > How did you generate that image with thumbnail? With ImageIO? > > ...jim > > On 07/19/2016 12:18 PM, Jayathirth D V wrote: >> Hi Phil, >> >> I generated Jpeg image with thumbnail as given in test case attached for https://bugs.openjdk.java.net/browse/JDK-4958271 with JDK 9. >> The image has only two APP0 markers and after the second marker it has "00 FF" which we can consider as "X FF" as per https://www.w3.org/Graphics/JPEG/itu-t81.pdf. But it is just continuation of pattern "00 00 FF" which we see around the end of second APP0 marker. >> >> For this new image I don't see whether we are writing improperly in JDK9(If we consider "X FF" bits between markers). >> So we can just apply http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ and open up the test case(after verifying whether it is the only test case which uses this particular image) with new image that I have created. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Philip Race >> Sent: Wednesday, July 13, 2016 10:06 AM >> To: Jim Graham >> Cc: Jayathirth D V; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8160943 : [PIT] >> new failure of closed/javax/imageio/ReadAllThumbnailsTest.java >> >> Whilst looking at the reason this test was originally created >> https://bugs.openjdk.java.net/browse/JDK-4958271 >> it started to look likely that the image was (as I sort of suspected) was generated by IIO itself. >> >> I think there a couple of things we can do here >> 1) Open up the test (and image - although if moving it make sure no other tests in that location need the image). >> 2) Investigate to see if the bug such that the "bad padding" is written out is still reproducible with current IIO ... or if it was fixed sometime between when that image was created and now. >> >> -phil. >> >> On 7/12/16, 7:48 PM, Jim Graham wrote: >>> I think this is fine, but I noticed that some of the recently added >>> comments have some grammar issues. It might be nice to change the >>> following: >>> >>> 565 // markers which do not contain length data >>> (doesn't => do not) >>> >>> 576 // markers which contain length data >>> (contains => contain) >>> >>> I don't need to review those changes... >>> >>> ...jim >>> >>> On 7/12/16 9:15 AM, Jayathirth D V wrote: >>>> Hi, >>>> >>>> >>>> >>>> Thanks for your input Phil. >>>> >>>> I have made changes just to parse "FF FF"(Like "FF 00" or any marker >>>> without length)and not consider it as an invalid marker in >>>> skipImage() of JPEGImageReader.java. >>>> >>>> Also I have removed closed/javax/imageio/ReadAllThumbnailsTest.java >>>> from ProblemList.txt as part of fix. >>>> >>>> >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 >>>> >>>> >>>> >>>> Please find webrev for review for JDK9: >>>> >>>> http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> >>>> >>>> *From:*Phil Race >>>> *Sent:* Saturday, July 09, 2016 12:37 AM >>>> *To:* Jayathirth D V >>>> *Cc:* Jim Graham; 2d-dev >>>> *Subject:* Re: REG : JDK-8160943 : [PIT] new failure of >>>> closed/javax/imageio/ReadAllThumbnailsTest.java >>>> >>>> >>>> >>>> On 07/08/2016 04:08 AM, Jayathirth D V wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> In JDK-8152672 >>>> >>>> we modified skipImage() in JpegImageReader.java >>>> and added tighter checks for parsing Jpeg data. >>>> >>>> >>>> >>>> We have to find any marker,0 or EOF after we find "FF" while >>>> parsing JPEG data. >>>> >>>> But in JDK-8160943 >>>> we have gap >>>> between APP0 marker and DQT(FF DB) >>>> marker which contains data "00 FF". >>>> >>>> >>>> >>>> APP0_End -> 00 FF -> FF DB(DQT) >>>> >>>> >>>> >>>> So after we skip APP0 marker we find two bytes of data which is >>>> "FF FF". In the present code we consider this as >>>> invalid marker. >>>> >>>> >>>> See https://www.w3.org/Graphics/JPEG/itu-t81.pdf >>>> >>>> B.1.1.2 Markers >>>> Markers serve to identify the various structural parts of the >>>> compressed data formats. >>>> Most markers start marker segments containing a related group of >>>> parameters; some markers stand alone. All markers are assigned >>>> two-byte codes: an X'FF' byte followed by a byte which is not equal >>>> to 0 or X'FF' (see Table B.1). >>>> Any marker may optionally be preceded by any number of fill bytes, >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> which are bytes assigned code X'FF >>>> ^^^^^^^^^^^^^^^^^^^^^^ >>>> >>>> -phil. >>>> >>>> >>>> Because of this JDK-8160943 >>>> is failing. >>>> >>>> >>>> >>>> Is the length of APP0 marker not valid in the image or we should >>>> not consider "FF FF" as invalid maker? >>>> >>>> Please let me know your input. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> >>>> From james.graham at oracle.com Fri Jul 22 20:22:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 22 Jul 2016 13:22:26 -0700 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8147542 Linux: ClassCastException when repainting after display resolution change In-Reply-To: <579254F1.4050808@oracle.com> References: <1D7CBE9A-9FE3-4D4E-AA0B-F0303316976D@jetbrains.com> <9208F9C7-4151-4C83-8BC1-4DE654ADD910@jetbrains.com> <6F170584-87CA-4525-9954-77CC946E3F21@jetbrains.com> <579254F1.4050808@oracle.com> Message-ID: <704e871c-c7e3-4a40-cfbd-a2677d8581ff@oracle.com> +1 from me too... ...jim On 07/22/2016 10:16 AM, Phil Race wrote: > This is OK by me. > > -phil. > > On 07/22/2016 02:20 AM, Alexey Ushakov wrote: >> Friendly reminder :) >> >> Best Regards, >> Alexey >> >>> On 13 Jul 2016, at 12:33, Alexey Ushakov >>> > >>> wrote: >>> >>> Hi, >>> >>> Is there any concerns about this fix? >>> >>> Best Regards, >>> Alexey >>> >>>> On 06 Jul 2016, at 15:22, Alexey Ushakov >>>> > >>>> wrote: >>>> >>>> Hello Phil and Sergey, >>>> >>>> There is one more slightly different issue causing CCE in blit code. >>>> It happens quite often in IDEA. After looking through JBS I?ve found >>>> that the problem is still relevant for all current releases. Here is >>>> the fix that I?ve marked with the most recent JBS issue that we have >>>> for some time in our custom OpenJDK based runtime. Please have a look. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147542 >>>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8147542/webrev.00 >>>> >>>> >>>> Best Regards, >>>> Alexey >>> >> > From brian.burkhalter at oracle.com Fri Jul 22 20:57:41 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Jul 2016 13:57:41 -0700 Subject: [OpenJDK 2D-Dev] RFR 8148454: [PIT] Failure of ReplaceMetadataTest on TIFF with IllegalStateException Message-ID: <0B1982BE-6A39-46C3-83F0-8F263DB869C7@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8148454 Patch: http://cr.openjdk.java.net/~bpb/8148454/webrev.00/ Problem was that the superclass ?output? variable was being incorrectly reset to null. The TIFF writer mostly uses its internal ?stream? variable for the ImageOutputStream but the test exposed a case which referred to the superclass ?output? variable. The @ignore tag has been removed from the mentioned test. Thanks, Brian From brian.burkhalter at oracle.com Fri Jul 22 20:59:09 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Jul 2016 13:59:09 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162429: Clean up obsolete font preferences for JDS. In-Reply-To: <57927BF1.5080003@oracle.com> References: <57927BF1.5080003@oracle.com> Message-ID: +1 Brian On Jul 22, 2016, at 1:02 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8162429 > http://cr.openjdk.java.net/~prr/8162429/ > > Clean up some now obsolete font code. > > -phil. From philip.race at oracle.com Fri Jul 22 21:22:53 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 14:22:53 -0700 Subject: [OpenJDK 2D-Dev] RFR 8148454: [PIT] Failure of ReplaceMetadataTest on TIFF with IllegalStateException In-Reply-To: <0B1982BE-6A39-46C3-83F0-8F263DB869C7@oracle.com> References: <0B1982BE-6A39-46C3-83F0-8F263DB869C7@oracle.com> Message-ID: <57928EAD.8080509@oracle.com> Brian, I verified that the failing tests now pass. You also need to update the ProblemList. -phil. On 07/22/2016 01:57 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8148454 > Patch: http://cr.openjdk.java.net/~bpb/8148454/webrev.00/ > > Problem was that the superclass ?output? variable was being incorrectly reset to null. The TIFF writer mostly uses its internal ?stream? variable for the ImageOutputStream but the test exposed a case which referred to the superclass ?output? variable. The @ignore tag has been removed from the mentioned test. > > Thanks, > > Brian From philip.race at oracle.com Fri Jul 22 22:19:59 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Jul 2016 15:19:59 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162432: Clean up references in font code to old Solaris releases. Message-ID: <57929C0F.20908@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8162432 http://cr.openjdk.java.net/~prr/8162432/ There's no need for the isSolaris8/9 or isOpenSolaris variables any more. -phil. From brian.burkhalter at oracle.com Fri Jul 22 22:50:34 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Jul 2016 15:50:34 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162432: Clean up references in font code to old Solaris releases. In-Reply-To: <57929C0F.20908@oracle.com> References: <57929C0F.20908@oracle.com> Message-ID: <8F7733FB-5555-4CC7-A10F-A4CB61F86093@oracle.com> +1 Brian On Jul 22, 2016, at 3:19 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8162432 > http://cr.openjdk.java.net/~prr/8162432/ > > There's no need for the isSolaris8/9 or isOpenSolaris variables any more. > > -phil. From alexey.ushakov at jetbrains.com Sat Jul 23 03:26:15 2016 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Sat, 23 Jul 2016 06:26:15 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8147542 Linux: ClassCastException when repainting after display resolution change In-Reply-To: <704e871c-c7e3-4a40-cfbd-a2677d8581ff@oracle.com> References: <1D7CBE9A-9FE3-4D4E-AA0B-F0303316976D@jetbrains.com> <9208F9C7-4151-4C83-8BC1-4DE654ADD910@jetbrains.com> <6F170584-87CA-4525-9954-77CC946E3F21@jetbrains.com> <579254F1.4050808@oracle.com> <704e871c-c7e3-4a40-cfbd-a2677d8581ff@oracle.com> Message-ID: <992A94DF-696C-4174-9A63-C95F1940EA1C@jetbrains.com> Thank you very much! Could you please help me with integrating the fix into 8u and 9? I don?t have push permissions for the latest releases of JDK. Best Regards, Alexey > On 22 Jul 2016, at 23:22, Jim Graham wrote: > > +1 from me too... > > ...jim > > On 07/22/2016 10:16 AM, Phil Race wrote: >> This is OK by me. >> >> -phil. >> >> On 07/22/2016 02:20 AM, Alexey Ushakov wrote: >>> Friendly reminder :) >>> >>> Best Regards, >>> Alexey >>> >>>> On 13 Jul 2016, at 12:33, Alexey Ushakov >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> Is there any concerns about this fix? >>>> >>>> Best Regards, >>>> Alexey >>>> >>>>> On 06 Jul 2016, at 15:22, Alexey Ushakov >>>>> > >>>>> wrote: >>>>> >>>>> Hello Phil and Sergey, >>>>> >>>>> There is one more slightly different issue causing CCE in blit code. >>>>> It happens quite often in IDEA. After looking through JBS I?ve found >>>>> that the problem is still relevant for all current releases. Here is >>>>> the fix that I?ve marked with the most recent JBS issue that we have >>>>> for some time in our custom OpenJDK based runtime. Please have a look. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147542 >>>>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8147542/webrev.00 >>>>> >>>>> >>>>> Best Regards, >>>>> Alexey >>>> >>> >> From prasanta.sadhukhan at oracle.com Mon Jul 25 09:57:44 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 25 Jul 2016 15:27:44 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6591280: getting IPP connection causes disabling jar caches Message-ID: <5795E298.8040306@oracle.com> Hi All, Please review a fix for jdk9 where it is seen that we are unnecessarily disabling jar caching for entire JVM execution when a IPPConnection is established, which is wrong. Bug: https://bugs.openjdk.java.net/browse/JDK-6591280 webrev: http://cr.openjdk.java.net/~psadhukhan/6591280/webrev.00/ When IPPService.getIPPConnection(URL url) is called, we call connection.setDefaultUsesCaches(false) [in addition to connection.setUseCaches(false);] where "connection" is instance of HttpUrlConnection. Calling this setDefaultUsesCaches(false) will result in disabling |URLConnection|'s |useCaches| flag and as spec states "This flag applies to the next, and all following URLConnections that are created" so jar caching will be disabled for subsequent URLConnections too. Proposed fix is to remove this setting of disabling jvm-wide jar caching. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.walsh at oracle.com Mon Jul 25 14:14:35 2016 From: martin.walsh at oracle.com (Martin Walsh) Date: Mon, 25 Jul 2016 15:14:35 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160664 JVM crashed with font manager on Solaris 12 In-Reply-To: <579250E9.30505@oracle.com> References: <57922579.5050709@oracle.com> <579250E9.30505@oracle.com> Message-ID: <57961ECB.50607@oracle.com> On 07/22/16 05:59 PM, Phil Race wrote: > Hi, > > That looks reasonable .. but before an OK I would like to see the > results of running the test case in > the bug report after that fix. Run the test case with > -Dsun.java2d.debugfonts=true so we can see > what the JDK is doing internally. You can add the log to the bug report. Thanks, I have attached the output of this to the bug. > > Basically fontconfig is also likely to be subsequently invoked to build > the list of real fonts underlying > the logical font names (eg JDK sansserif which is the equivalent of > fontconfig's sans). > I suspect they will all end up just falling back to the Lucida Sans > Regular font shipped with JDK. > > But for OpenJDK that won't be there .. so you may also want to see what > happens if you > then delete (move elsewhere) that font from jdk/lib/fonts. Maybe not a > VM crash but a Java NPE perhaps > as no fonts at all is not a supportable configuration. Yes, you get a NPE. # java Family Exception in thread "main" java.lang.NullPointerException at sun.awt.FcFontManager.getDefaultPlatformFont(java.desktop at 9-internal/FcFontManager.java:76) at sun.font.SunFontManager$2.run(java.desktop at 9-internal/SunFontManager.java:434) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at sun.font.SunFontManager.(java.desktop at 9-internal/SunFontManager.java:377) at sun.awt.FcFontManager.(java.desktop at 9-internal/FcFontManager.java:35) at sun.awt.X11FontManager.(java.desktop at 9-internal/X11FontManager.java:56) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-internal/Native Method) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-internal/NativeConstructorAccessorImpl.java:62) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-internal/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-internal/Constructor.java:453) at java.lang.Class.newInstance(java.base at 9-internal/Class.java:569) at sun.font.FontManagerFactory$1.run(java.desktop at 9-internal/FontManagerFactory.java:83) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at sun.font.FontManagerFactory.getInstance(java.desktop at 9-internal/FontManagerFactory.java:74) at sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(java.desktop at 9-internal/SunGraphicsEnvironment.java:203) at sun.java2d.SunGraphicsEnvironment.getAllFonts(java.desktop at 9-internal/SunGraphicsEnvironment.java:222) at sun.java2d.HeadlessGraphicsEnvironment.getAllFonts(java.desktop at 9-internal/HeadlessGraphicsEnvironment.java:72) at Family.main(Family.java:7) > > So yes, that does mean I think that although avoiding a crash is good, > running graphics tests on > a system that has no font is an unsupported and unsupportable > configuration. > Put another way Java even as *headless* has a *hard* requirement on the > fonts being installed > and Solaris 12 not installing any by default means it does not satisfy > the requirements of Java > and that decision should be revisited .. else (and I really, really, > mean this) we can't support Solaris 12. Well with a minimal install, Java is not installed either. As far as I can tell, the Java package manifest delivered to Solaris does not depend on the font files. I just "pkg install jdk-8" and no font files came with it. So perhaps the Java pkg manifests needs to depend on the relevant font package so that fonts will be installed when Java is installed. However this does not support the scenario where a JDK tar file is dropped onto the machine. I am not sure whether we want to support this scenario, we can take this off list for further discussion. Thanks, Martin > > -phil. > > On 07/22/2016 06:54 AM, Martin Walsh wrote: >> Hi, >> >> Could I get a review for the simple fix for >> >> https://bugs.openjdk.java.net/browse/JDK-8160664 >> >> A webrev of the change is available here: >> >> http://cr.openjdk.java.net/~aivanov/martin.walsh/8160664/jdk9/webrev.00/ >> >> >> Thanks, >> >> Martin > From jayathirth.d.v at oracle.com Mon Jul 25 15:48:30 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 25 Jul 2016 08:48:30 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6591280: getting IPP connection causes disabling jar caches In-Reply-To: <5795E298.8040306@oracle.com> References: <5795E298.8040306@oracle.com> Message-ID: Hi Prasanta, ? Changes are looking fine. ? Thanks, Jay ? From: Prasanta Sadhukhan Sent: Monday, July 25, 2016 3:28 PM To: Philip Race; 2d-dev Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6591280: getting IPP connection causes disabling jar caches ? Hi All, Please review a fix for jdk9 where it is seen that we are unnecessarily disabling jar caching for entire JVM execution when a IPPConnection is established, which is wrong. Bug: https://bugs.openjdk.java.net/browse/JDK-6591280 webrev: http://cr.openjdk.java.net/~psadhukhan/6591280/webrev.00/ When IPPService.getIPPConnection(URL url) is called, we call connection.setDefaultUsesCaches(false) [in addition to connection.setUseCaches(false);] where "connection" is instance of HttpUrlConnection. Calling this setDefaultUsesCaches(false) will result in disabling URLConnection's useCaches flag and as spec states "This flag applies to the next, and all following URLConnections that are created" so jar caching will be disabled for subsequent URLConnections too. Proposed fix is to remove this setting of disabling jvm-wide jar caching. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jul 25 17:22:41 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Jul 2016 10:22:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 7175487: Cannot customize font configuration on Linux In-Reply-To: <57915257.2090708@oracle.com> References: <57915257.2090708@oracle.com> Message-ID: <57964AE1.8030809@oracle.com> Hi, Anyone able to approve this ? I already pushed a subsequent fix that unfortunately *depends* on this fix. So I need to get this one in ASAP -phil. On 07/21/2016 03:53 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-7175487 > http://cr.openjdk.java.net/~prr/7175487/ > > As I note in the bug eval the probable issue here is that the file was > found but rejected. > I've made the code more forgiving by removing the test that the file > have references to font files. > The XLFD pattern for locating the files will work if they are missing > (I did some manual testing). > > Also the reference to OpenSolaris here is obsolete. There's more clean > up that could be done > around that but for this fix I wanted to keep it about this Linux > issue except for cleaning up > the overall if (..) logic > > -phil. From philip.race at oracle.com Mon Jul 25 17:30:11 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Jul 2016 10:30:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160664 JVM crashed with font manager on Solaris 12 In-Reply-To: <57961ECB.50607@oracle.com> References: <57922579.5050709@oracle.com> <579250E9.30505@oracle.com> <57961ECB.50607@oracle.com> Message-ID: <57964CA3.40408@oracle.com> On 07/25/2016 07:14 AM, Martin Walsh wrote: > On 07/22/16 05:59 PM, Phil Race wrote: >> Hi, >> >> That looks reasonable .. but before an OK I would like to see the >> results of running the test case in >> the bug report after that fix. Run the test case with >> -Dsun.java2d.debugfonts=true so we can see >> what the JDK is doing internally. You can add the log to the bug report. > > Thanks, I have attached the output of this to the bug. I took a look through these and "no surprises", so the fix seems fine (approved). Do you need me to push this for you ? > >> >> Basically fontconfig is also likely to be subsequently invoked to build >> the list of real fonts underlying >> the logical font names (eg JDK sansserif which is the equivalent of >> fontconfig's sans). >> I suspect they will all end up just falling back to the Lucida Sans >> Regular font shipped with JDK. >> >> But for OpenJDK that won't be there .. so you may also want to see what >> happens if you >> then delete (move elsewhere) that font from jdk/lib/fonts. Maybe not a >> VM crash but a Java NPE perhaps >> as no fonts at all is not a supportable configuration. > > Yes, you get a NPE. > > # java Family > Exception in thread "main" java.lang.NullPointerException ... Yes, this is what I expected there. Perhaps we should be throwing some other kind of exception here .. if there really are no fonts anywhere .. but that is beyond the immediate scope of this fix. -phil. From brian.burkhalter at oracle.com Mon Jul 25 17:49:09 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Jul 2016 10:49:09 -0700 Subject: [OpenJDK 2D-Dev] RFR: 7175487: Cannot customize font configuration on Linux In-Reply-To: <57964AE1.8030809@oracle.com> References: <57915257.2090708@oracle.com> <57964AE1.8030809@oracle.com> Message-ID: <7DF798D5-D854-48CB-A2D6-A9FD661D5A9E@oracle.com> Looks fine: approved. Brian On Jul 25, 2016, at 10:22 AM, Phil Race wrote: > Hi, > > Anyone able to approve this ? > I already pushed a subsequent fix that unfortunately *depends* on this fix. > So I need to get this one in ASAP > > -phil. > > On 07/21/2016 03:53 PM, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-7175487 >> http://cr.openjdk.java.net/~prr/7175487/ >> >> As I note in the bug eval the probable issue here is that the file was found but rejected. >> I've made the code more forgiving by removing the test that the file have references to font files. >> The XLFD pattern for locating the files will work if they are missing (I did some manual testing). >> >> Also the reference to OpenSolaris here is obsolete. There's more clean up that could be done >> around that but for this fix I wanted to keep it about this Linux issue except for cleaning up >> the overall if (..) logic >> >> -phil. > From philip.race at oracle.com Mon Jul 25 19:41:05 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Jul 2016 12:41:05 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162488: JDK should be updated to use LittleCMS 2.8 Message-ID: <57966B51.5000507@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8162488 Webrev : http://cr.openjdk.java.net/~prr/8162488 LCMS 2.8 has been released. JDK should keep up to date. I have verified via JPRT that the updated version builds cleanly on all platforms. Also ran Java2Demo and graphics/imaging/color regression tests to verify no new problems there. This should be backported to JDK 8u once it has been integrated to 9. The update itself is not large - relative to the library - and you can read what the author says here :- https://sourceforge.net/p/lcms/mailman/message/35239394/ A good number of the changes are just fixing typos in comments and updating copyright years and some additional checking/verification. The alpha support is the main new feature. -phil From philip.race at oracle.com Mon Jul 25 20:24:06 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Jul 2016 13:24:06 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6278300: sun.print.Win32MediaSize deserialization error In-Reply-To: <5788AEB1.9010709@oracle.com> References: <5788AEB1.9010709@oracle.com> Message-ID: <57967566.2060604@oracle.com> The fix seems wrong to me .. and the problem is not easy. Windows defines standard paper sizes and we recognise those and will always serialise the "Media" as one of the built-in java pre-defined Media. But windows printer drivers very typically define additional driver-specific papers, so at runtime JDK dynamically creates new instances as these are discovered. They will be instances of Win32MediaSize and their IDs (enum int values) will be entirely dependent on the order they "happened" to be added to the list. When you serialise this out, all you serialise is (a) the type (Win32MediaSize) and (b) the int value (see the serialized form docs for EnumSyntax). When you come to *deserialize* then what happens depends on whether the code that adds those to the list has been run (or not). If it has, you may well be lucky and get the right intended paper. If it has not - which is inevitable if you load the preferences in main(..) before any printing code has run - then the code that initialises the table has not been run and the int value is meaningless. Pointing it to the ID in the super-class is wrong. Also you have not run the Win32MediaSize constructor ! So you will have deserialized a garbage instance .. it will have an ID that does not correspond to the table, and was meant to ID some standard paper size. So the fix is probably worse than the bug. It seems like there should be a readResolve() for Win32MediaSize that first initialises the table. And it is only *this simple* (yes, I mean that) because you only have one printer involved. Get 4 printers with custom IDs and you don't even know in which order these printers had their IDs initialised. The documented serialised form leaves you with essentially insufficient information. It seems like Win32MediaSize needs a serialised form that includes the extra info. But if you "delete" the printer and run the app you now have useless serialised data and need to esstablish a policy around that. Also it seems likely we have the same issue in the CUPS code .. This is a non-trivial bug and will likely take a lot of careful work to figure out all the spec/compat/behavioural issues. -phil. On 07/15/2016 02:36 AM, Prasanta Sadhukhan wrote: > Hi All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-6278300 > > Please review a fix for an issue where it is seen that > Deserialization of a javax.print.attribute.standard.MediaPrintableArea > printer attribute fails when the serialization happened in a prior > invocation of the program > only for a *non-standard* page size say 4"x6" > > It is because EnumSyntax.readResolve() tries to get the EnumSyntax[] > table from Win32MediaSize when the objects are read > and if the EnumSyntax table is not initialized or 0 in length, then > readResolve() will find the object value being read is not in the > EnumSyntax table and will throw this InvalidObjectException > > java.io.InvalidObjectException: Integer value = 9 not in valid range > 0..-1for class class sun.print.Win32MediaSize > at > javax.print.attribute.EnumSyntax.readResolve(java.desktop at 9-internal/EnumSyntax.java:204) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-internal/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-internal/NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-internal/DelegatingMethodAccessorImpl.java:43) > at > java.lang.reflect.Method.invoke(java.base at 9-internal/Method.java:533) > at > java.io.ObjectStreamClass.invokeReadResolve(java.base at 9-internal/ObjectStreamClass.java:1150) > at > java.io.ObjectInputStream.readOrdinaryObject(java.base at 9-internal/ObjectInputStream.java:1835) > at > java.io.ObjectInputStream.readObject0(java.base at 9-internal/ObjectInputStream.java:1371) > at > java.io.ObjectInputStream.readObject(java.base at 9-internal/ObjectInputStream.java:371) > > When the printDialog() is invoked, then EnumSyntax table will be > initialised to the current paper ids. But, if printDIalog() is invoked > AFTER objects are deserialised, we run into this problem of enumTable > being 0 in length. > > Proposed fix is, to check if the enumtable is not initialised, then > fallback to the supported media size enum table. > > webrev: http://cr.openjdk.java.net/~psadhukhan/6278300/webrev.00/ > > I made it noreg-hard as it needs a custom paper size to be added to > printer media list before invoking the serialization testcase present > in JBS bug entry. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Jul 25 20:42:48 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jul 2016 23:42:48 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8162488: JDK should be updated to use LittleCMS 2.8 In-Reply-To: <57966B51.5000507@oracle.com> References: <57966B51.5000507@oracle.com> Message-ID: <620a78a3-3d80-bb1a-435c-f668552d4a15@oracle.com> On 25.07.16 22:41, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8162488 > Webrev : http://cr.openjdk.java.net/~prr/8162488 > > LCMS 2.8 has been released. JDK should keep up to date. > I have verified via JPRT that the updated version builds cleanly on all > platforms. > Also ran Java2Demo and graphics/imaging/color regression tests to verify > no new problems there. > This should be backported to JDK 8u once it has been integrated to 9. Looks fine. > The alpha support is the main new feature. Is it affects the jdk functionality? If yes then should we provide some test to check, if not then should we use this feature somehow? -- Best regards, Sergey. From philip.race at oracle.com Mon Jul 25 20:44:57 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Jul 2016 13:44:57 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162488: JDK should be updated to use LittleCMS 2.8 In-Reply-To: <620a78a3-3d80-bb1a-435c-f668552d4a15@oracle.com> References: <57966B51.5000507@oracle.com> <620a78a3-3d80-bb1a-435c-f668552d4a15@oracle.com> Message-ID: <57967A49.5010709@oracle.com> The alpha support does not affect JDK .. you need to set a flag to enable it - else the new code just returns - and we do not set this (new) flag. Something to investigate maybe, but no immediate or necessary impact that I see. -phil. On 07/25/2016 01:42 PM, Sergey Bylokhov wrote: > On 25.07.16 22:41, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8162488 >> Webrev : http://cr.openjdk.java.net/~prr/8162488 >> >> LCMS 2.8 has been released. JDK should keep up to date. >> I have verified via JPRT that the updated version builds cleanly on all >> platforms. >> Also ran Java2Demo and graphics/imaging/color regression tests to verify >> no new problems there. >> This should be backported to JDK 8u once it has been integrated to 9. > > Looks fine. > >> The alpha support is the main new feature. > > Is it affects the jdk functionality? If yes then should we provide > some test to check, if not then should we use this feature somehow? > From philip.race at oracle.com Mon Jul 25 20:59:23 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Jul 2016 13:59:23 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6591280: getting IPP connection causes disabling jar caches In-Reply-To: <5795E298.8040306@oracle.com> References: <5795E298.8040306@oracle.com> Message-ID: <57967DAB.9010700@oracle.com> +1 FWIW this being an instance method hides what it does. It seems like it should have been static but as discussed here it is too late for that :- https://bugs.openjdk.java.net/browse/JDK-4851466 -phil. On 07/25/2016 02:57 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for jdk9 where it is seen that we are > unnecessarily disabling jar caching for entire JVM execution > when a IPPConnection is established, which is wrong. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6591280 > webrev: http://cr.openjdk.java.net/~psadhukhan/6591280/webrev.00/ > > When IPPService.getIPPConnection(URL url) is called, we call > connection.setDefaultUsesCaches(false) [in addition to > connection.setUseCaches(false);] > where "connection" is instance of HttpUrlConnection. > Calling this setDefaultUsesCaches(false) will result in disabling > |URLConnection|'s |useCaches| flag and as spec states "This flag > applies to the next, and all following URLConnections that are created" > so jar caching will be disabled for subsequent URLConnections too. > > Proposed fix is to remove this setting of disabling jvm-wide jar caching. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Tue Jul 26 05:35:54 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 26 Jul 2016 08:35:54 +0300 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160664 JVM crashed with font manager on Solaris 12 In-Reply-To: <57964CA3.40408@oracle.com> References: <57922579.5050709@oracle.com> <579250E9.30505@oracle.com> <57961ECB.50607@oracle.com> <57964CA3.40408@oracle.com> Message-ID: <6c1e6b0e-12ea-fdd0-15d4-b39ff02e0c62@oracle.com> Hi Martin, The fix looks fine. On 25.07.2016 20:30, Phil Race wrote: > On 07/25/2016 07:14 AM, Martin Walsh wrote: >> On 07/22/16 05:59 PM, Phil Race wrote: >>> Hi, >>> >>> That looks reasonable .. but before an OK I would like to see the >>> results of running the test case in >>> the bug report after that fix. Run the test case with >>> -Dsun.java2d.debugfonts=true so we can see >>> what the JDK is doing internally. You can add the log to the bug >>> report. >> >> Thanks, I have attached the output of this to the bug. > > I took a look through these and "no surprises", so the fix seems fine > (approved). > Do you need me to push this for you ? Thank you Phil! I will push it for Martin. Regards, Alexey > > >> >>> >>> Basically fontconfig is also likely to be subsequently invoked to build >>> the list of real fonts underlying >>> the logical font names (eg JDK sansserif which is the equivalent of >>> fontconfig's sans). >>> I suspect they will all end up just falling back to the Lucida Sans >>> Regular font shipped with JDK. >>> >>> But for OpenJDK that won't be there .. so you may also want to see what >>> happens if you >>> then delete (move elsewhere) that font from jdk/lib/fonts. Maybe not a >>> VM crash but a Java NPE perhaps >>> as no fonts at all is not a supportable configuration. >> >> Yes, you get a NPE. >> >> # java Family >> Exception in thread "main" java.lang.NullPointerException > > ... > Yes, this is what I expected there. Perhaps we should be throwing some > other kind > of exception here .. if there really are no fonts anywhere .. but > that is beyond the > immediate scope of this fix. > > -phil. From philip.race at oracle.com Tue Jul 26 05:40:59 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 25 Jul 2016 22:40:59 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074827: Resolve disabled warnings for libjavajpeg In-Reply-To: <57969C0D.6040603@oracle.com> References: <57969C0D.6040603@oracle.com> Message-ID: <5796F7EB.2090107@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8074827 http://cr.openjdk.java.net/~prr/8074827/ Passes JPRT. gcc clobbered is left since that seems to be a gcc bug fixed in a later gcc -phil. From prasanta.sadhukhan at oracle.com Tue Jul 26 05:51:12 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 26 Jul 2016 11:21:12 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8162488: JDK should be updated to use LittleCMS 2.8 In-Reply-To: <57967A49.5010709@oracle.com> References: <57966B51.5000507@oracle.com> <620a78a3-3d80-bb1a-435c-f668552d4a15@oracle.com> <57967A49.5010709@oracle.com> Message-ID: <5796FA50.20207@oracle.com> Just curious, cmscgats.c#why snprintf(Buffer, 1023,...) is used for a buffer of 1024 bytes. snprintf says, The generated string has a length of at most n-1, leaving space for the additional terminating null character so if we specify 1023, then 1022 bytes will be copied and 1023th byte will be terminating null character. cmsgamma.c copyright year is not modified. cmslut.c., cmsmtrx.c, has 2 extra lines at the end but I understand we take this lib as it is from open source so probably ok and if that is the case, +1 fro me. Regards Prasanta On 7/26/2016 2:14 AM, Phil Race wrote: > The alpha support does not affect JDK .. you need to set a flag to > enable it - else the new > code just returns - and we do not set this (new) flag. > Something to investigate maybe, but no immediate or necessary impact > that I see. > > -phil. > > On 07/25/2016 01:42 PM, Sergey Bylokhov wrote: >> On 25.07.16 22:41, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162488 >>> Webrev : http://cr.openjdk.java.net/~prr/8162488 >>> >>> LCMS 2.8 has been released. JDK should keep up to date. >>> I have verified via JPRT that the updated version builds cleanly on all >>> platforms. >>> Also ran Java2Demo and graphics/imaging/color regression tests to >>> verify >>> no new problems there. >>> This should be backported to JDK 8u once it has been integrated to 9. >> >> Looks fine. >> >>> The alpha support is the main new feature. >> >> Is it affects the jdk functionality? If yes then should we provide >> some test to check, if not then should we use this feature somehow? >> > From prasanta.sadhukhan at oracle.com Tue Jul 26 06:03:52 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 26 Jul 2016 11:33:52 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8074827: Resolve disabled warnings for libjavajpeg In-Reply-To: <5796F7EB.2090107@oracle.com> References: <57969C0D.6040603@oracle.com> <5796F7EB.2090107@oracle.com> Message-ID: <5796FD48.3000306@oracle.com> Looks good. Regards Prasanta On 7/26/2016 11:10 AM, Philip Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8074827 > http://cr.openjdk.java.net/~prr/8074827/ > > Passes JPRT. > gcc clobbered is left since that seems to be a gcc bug fixed in a > later gcc > > -phil. From philip.race at oracle.com Tue Jul 26 06:16:08 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 25 Jul 2016 23:16:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162488: JDK should be updated to use LittleCMS 2.8 In-Reply-To: <5796FA50.20207@oracle.com> References: <57966B51.5000507@oracle.com> <620a78a3-3d80-bb1a-435c-f668552d4a15@oracle.com> <57967A49.5010709@oracle.com> <5796FA50.20207@oracle.com> Message-ID: <57970028.2040503@oracle.com> On 7/25/16, 10:51 PM, Prasanta Sadhukhan wrote: > Just curious, > cmscgats.c#why snprintf(Buffer, 1023,...) is used for a buffer of 1024 > bytes. > > snprintf says, The generated string has a length of at most n-1, > leaving space for the additional terminating null character so if we > specify 1023, then 1022 bytes will be copied and 1023th byte will be > terminating null character. Not sure. A harmless abundance of caution ? .. > > cmsgamma.c copyright year is not modified. SEP. > cmslut.c., cmsmtrx.c, has 2 extra lines at the end I noticed a few. I intend to leave them unless jcheck objects. Minimum differences from upstream .. -phil. > > but I understand we take this lib as it is from open source so > probably ok and if that is the case, +1 fro me. > > Regards > Prasanta > On 7/26/2016 2:14 AM, Phil Race wrote: >> The alpha support does not affect JDK .. you need to set a flag to >> enable it - else the new >> code just returns - and we do not set this (new) flag. >> Something to investigate maybe, but no immediate or necessary impact >> that I see. >> >> -phil. >> >> On 07/25/2016 01:42 PM, Sergey Bylokhov wrote: >>> On 25.07.16 22:41, Phil Race wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162488 >>>> Webrev : http://cr.openjdk.java.net/~prr/8162488 >>>> >>>> LCMS 2.8 has been released. JDK should keep up to date. >>>> I have verified via JPRT that the updated version builds cleanly on >>>> all >>>> platforms. >>>> Also ran Java2Demo and graphics/imaging/color regression tests to >>>> verify >>>> no new problems there. >>>> This should be backported to JDK 8u once it has been integrated to 9. >>> >>> Looks fine. >>> >>>> The alpha support is the main new feature. >>> >>> Is it affects the jdk functionality? If yes then should we provide >>> some test to check, if not then should we use this feature somehow? >>> >> > From Sergey.Bylokhov at oracle.com Tue Jul 26 10:01:52 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Jul 2016 13:01:52 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8074827: Resolve disabled warnings for libjavajpeg In-Reply-To: <5796FD48.3000306@oracle.com> References: <57969C0D.6040603@oracle.com> <5796F7EB.2090107@oracle.com> <5796FD48.3000306@oracle.com> Message-ID: <9cca9774-4e06-089d-0549-62a2d367f0dc@oracle.com> +1 On 26.07.16 9:03, Prasanta Sadhukhan wrote: > Looks good. > > Regards > Prasanta > On 7/26/2016 11:10 AM, Philip Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8074827 >> http://cr.openjdk.java.net/~prr/8074827/ >> >> Passes JPRT. >> gcc clobbered is left since that seems to be a gcc bug fixed in a >> later gcc >> >> -phil. > -- Best regards, Sergey. From vadim.pakhnushev at oracle.com Tue Jul 26 14:50:26 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 26 Jul 2016 17:50:26 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure Message-ID: <485e5dad-562e-764b-ff02-85557804e1a9@oracle.com> Hi all, Please review the build failure fix for: https://bugs.openjdk.java.net/browse/JDK-8162545 diff -r c0cf6ec85273 src/java.desktop/share/native/libjavajpeg/imageioJPEG.c --- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul 26 15:55:22 2016 +0300 +++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul 26 17:49:12 2016 +0300 @@ -2634,7 +2634,7 @@ RELEASE_ARRAYS(env, data, NULL); } -static void freeArray(void** arr, jint size) { +static void freeArray(UINT8** arr, jint size) { int i; if (arr != NULL) { for (i = 0; i < size; i++) { Thanks, Vadim From prasanta.sadhukhan at oracle.com Tue Jul 26 15:10:28 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 26 Jul 2016 20:40:28 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure In-Reply-To: <485e5dad-562e-764b-ff02-85557804e1a9@oracle.com> References: <485e5dad-562e-764b-ff02-85557804e1a9@oracle.com> Message-ID: <57977D64.60100@oracle.com> Looks good. But strangely, I do not see this function in this file when Phil sent for review for his disable warning fix ;-) Regards Prasanta On 7/26/2016 8:20 PM, Vadim Pakhnushev wrote: > Hi all, > > Please review the build failure fix for: > https://bugs.openjdk.java.net/browse/JDK-8162545 > > diff -r c0cf6ec85273 > src/java.desktop/share/native/libjavajpeg/imageioJPEG.c > --- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul > 26 15:55:22 2016 +0300 > +++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul > 26 17:49:12 2016 +0300 > @@ -2634,7 +2634,7 @@ > RELEASE_ARRAYS(env, data, NULL); > } > > -static void freeArray(void** arr, jint size) { > +static void freeArray(UINT8** arr, jint size) { > int i; > if (arr != NULL) { > for (i = 0; i < size; i++) { > > > Thanks, > Vadim From philip.race at oracle.com Tue Jul 26 15:40:54 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Jul 2016 08:40:54 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure In-Reply-To: <485e5dad-562e-764b-ff02-85557804e1a9@oracle.com> References: <485e5dad-562e-764b-ff02-85557804e1a9@oracle.com> Message-ID: <57978486.5000606@oracle.com> +1 -phil. On 07/26/2016 07:50 AM, Vadim Pakhnushev wrote: > Hi all, > > Please review the build failure fix for: > https://bugs.openjdk.java.net/browse/JDK-8162545 > > diff -r c0cf6ec85273 > src/java.desktop/share/native/libjavajpeg/imageioJPEG.c > --- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul > 26 15:55:22 2016 +0300 > +++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul > 26 17:49:12 2016 +0300 > @@ -2634,7 +2634,7 @@ > RELEASE_ARRAYS(env, data, NULL); > } > > -static void freeArray(void** arr, jint size) { > +static void freeArray(UINT8** arr, jint size) { > int i; > if (arr != NULL) { > for (i = 0; i < size; i++) { > > > Thanks, > Vadim From vadim.pakhnushev at oracle.com Tue Jul 26 15:43:51 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 26 Jul 2016 18:43:51 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure In-Reply-To: <57977D64.60100@oracle.com> References: <485e5dad-562e-764b-ff02-85557804e1a9@oracle.com> <57977D64.60100@oracle.com> Message-ID: I checked that this fix passes JPRT with Phil's fix as well. Vadim On 26.07.2016 18:10, Prasanta Sadhukhan wrote: > Looks good. > But strangely, I do not see this function in this file when Phil sent > for review for his disable warning fix ;-) > > Regards > Prasanta > On 7/26/2016 8:20 PM, Vadim Pakhnushev wrote: >> Hi all, >> >> Please review the build failure fix for: >> https://bugs.openjdk.java.net/browse/JDK-8162545 >> >> diff -r c0cf6ec85273 >> src/java.desktop/share/native/libjavajpeg/imageioJPEG.c >> --- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul >> 26 15:55:22 2016 +0300 >> +++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul >> 26 17:49:12 2016 +0300 >> @@ -2634,7 +2634,7 @@ >> RELEASE_ARRAYS(env, data, NULL); >> } >> >> -static void freeArray(void** arr, jint size) { >> +static void freeArray(UINT8** arr, jint size) { >> int i; >> if (arr != NULL) { >> for (i = 0; i < size; i++) { >> >> >> Thanks, >> Vadim > From philip.race at oracle.com Tue Jul 26 15:47:34 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Jul 2016 08:47:34 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure In-Reply-To: <57977D64.60100@oracle.com> References: <485e5dad-562e-764b-ff02-85557804e1a9@oracle.com> <57977D64.60100@oracle.com> Message-ID: <57978616.6090507@oracle.com> Not that strange considering it was just pushed a few hours ago. I'll have to merge these before pushing my fix .. -phil. On 07/26/2016 08:10 AM, Prasanta Sadhukhan wrote: > Looks good. > But strangely, I do not see this function in this file when Phil sent > for review for his disable warning fix ;-) > > Regards > Prasanta > On 7/26/2016 8:20 PM, Vadim Pakhnushev wrote: >> Hi all, >> >> Please review the build failure fix for: >> https://bugs.openjdk.java.net/browse/JDK-8162545 >> >> diff -r c0cf6ec85273 >> src/java.desktop/share/native/libjavajpeg/imageioJPEG.c >> --- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul >> 26 15:55:22 2016 +0300 >> +++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul >> 26 17:49:12 2016 +0300 >> @@ -2634,7 +2634,7 @@ >> RELEASE_ARRAYS(env, data, NULL); >> } >> >> -static void freeArray(void** arr, jint size) { >> +static void freeArray(UINT8** arr, jint size) { >> int i; >> if (arr != NULL) { >> for (i = 0; i < size; i++) { >> >> >> Thanks, >> Vadim > From jennifer.godinez at oracle.com Tue Jul 26 21:28:10 2016 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Tue, 26 Jul 2016 14:28:10 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8162429: Clean up obsolete font preferences for JDS. In-Reply-To: <57927BF1.5080003@oracle.com> References: <57927BF1.5080003@oracle.com> Message-ID: Looks good. Jennifer On 7/22/2016 1:02 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8162429 > http://cr.openjdk.java.net/~prr/8162429/ > > Clean up some now obsolete font code. > > -phil. From Sergey.Bylokhov at oracle.com Tue Jul 26 21:50:24 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Jul 2016 00:50:24 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <54e2524f-2c0e-03f6-610d-ef55c27102b5@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> <5775AFF8.5060006@oracle.com> <54e2524f-2c0e-03f6-610d-ef55c27102b5@oracle.com> Message-ID: <9199112a-838d-377e-a86a-ce31b1a64aef@oracle.com> On 13.07.16 5:42, Jim Graham wrote: > What does the compClip end up being in that case? BufferedImage bi = new BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); SunGraphics2D graphics = (SunGraphics2D) bi.createGraphics(); graphics.scale(1.5, 1.5); graphics.setClip(1, 1, 0, 0); System.out.println("clip = " + graphics.getClip().getBounds2D()); System.out.println("clip.isEmpty = " + graphics.getClip().getBounds2D().isEmpty()); boolean hit = graphics.hitClip(1, 1, 1, 1); System.out.println("hit = " + hit); System.out.println("compClip = " + graphics.getCompClip()); System.out.println("compClip.isEmpty = " + graphics.getCompClip().isEmpty()); The output: clip = java.awt.geom.Rectangle2D$Double[x=1.0,y=1.0,w=0.0,h=0.0] clip.isEmpty = true hit = true compClip = Region[[1, 1 => 2, 2]] compClip.isEmpty = false So the graphics.getClip() returns empty clip, but compClip is not empty. It seems this occurs when we intersect usrClip =[x=1.5,y=1.5,w=0.0,h=0.0] and devClip=Region[[0, 0 => 10, 10]] because result is clipRegion=Region[[1, 1 => 2, 2]] The code in question is: protected void validateCompClip() { ..... clipRegion = devClip.getIntersection(usrClip.getBounds()); ..... } The usrClip.getBounds() method will change [x=1.5,y=1.5,w=0.0,h=0.0] to [x=1,y=1,w=1,h=1], so the empty Rectangle2D became non-empty. > > ...jim > > On 7/4/16 1:12 AM, Sergey Bylokhov wrote: >> On 01.07.16 2:49, Jim Graham wrote: >>> How is it returning true? If the clip really is empty, then >>> intersectsQuickCheck() should never return true. Or are you saying that >>> an empty clip shape produces a non-empty composite clip region? >> >> >> This code will test such situation: >> BufferedImage bi = new >> BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); >> Graphics2D graphics = bi.createGraphics(); >> graphics.scale(1.5, 1.5); >> graphics.setClip(1, 1, 0, 0); >> System.out.println("empty = " + >> graphics.getClip().getBounds2D().isEmpty()); >> boolean hit = graphics.hitClip(1, 1, 1, 1); >> System.out.println("hit = " + hit); >> >> if "graphics.scale(1.5, 1.5);" will be removed then correct false will >> be printed. In both cases the clip will be empty >> but hitCLip will return different result in case of scaled SG2D. >> >>> >>> ...jim >>> >>> On 06/30/2016 10:02 AM, Sergey Bylokhov wrote: >>>> It looks strange that the empty clip became "non-empty"(at least >>>> hitClip >>>> reports this) when we apply transform to it, no? I guess that at the >>>> beginning of hitClip() we should check that the clip.isEmpty(), and we >>>> should return "false" in this case(I think this is not strictly related >>>> to this bug)? >>>> >>>> On 24.06.16 1:14, Jim Graham wrote: >>>>> Think of this method as asking: >>>>> >>>>> I don't want you to waste a lot of time, but tell me if it is silly >>>>> for >>>>> me to even consider rendering something with these bounds. >>>>> >>>>> And the answer is either "Oh, yeah, it is inconceivable that those >>>>> bounds would be rendered", or "Not sure, maybe, just render it and >>>>> see". There may be some cases where it knows "I know for sure that >>>>> lots >>>>> of stuff will render through the clip", but that is not where the >>>>> divining line is here in terms of when the answer becomes true - it >>>>> becomes true when there is a chance that it might render something. >>>>> >>>>> Arguably, the user-space comparison against the user-space clip >>>>> that you >>>>> added here can never be accurate even if you allow for "false >>>>> positives". The clip is rasterized and whole pixels are chosen >>>>> based on >>>>> various criteria that affect clip rasterization. Thus, while the >>>>> theoretical clip is at N.5, our rasterization choice has us render >>>>> anything that hits pixel N, even if the contribution of the rendered >>>>> primitive is only for the first half of N. That pixel might be >>>>> rendered >>>>> if anything hits any part of it, depending on what rendering operation >>>>> is being done. >>>>> >>>>> So, your "fix" actually breaks the functionality because it is quite >>>>> possible that something with a bounding box that stops before N.5 >>>>> might >>>>> affect pixel N and cause it to be rendered even though your new answer >>>>> suggested that it wouldn't happen. Your code might actually cause a >>>>> bug, not fix one. >>>>> >>>>> (There are also some potential theoretical failures related to how AA >>>>> and STROKE_CONTROL might perturb our rendering, effects which are >>>>> ignore >>>>> by the current implementation of hitClip(), however I believe that all >>>>> of those effects fit within the current implementation - it's just >>>>> that >>>>> I don't think anyone has ever proven this, or written an exhaustive >>>>> test >>>>> suite to verify that none of our rendering hints can perturb rendering >>>>> by enough to create some surprises here...) >>>>> >>>>> ...jim >>>>> >>>>> On 6/23/16 3:00 PM, Jim Graham wrote: >>>>>> Since "return true" would be a compliant implementation of >>>>>> Graphics.hitClip(), this is not a bug... >>>>>> >>>>>> Read the documentation, it is allowed to use fast math that can >>>>>> return >>>>>> true when technically the answer is false... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>>>>>> >>>>>>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and >>>>>>> call the hitClip() with the passed rectangle [x=0, >>>>>>> y=0, width=5, height=5]. >>>>>>> >>>>>>> The result is false for the graphics with scale 1 and true if the >>>>>>> scale is floating point 1.5. >>>>>>> >>>>>>> This is because the transformed clip which has floating point >>>>>>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>>>>>> with rounded down upper-left and rounded up lower-right corners [7, >>>>>>> 7, 8, 8] which now intersects with the transformed >>>>>>> rectangle [0, 0, 7.5, 7.5]. >>>>>>> >>>>>>> The proposed fix adds additional check for the user clip and the >>>>>>> user rectangle intersection if the intersection with >>>>>>> the region clip passes. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>> >>>> >> >> -- Best regards, Sergey. From james.graham at oracle.com Tue Jul 26 22:56:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 26 Jul 2016 15:56:26 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <9199112a-838d-377e-a86a-ce31b1a64aef@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> <5775AFF8.5060006@oracle.com> <54e2524f-2c0e-03f6-610d-ef55c27102b5@oracle.com> <9199112a-838d-377e-a86a-ce31b1a64aef@oracle.com> Message-ID: <3dca1571-a32d-3d35-5b44-51a42f1c80b5@oracle.com> Ah, this is an issue of what an empty rectangle means. Filling 1.5,1.5,0,0 produces no output because it has no interior. But, stroking 1.5,1.5,0,0 can produce output because it is simply a rectangle that spins in place. As a result there are really 3 different containment properties for a rectangle - one that has area, one that has only location/no area, and one that has neither location nor area. This is discussed in the class comments for java.awt.Rectangle. isEmpty() indicates whether any area is covered, but the Rectangle may still accumulate into bounds calculations (via union operations) and other similar operations will treat its location as valid even if it encompasses no area. The issue is what should Rectangle2D.getBounds() return? We decided to do a min/max on the origin coordinate if the width/height are 0 because of this "it exists even if it covers no area" issue. But, clip areas are governed by what pixels would be filled, which is not reflected in the way that getBounds() works. What is going wrong in SG2D is that it is using Rectangle2D.getBounds() to compute the containment of the clip, but that does a min/max on the area rather than compute which pixels would be hit by a fill operation. We should replace that calculation with a more accurate computation on which centers of pixels are included in the Rectangle2D, something like: Rectangle2D rClip = (Rectangle2D) usrClip; int x0 = (int) Math.ceil(rClip.getMinX() - 0.5); int y0 = (int) Math.ceil(rClip.getMinY() - 0.5); int x1 = (int) Math.ceil(rClip.getMaxX() - 0.5); int x1 = (int) Math.ceil(rClip.getMaxY() - 0.5); clipRegion = devClip.getIntersectionXYXY(x0, y0, x1, y1); Some work and testing should be done to see what happens when any of the min/max/xy coordinates overflow an integer, but that would be the basic gist of what we should be doing in that case in validateCompClip()... ...jim On 07/26/2016 02:50 PM, Sergey Bylokhov wrote: > On 13.07.16 5:42, Jim Graham wrote: >> What does the compClip end up being in that case? > > BufferedImage bi = new > BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); > SunGraphics2D graphics = (SunGraphics2D) bi.createGraphics(); > graphics.scale(1.5, 1.5); > graphics.setClip(1, 1, 0, 0); > System.out.println("clip = " + graphics.getClip().getBounds2D()); > System.out.println("clip.isEmpty = " + > graphics.getClip().getBounds2D().isEmpty()); > boolean hit = graphics.hitClip(1, 1, 1, 1); > System.out.println("hit = " + hit); > System.out.println("compClip = " + graphics.getCompClip()); > System.out.println("compClip.isEmpty = " + > graphics.getCompClip().isEmpty()); > > The output: > clip = java.awt.geom.Rectangle2D$Double[x=1.0,y=1.0,w=0.0,h=0.0] > clip.isEmpty = true > hit = true > compClip = Region[[1, 1 => 2, 2]] > compClip.isEmpty = false > > So the graphics.getClip() returns empty clip, but compClip is not empty. > > It seems this occurs when we intersect usrClip > =[x=1.5,y=1.5,w=0.0,h=0.0] and devClip=Region[[0, 0 => 10, 10]] because > result is clipRegion=Region[[1, 1 => 2, 2]] > > The code in question is: > protected void validateCompClip() { > ..... > clipRegion = devClip.getIntersection(usrClip.getBounds()); > ..... > } > The usrClip.getBounds() method will change [x=1.5,y=1.5,w=0.0,h=0.0] to > [x=1,y=1,w=1,h=1], so the empty Rectangle2D became non-empty. > > >> >> ...jim >> >> On 7/4/16 1:12 AM, Sergey Bylokhov wrote: >>> On 01.07.16 2:49, Jim Graham wrote: >>>> How is it returning true? If the clip really is empty, then >>>> intersectsQuickCheck() should never return true. Or are you saying >>>> that >>>> an empty clip shape produces a non-empty composite clip region? >>> >>> >>> This code will test such situation: >>> BufferedImage bi = new >>> BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); >>> Graphics2D graphics = bi.createGraphics(); >>> graphics.scale(1.5, 1.5); >>> graphics.setClip(1, 1, 0, 0); >>> System.out.println("empty = " + >>> graphics.getClip().getBounds2D().isEmpty()); >>> boolean hit = graphics.hitClip(1, 1, 1, 1); >>> System.out.println("hit = " + hit); >>> >>> if "graphics.scale(1.5, 1.5);" will be removed then correct false will >>> be printed. In both cases the clip will be empty >>> but hitCLip will return different result in case of scaled SG2D. >>> >>>> >>>> ...jim >>>> >>>> On 06/30/2016 10:02 AM, Sergey Bylokhov wrote: >>>>> It looks strange that the empty clip became "non-empty"(at least >>>>> hitClip >>>>> reports this) when we apply transform to it, no? I guess that at the >>>>> beginning of hitClip() we should check that the clip.isEmpty(), and we >>>>> should return "false" in this case(I think this is not strictly >>>>> related >>>>> to this bug)? >>>>> >>>>> On 24.06.16 1:14, Jim Graham wrote: >>>>>> Think of this method as asking: >>>>>> >>>>>> I don't want you to waste a lot of time, but tell me if it is silly >>>>>> for >>>>>> me to even consider rendering something with these bounds. >>>>>> >>>>>> And the answer is either "Oh, yeah, it is inconceivable that those >>>>>> bounds would be rendered", or "Not sure, maybe, just render it and >>>>>> see". There may be some cases where it knows "I know for sure that >>>>>> lots >>>>>> of stuff will render through the clip", but that is not where the >>>>>> divining line is here in terms of when the answer becomes true - it >>>>>> becomes true when there is a chance that it might render something. >>>>>> >>>>>> Arguably, the user-space comparison against the user-space clip >>>>>> that you >>>>>> added here can never be accurate even if you allow for "false >>>>>> positives". The clip is rasterized and whole pixels are chosen >>>>>> based on >>>>>> various criteria that affect clip rasterization. Thus, while the >>>>>> theoretical clip is at N.5, our rasterization choice has us render >>>>>> anything that hits pixel N, even if the contribution of the rendered >>>>>> primitive is only for the first half of N. That pixel might be >>>>>> rendered >>>>>> if anything hits any part of it, depending on what rendering >>>>>> operation >>>>>> is being done. >>>>>> >>>>>> So, your "fix" actually breaks the functionality because it is quite >>>>>> possible that something with a bounding box that stops before N.5 >>>>>> might >>>>>> affect pixel N and cause it to be rendered even though your new >>>>>> answer >>>>>> suggested that it wouldn't happen. Your code might actually cause a >>>>>> bug, not fix one. >>>>>> >>>>>> (There are also some potential theoretical failures related to how AA >>>>>> and STROKE_CONTROL might perturb our rendering, effects which are >>>>>> ignore >>>>>> by the current implementation of hitClip(), however I believe that >>>>>> all >>>>>> of those effects fit within the current implementation - it's just >>>>>> that >>>>>> I don't think anyone has ever proven this, or written an exhaustive >>>>>> test >>>>>> suite to verify that none of our rendering hints can perturb >>>>>> rendering >>>>>> by enough to create some surprises here...) >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 6/23/16 3:00 PM, Jim Graham wrote: >>>>>>> Since "return true" would be a compliant implementation of >>>>>>> Graphics.hitClip(), this is not a bug... >>>>>>> >>>>>>> Read the documentation, it is allowed to use fast math that can >>>>>>> return >>>>>>> true when technically the answer is false... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>>>>>>> >>>>>>>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics >>>>>>>> and >>>>>>>> call the hitClip() with the passed rectangle [x=0, >>>>>>>> y=0, width=5, height=5]. >>>>>>>> >>>>>>>> The result is false for the graphics with scale 1 and true if the >>>>>>>> scale is floating point 1.5. >>>>>>>> >>>>>>>> This is because the transformed clip which has floating point >>>>>>>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>>>>>>> with rounded down upper-left and rounded up lower-right corners >>>>>>>> [7, >>>>>>>> 7, 8, 8] which now intersects with the transformed >>>>>>>> rectangle [0, 0, 7.5, 7.5]. >>>>>>>> >>>>>>>> The proposed fix adds additional check for the user clip and the >>>>>>>> user rectangle intersection if the intersection with >>>>>>>> the region clip passes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>> >>>>> >>> >>> > > From prasanta.sadhukhan at oracle.com Wed Jul 27 10:02:39 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 27 Jul 2016 15:32:39 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <5791FBF7.2050800@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> Message-ID: <579886BF.30600@oracle.com> Modified webrev to take care of a problem in webrev.01 whereby banner page was getting printed by default. Now, banner page will get printed only if the checkbox is checked in printer dialog. http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ Regards Prasanta On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: > Hi Phil, > > I have modified the code to check if job-sheets is supported and then > only proceed to print the banner page. > Also, rectified the jobTitle and banner confusion by adding jobsheet > check. > Also added the same code in UnixPrintJob even though I found its > printExecCmd() does not get executed in linux and solaris > PSPrinterJob's printExecCmd() is executed instead. In mac, neither > UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets > executed. > > Tested on ubuntu and solaris 11 with the fix and banner page is > printed with the fix. In mac, cover page gets printed without any change. > > http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ > > Regards > Prasanta > On 7/20/2016 8:56 PM, Philip Race wrote: >> In my evaluation of that bug (which was 9 yrs ago so I do not have >> any memory of it :-)), I note that we first need to check >> that job-sheets is supported .. you are not doing that .. >> what happens if we pass an unsupported option ? >> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >> >> Also -J (job-title) is something you can see in the queue when >> you do lpq. I don't know why it is tied to banner here but >> removing it seems wrong. Perhaps this should be renamed from >> "banner" and "BANNER" to jobTitle ?? Please examine this. >> >> In fact you seem to be conflicting with the -o nobanner. >> >> So in general we have some lack of clarity around job title and >> banner page >> (aka job sheet). >> >> Also we have PSPrinterJob and UnixPrinterJob with similar code. >> Please examine it to make sure no similar case is going missed. >> >> -phil. >> >> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that Banner page >>> in linux does not get printed despite user selecting the Banner page >>> checkbox in Printer dialog. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>> >>> It seems if we pass "-J " option to lpr command, it has >>> no effect. >>> To print Banner page, we need to pass >>> "-o job-sheets=>> "standard", "topsecret", or "unclassified">" >>> >>> Since we support only standard banner or none via a checkbox, >>> the proposed fix passes option "-o job-sheets=standard" to lpr >>> command to print the banner page. >>> >>> Regards >>> PRasanta > From philip.race at oracle.com Wed Jul 27 13:50:23 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 27 Jul 2016 06:50:23 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <579886BF.30600@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> <579886BF.30600@oracle.com> Message-ID: <5798BC1F.2010605@oracle.com> 883 } else { 884 Class[] supportedCats = getPrintService(). 885 getSupportedAttributeCategories(); 886 for (int i=0;i Modified webrev to take care of a problem in webrev.01 whereby banner > page was getting printed by default. > Now, banner page will get printed only if the checkbox is checked in > printer dialog. > > http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ > > Regards > Prasanta > On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: >> Hi Phil, >> >> I have modified the code to check if job-sheets is supported and then >> only proceed to print the banner page. >> Also, rectified the jobTitle and banner confusion by adding jobsheet >> check. >> Also added the same code in UnixPrintJob even though I found its >> printExecCmd() does not get executed in linux and solaris >> PSPrinterJob's printExecCmd() is executed instead. In mac, neither >> UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets >> executed. >> >> Tested on ubuntu and solaris 11 with the fix and banner page is >> printed with the fix. In mac, cover page gets printed without any >> change. >> >> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ >> >> Regards >> Prasanta >> On 7/20/2016 8:56 PM, Philip Race wrote: >>> In my evaluation of that bug (which was 9 yrs ago so I do not have >>> any memory of it :-)), I note that we first need to check >>> that job-sheets is supported .. you are not doing that .. >>> what happens if we pass an unsupported option ? >>> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >>> >>> Also -J (job-title) is something you can see in the queue when >>> you do lpq. I don't know why it is tied to banner here but >>> removing it seems wrong. Perhaps this should be renamed from >>> "banner" and "BANNER" to jobTitle ?? Please examine this. >>> >>> In fact you seem to be conflicting with the -o nobanner. >>> >>> So in general we have some lack of clarity around job title and >>> banner page >>> (aka job sheet). >>> >>> Also we have PSPrinterJob and UnixPrinterJob with similar code. >>> Please examine it to make sure no similar case is going missed. >>> >>> -phil. >>> >>> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that Banner page >>>> in linux does not get printed despite user selecting the Banner >>>> page checkbox in Printer dialog. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>>> >>>> It seems if we pass "-J " option to lpr command, it has >>>> no effect. >>>> To print Banner page, we need to pass >>>> "-o job-sheets=>>> "standard", "topsecret", or "unclassified">" >>>> >>>> Since we support only standard banner or none via a checkbox, >>>> the proposed fix passes option "-o job-sheets=standard" to lpr >>>> command to print the banner page. >>>> >>>> Regards >>>> PRasanta >> > From prasanta.sadhukhan at oracle.com Wed Jul 27 14:55:00 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 27 Jul 2016 20:25:00 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <5798BC1F.2010605@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> <579886BF.30600@oracle.com> <5798BC1F.2010605@oracle.com> Message-ID: <5798CB44.5080802@oracle.com> On 7/27/2016 7:20 PM, Philip Race wrote: > 883 } else { > 884 Class[] supportedCats = getPrintService(). > 885 getSupportedAttributeCategories(); > 886 for (int i=0;i 887 if (JobSheets.class == supportedCats[i]) { > 888 pFlags |= JOBSHEET; > 889 ncomps+=1; > 890 break; > 891 } > 892 } > > What is wrong with > > getPrintService().isAttributeCategorySupported(JobSheets.class) ? > > https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeCategorySupported-java.lang.Class- > > > I am also very confused about why you added JOBSHEET > which seems to duplicate the functionality of NOSHEET. > Do you want me to name it as "BANNER" instead of "JOBSHEET"? Since lpr command uses job-sheet=standard for banner so Iused that way. > Also it seems to me like it was intentional that the banner page be > printed by default .. which is why the variable was called > "*no*JobSheet .. > so as to over-ride that behaviour. > > It is kind of what you'd want if you walk over to the shared printer in > your office to have a banner page which declares it as yours ... > ok, would do the needful. I also thought so but then I thought that so far, banner page was not getting printed so it will be a behavioural change for the user so made "no banner page " by default. Regards Prasanta > So the checkbox should probably be enabled in that case. > > Also you should verify that we report the default value for JobSheets > as being STANDARD, not NONE. > > > -phil. > > On 7/27/16, 3:02 AM, Prasanta Sadhukhan wrote: >> Modified webrev to take care of a problem in webrev.01 whereby banner >> page was getting printed by default. >> Now, banner page will get printed only if the checkbox is checked in >> printer dialog. >> >> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ >> >> Regards >> Prasanta >> On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: >>> Hi Phil, >>> >>> I have modified the code to check if job-sheets is supported and >>> then only proceed to print the banner page. >>> Also, rectified the jobTitle and banner confusion by adding jobsheet >>> check. >>> Also added the same code in UnixPrintJob even though I found its >>> printExecCmd() does not get executed in linux and solaris >>> PSPrinterJob's printExecCmd() is executed instead. In mac, neither >>> UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets >>> executed. >>> >>> Tested on ubuntu and solaris 11 with the fix and banner page is >>> printed with the fix. In mac, cover page gets printed without any >>> change. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 7/20/2016 8:56 PM, Philip Race wrote: >>>> In my evaluation of that bug (which was 9 yrs ago so I do not have >>>> any memory of it :-)), I note that we first need to check >>>> that job-sheets is supported .. you are not doing that .. >>>> what happens if we pass an unsupported option ? >>>> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >>>> >>>> Also -J (job-title) is something you can see in the queue when >>>> you do lpq. I don't know why it is tied to banner here but >>>> removing it seems wrong. Perhaps this should be renamed from >>>> "banner" and "BANNER" to jobTitle ?? Please examine this. >>>> >>>> In fact you seem to be conflicting with the -o nobanner. >>>> >>>> So in general we have some lack of clarity around job title and >>>> banner page >>>> (aka job sheet). >>>> >>>> Also we have PSPrinterJob and UnixPrinterJob with similar code. >>>> Please examine it to make sure no similar case is going missed. >>>> >>>> -phil. >>>> >>>> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that Banner page >>>>> in linux does not get printed despite user selecting the Banner >>>>> page checkbox in Printer dialog. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>>>> >>>>> It seems if we pass "-J " option to lpr command, it >>>>> has no effect. >>>>> To print Banner page, we need to pass >>>>> "-o job-sheets=>>>> "standard", "topsecret", or "unclassified">" >>>>> >>>>> Since we support only standard banner or none via a checkbox, >>>>> the proposed fix passes option "-o job-sheets=standard" to lpr >>>>> command to print the banner page. >>>>> >>>>> Regards >>>>> PRasanta >>> >> From alexey.ivanov at oracle.com Wed Jul 27 15:58:50 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 27 Jul 2016 18:58:50 +0300 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160664 JVM crashed with font manager on Solaris 12 In-Reply-To: <6c1e6b0e-12ea-fdd0-15d4-b39ff02e0c62@oracle.com> References: <57922579.5050709@oracle.com> <579250E9.30505@oracle.com> <57961ECB.50607@oracle.com> <57964CA3.40408@oracle.com> <6c1e6b0e-12ea-fdd0-15d4-b39ff02e0c62@oracle.com> Message-ID: Hi Martin, Phil, I have pushed the fix. Changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/25e32d8c26c8 Regards, Alexey On 26.07.2016 8:35, Alexey Ivanov wrote: > Hi Martin, > > The fix looks fine. > > On 25.07.2016 20:30, Phil Race wrote: >> On 07/25/2016 07:14 AM, Martin Walsh wrote: >>> On 07/22/16 05:59 PM, Phil Race wrote: >>>> Hi, >>>> >>>> That looks reasonable .. but before an OK I would like to see the >>>> results of running the test case in >>>> the bug report after that fix. Run the test case with >>>> -Dsun.java2d.debugfonts=true so we can see >>>> what the JDK is doing internally. You can add the log to the bug >>>> report. >>> >>> Thanks, I have attached the output of this to the bug. >> >> I took a look through these and "no surprises", so the fix seems fine >> (approved). >> Do you need me to push this for you ? > > Thank you Phil! > > I will push it for Martin. > > Regards, > Alexey > >> >> >>> >>>> >>>> Basically fontconfig is also likely to be subsequently invoked to >>>> build >>>> the list of real fonts underlying >>>> the logical font names (eg JDK sansserif which is the equivalent of >>>> fontconfig's sans). >>>> I suspect they will all end up just falling back to the Lucida Sans >>>> Regular font shipped with JDK. >>>> >>>> But for OpenJDK that won't be there .. so you may also want to see >>>> what >>>> happens if you >>>> then delete (move elsewhere) that font from jdk/lib/fonts. Maybe not a >>>> VM crash but a Java NPE perhaps >>>> as no fonts at all is not a supportable configuration. >>> >>> Yes, you get a NPE. >>> >>> # java Family >>> Exception in thread "main" java.lang.NullPointerException >> >> ... >> Yes, this is what I expected there. Perhaps we should be throwing >> some other kind >> of exception here .. if there really are no fonts anywhere .. but >> that is beyond the >> immediate scope of this fix. >> >> -phil. > From philip.race at oracle.com Wed Jul 27 16:25:14 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Jul 2016 09:25:14 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs In-Reply-To: <577B791F.4020900@oracle.com> References: <577B791F.4020900@oracle.com> Message-ID: <5798E06A.5030909@oracle.com> prAll is final and initalised. So why are you testing !=null ? -phil. On 07/05/2016 02:08 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen "Page range > (From/To) " field is not disabled for flavors such as postscript, > image flavors. > PageRanges attribute is supported only for Service Formatted flavors > such as Pageable and Printable and so for > other flavors such as postscript, image flavors page ranges fields > must be disabled on the print dialog so as not to allow the user to > select the same > > Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 > webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ > > Proposed fix is to check for attribute against the specified doc flavor > and not against attribute category to decide whether to enable / > disable it. > > Regards > Prasanta From philip.race at oracle.com Wed Jul 27 21:12:17 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Jul 2016 14:12:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056210: Move libawt file to windows directory Message-ID: <579923B1.9070604@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8056210 http://cr.openjdk.java.net/~prr/8056210/ Simple clean-up of moving code used only on windows into a windows source directory JPRT is happy .. -phil. From philip.race at oracle.com Wed Jul 27 22:06:51 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Jul 2016 15:06:51 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8148477: Native memory leak in font layout subsystem Message-ID: <5799307B.6010402@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8158477 http://cr.openjdk.java.net/~prr/8158477/ Missing a call to ReleaseCharArrayElements() With this fix the test in the bug runs happily for many minutes without any increase at all in virtual memory. About 1.5 million invocations of the layout code so far. The JNI exception checking is just something I noticed was missing .. not relevant to the leak. No reg. test since it is not something you can test easily from jtreg .. -phil. From Sergey.Bylokhov at oracle.com Thu Jul 28 09:34:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Jul 2016 12:34:43 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8056210: Move libawt file to windows directory In-Reply-To: <579923B1.9070604@oracle.com> References: <579923B1.9070604@oracle.com> Message-ID: <6d307f80-6775-1e87-8213-41d51a056266@oracle.com> Looks fine. On 28.07.16 0:12, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8056210 > http://cr.openjdk.java.net/~prr/8056210/ > > Simple clean-up of moving code used only on windows into a windows > source directory > JPRT is happy .. > > -phil. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Jul 28 09:51:45 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 28 Jul 2016 15:21:45 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <5798BC1F.2010605@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> <579886BF.30600@oracle.com> <5798BC1F.2010605@oracle.com> Message-ID: <5799D5B1.4090808@oracle.com> The banner checkbox is not enabled initially as it calls getDefaultAttributeValue() and it seems printer is reporting the default job-sheet value as "none" so the below check is not satisfied. cbJobSheets.setSelected(js != JobSheets.NONE); When IPPPrintService#readIPPResponse() is called, it invokes /new AttributeClass(attribStr, valTagByte, outArray); /and stored the value corresponding to each attribute. I saw that IPP response has *job-sheets-default => job-sheets-default *and* **job-sheets-supported => job-sheets-supported* // When AttributeClass constructor is called with ("job-sheets-default", 66, value) the value is [ 0] = (byte) 4 [ 1] = (byte) 110 [ 2] = (byte) 111 [ 3] = (byte) 110 [ 4] = (byte) 101 [ 5] = (byte) 4 [ 6] = (byte) 110 [ 7] = (byte) 111 [ 8] = (byte) 110 [ 9] = (byte) 101 [10] = (byte) 2 which basically translates to '',n,o,n,e,'',n,o,n,e,'' so when ServiceDialog calls IPPPrintService#getDefaultAttributeValue(JobSheets) ---------------- if (attribClass != null && attribClass.getStringValue().equals("none")) { return JobSheets.NONE; } else { return JobSheets.STANDARD; } -------------- we have attribClass.getStringValue() as "none" so default job sheet value is coming out to be NONE. Since it is coming out from IPP response, I think we should not change default value of JobSheets to STANDARD. Do you think otherwise? In the modified webrev, I have made the jobsheet default value STANDARD, only when IPP does not report any default value. http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.03/ Tested in ubuntu & solaris11. Regards Prasanta On 7/27/2016 7:20 PM, Philip Race wrote: > 883 } else { > 884 Class[] supportedCats = getPrintService(). > 885 getSupportedAttributeCategories(); > 886 for (int i=0;i 887 if (JobSheets.class == supportedCats[i]) { > 888 pFlags |= JOBSHEET; > 889 ncomps+=1; > 890 break; > 891 } > 892 } > > What is wrong with > > getPrintService().isAttributeCategorySupported(JobSheets.class) ? > > https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeCategorySupported-java.lang.Class- > > > I am also very confused about why you added JOBSHEET > which seems to duplicate the functionality of NOSHEET. > > Also it seems to me like it was intentional that the banner page be > printed by default .. which is why the variable was called > "*no*JobSheet .. > so as to over-ride that behaviour. > > It is kind of what you'd want if you walk over to the shared printer in > your office to have a banner page which declares it as yours ... > > So the checkbox should probably be enabled in that case. > > Also you should verify that we report the default value for JobSheets > as being STANDARD, not NONE. > > > -phil. > > On 7/27/16, 3:02 AM, Prasanta Sadhukhan wrote: >> Modified webrev to take care of a problem in webrev.01 whereby banner >> page was getting printed by default. >> Now, banner page will get printed only if the checkbox is checked in >> printer dialog. >> >> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ >> >> Regards >> Prasanta >> On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: >>> Hi Phil, >>> >>> I have modified the code to check if job-sheets is supported and >>> then only proceed to print the banner page. >>> Also, rectified the jobTitle and banner confusion by adding jobsheet >>> check. >>> Also added the same code in UnixPrintJob even though I found its >>> printExecCmd() does not get executed in linux and solaris >>> PSPrinterJob's printExecCmd() is executed instead. In mac, neither >>> UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets >>> executed. >>> >>> Tested on ubuntu and solaris 11 with the fix and banner page is >>> printed with the fix. In mac, cover page gets printed without any >>> change. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 7/20/2016 8:56 PM, Philip Race wrote: >>>> In my evaluation of that bug (which was 9 yrs ago so I do not have >>>> any memory of it :-)), I note that we first need to check >>>> that job-sheets is supported .. you are not doing that .. >>>> what happens if we pass an unsupported option ? >>>> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >>>> >>>> Also -J (job-title) is something you can see in the queue when >>>> you do lpq. I don't know why it is tied to banner here but >>>> removing it seems wrong. Perhaps this should be renamed from >>>> "banner" and "BANNER" to jobTitle ?? Please examine this. >>>> >>>> In fact you seem to be conflicting with the -o nobanner. >>>> >>>> So in general we have some lack of clarity around job title and >>>> banner page >>>> (aka job sheet). >>>> >>>> Also we have PSPrinterJob and UnixPrinterJob with similar code. >>>> Please examine it to make sure no similar case is going missed. >>>> >>>> -phil. >>>> >>>> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that Banner page >>>>> in linux does not get printed despite user selecting the Banner >>>>> page checkbox in Printer dialog. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>>>> >>>>> It seems if we pass "-J " option to lpr command, it >>>>> has no effect. >>>>> To print Banner page, we need to pass >>>>> "-o job-sheets=>>>> "standard", "topsecret", or "unclassified">" >>>>> >>>>> Since we support only standard banner or none via a checkbox, >>>>> the proposed fix passes option "-o job-sheets=standard" to lpr >>>>> command to print the banner page. >>>>> >>>>> Regards >>>>> PRasanta >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jul 28 10:27:03 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 28 Jul 2016 15:57:03 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs In-Reply-To: <5798E06A.5030909@oracle.com> References: <577B791F.4020900@oracle.com> <5798E06A.5030909@oracle.com> Message-ID: <5799DDF7.30900@oracle.com> Trying to be extra cautious. Please find modified webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.01/ Regards Prasanta On 7/27/2016 9:55 PM, Phil Race wrote: > prAll is final and initalised. So why are you testing !=null ? > > -phil. > > On 07/05/2016 02:08 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen "Page range >> (From/To) " field is not disabled for flavors such as postscript, >> image flavors. >> PageRanges attribute is supported only for Service Formatted flavors >> such as Pageable and Printable and so for >> other flavors such as postscript, image flavors page ranges fields >> must be disabled on the print dialog so as not to allow the user to >> select the same >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 >> webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ >> >> Proposed fix is to check for attribute against the specified doc flavor >> and not against attribute category to decide whether to enable / >> disable it. >> >> Regards >> Prasanta > From prasanta.sadhukhan at oracle.com Thu Jul 28 10:34:16 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 28 Jul 2016 16:04:16 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8056210: Move libawt file to windows directory In-Reply-To: <6d307f80-6775-1e87-8213-41d51a056266@oracle.com> References: <579923B1.9070604@oracle.com> <6d307f80-6775-1e87-8213-41d51a056266@oracle.com> Message-ID: <5799DFA8.7040104@oracle.com> Looks ok. Regards Prasanta On 7/28/2016 3:04 PM, Sergey Bylokhov wrote: > Looks fine. > > On 28.07.16 0:12, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8056210 >> http://cr.openjdk.java.net/~prr/8056210/ >> >> Simple clean-up of moving code used only on windows into a windows >> source directory >> JPRT is happy .. >> >> -phil. > > From jayathirth.d.v at oracle.com Thu Jul 28 11:42:15 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 28 Jul 2016 04:42:15 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method In-Reply-To: <5774510D.1020307@oracle.com> References: <9fae0981-42a0-1af5-0de0-45f131b8555b@oracle.com> <57743DC2.7040001@oracle.com> <5774510D.1020307@oracle.com> Message-ID: Hi, We can follow the same approach of what we did in ColorModel.equals() for JDK-7107905. We can use getClass() check in ComponentSampleModel.equals() to differentiate between BandedSampleModel and PixelInterleavedSampleModel in rare cases where they can have same values and remove the need for equals() & hashCode() methods in these subclasses. We can update the specification of ComponentSampleModel.equals() to mention what properties we are checking and what its subclasses to follow as we did in ColorModel. Please find webrev for the above changes: http://cr.openjdk.java.net/~jdv/8153943/webrev.04/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, June 30, 2016 4:22 AM To: Phil Race Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method Hi Phil, The following 2 statements are factually correct ignoring what we plan to do about these classes: - If they don't override equals() then they shouldn't override hash - Their raw casts were wrong (and the fact that nobody ever noticed that is a good indication that these methods have probably not been used in the wild). What I'm waffling on is that while the equals() methods appeared functionally useless, in practice they can either block or allow disparate class objects from being equal to each other and I'm thinking that one could argue that it makes strategic sense to enforce the correct class type (using instanceof) to match the behavioral expectations of a developer. Since I sent that out I also checked a similar case in the Number subclasses and an Integer and a Long will not evaluate to equals even if they hold the same cardinal value. Arguably that's even a stronger case of when 2 disparate objects might want to be seen as equals(), but we don't allow it there. Arguably, the override of hash is still unnecessary since it would be fine to allow disparate classes to have the same hash value from the super class - that doesn't violate any contracts. You can't allow it to inherit from Object.hashCode() since that hash value is very strict, but it would be OK to override the somewhat "property oriented" hash code from their immediate superclass. I would lean towards leaving it in if we decide to override equals() just to avoid the argument. Given the fact that these equals() methods have obviously not been used much, I don't have a strong opinion between "saving code by just not overriding them" and "making the different subclasses have unique identities by overriding and preventing them from being equal to each other". In the end, if we do fix the equals() for these classes, we should document why they are overriding equals() even if it appears to do not really value added testing compared to the super class... ...jim On 06/29/2016 02:29 PM, Phil Race wrote: > > To remind myself and others .. this review started out with changes to > the ColorModel classes mixed in. > Those were separated out making it easier to review just the > SampleModel hierachy here. > > Jim observed (see some way below for the context) :- > > > PixelInterleavedSampleModel and BandedSampleModel also have a > > meaningless override of super.equals/hashCode(). > > I think that comment is from when the webrev for those files looked > like this :- > > http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/sha > re/classes/java/awt/image/BandedSampleModel.java.sdiff.html > > http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/sha > re/classes/java/awt/image/PixelInterleavedSampleModel.java.sdiff.html > > > So Jim, are you suggesting a preferred option is to go back to that > proposal - at least for the equals methods ? > [Caveat : the proposed equals method there should test instanceof > before doing a cast but I actually don't know why it needs the cast > anyway] > > The hashCode() could be left alone in that case. > > But if the equals methods are not added as there, then I think we do > need to remove the > hashCode() since it could be different even if (albeit only in a > degenerate case), whilst instances (of the different classes) could > compare as equal. > > But in either case we need to look to the super-class which is lacking > any documentation of its own describing what makes two instances > equal. > We could try to explain there what might otherwise be surprising. > > -phil. > > > On 06/28/2016 01:40 PM, Jim Graham wrote: >> Still hoping to hear an opinion from Phil on this... >> >> The alternative is to add equals() overrides in the subclasses that >> just do "obj instanceof && super.equals()" which would only >> matter in some specific somewhat degenerate cases. >> >> The intent would be that even though the layout and pixel fetching >> behavior for a specific configuration of PISM and BSM are identical, >> they are philosophically not the same and so should not evaluate as >> equals()... >> >> ...Or, should they? >> >> ...jim >> >> On 6/27/16 4:05 PM, Jim Graham wrote: >>> This is odd that two completely different classes have identical >>> "equals()" methods. After looking into it in more detail it looks >>> as if ComponentSM is implemented as a general case that can >>> encompass either PixelInterleaved or Banded pixel layouts - which >>> means the subclasses are mostly just cosmetic (offering the >>> constructors that make most sense if the pixels are laid out in the >>> different ways) and only Banded offers a different implementation of >>> getDataElements which is only different from the super >>> implementation by virtue of eliminating a "multiply by a number >>> which we know to be 1". >>> >>> There are also some restrictions in the constructors that enforce >>> limits on the various values that CSM allows in its general >>> implementation, so it isn't possible to use the PixelInterleaved >>> constructor to create an arbitrarily-valued CSM nor to use the >>> Banded constructors for the same purpose. The overlap in the type >>> of CSM you can create from each of their constructors is very tiny >>> to non-existant. >>> >>> The end result is that it ends up being infeasible to define a >>> PixelInterleaved and a Banded SM that are equals() (not impossible, >>> but you'd have to have a very degenerate case like a 1x1 image to >>> make it through the various restrictions in the constructors and the >>> offsets and the scanline strides and pixel strides, etc.). It's >>> really odd in theory, and while not a problem in practice it still >>> feels as if it violates an expectation. The primary restrictions I >>> see getting in the way of different classed objects being equals() >>> is that Banded forces a pixel stride of 1 and PixelInterleaved >>> enforces that all band offsets are smaller than the scan stride. >>> >>> So, technically, I don't see any issue with just removing the hash >>> method as the webrev proposes, but I'd like to see Phil's reaction >>> to the situation we are in here with respect to intent vs. theory >>> vs. practice vs. developer expectation... >>> >>> ...jim >>> >>> On 6/24/16 10:34 AM, Jayathirth D V wrote: >>>> Hi, >>>> >>>> Please find following changes for review in JDK9 : >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.03/ >>>> >>>> Issue : We have hashCode() method in PixelInterleavedSampleModel >>>> and BandedSampleModel, but we don't have corresponding equals() >>>> method. >>>> >>>> Solution : In PixelInterleavedSampleModel and BandedSampleModel we >>>> don't have unique properties that are specific to these subclasses >>>> and we have proper equals() & hashCode() method in parent class >>>> ComponentSampleModel. So removed >>>> hashCode() method present in PixelInterleavedSampleModel and >>>> BandedSampleModel. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Wednesday, May 04, 2016 2:44 AM >>>> To: Phil Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>>> java.awt.image package some of the classes are missing hashCode() >>>> or equals() method >>>> >>>> Yes, the equals/hashcode chapter in Effective Java includes rules >>>> about ignoring fields that can be calculated from other fields >>>> (which applies to most internal fields). Basically, only things in >>>> the constructors tend to be good candidates for equals/hashcode... >>>> >>>> ...jim >>>> >>>> On 5/3/2016 2:00 PM, Phil Race wrote: >>>>> On 04/26/2016 04:10 PM, Jim Graham wrote: >>>>>> The ComponentColorModel implementation is a meaningless wrapper >>>>>> around super.equals/hashCode(). Why does it not test >>>>>> CCM-specific fields? >>>>> >>>>> It should although this looks like it is more than just running >>>>> through all the fields and testing them for equality. >>>>> eg it looks like "initScale()" should be called if necessary >>>>> before determining equality and the field "needScaleInit" is not >>>>> one that has to be directly included in the equality comparison. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> >>>>>> >>>>>> The ComponentSampleModel.hashCode() method should be upgraded >>>>>> based on the recommendations in Effective Java like the other methods here. >>>>>> >>>>>> PixelInterleavedSampleModel and BandedSampleModel also have a >>>>>> meaningless override of super.equals/hashCode(). >>>>>> >>>>>> And all of these classes suffer from casting to the specific type >>>>>> before verifying its class as I mentioned in the ICM.equals() >>>>>> review... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 4/25/16 2:31 AM, Jayathirth D V wrote: >>>>>>> Hi Jim, >>>>>>> >>>>>>> I have made changes to include check for class equality in base >>>>>>> class and use super.equals() from subclasses. >>>>>>> Please find updated webrev for review : >>>>>>> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ >>>>>>> >>>>>>> Change related to ColorModel is present in JDK-7107905 review. >>>>>>> >>>>>>> Thanks, >>>>>>> Jay >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jim Graham >>>>>>> Sent: Saturday, April 23, 2016 7:30 AM >>>>>>> To: Phil Race; Jayathirth D V >>>>>>> Cc: 2d-dev at openjdk.java.net >>>>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : >>>>>>> In java.awt.image package some of the classes are missing >>>>>>> hashCode() or >>>>>>> equals() method >>>>>>> >>>>>>> This is actually a pretty nasty issue that Joe Darcy also >>>>>>> brought up in the CCC review. >>>>>>> >>>>>>> In order to have symmetric testing of .equals(), we pretty much >>>>>>> have to enforce this test at all levels, including in the >>>>>>> original >>>>>>> ColorModels.equals() method. If we don't enforce this in >>>>>>> CM.equals(), then we could run ccm.equals(othercm) and it would >>>>>>> return false because the class is wrong, but turning it around >>>>>>> and testing >>>>>>> othercm.equals(ccm) would succeed because it doesn't enforce the >>>>>>> class equality. >>>>>>> >>>>>>> So, I'd recommend that CM.equals() tests getClass() == >>>>>>> getClass() at the base level and then all others will use >>>>>>> super.equals() and get the same protection. It means you can't >>>>>>> have a subclass of CCM be "equals" to a different subclass of >>>>>>> CCM, but that's an unfortunate issue with equals needing to >>>>>>> honor symmetry... :( >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 4/20/2016 10:17 AM, Phil Race wrote: >>>>>>>> Hi, You removed the following test in CCM.java : 2941 if >>>>>>>> (obj.getClass() != getClass()) { >>>>>>>> 2942 return false; >>>>>>>> >>>>>>>> 2943 } >>>>>>>> >>>>>>>> What this means is that before your change an instance of a >>>>>>>> subclass of CCM would never be equals() to any direct >>>>>>>> instantiatation of CCM but after your change it can be. I >>>>>>>> suspect the condition was there on purpose. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _Please review the following fix in JDK9:_ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This is subtask of >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6588409 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Issue : Some of the java.awt.image classes are missing either >>>>>>>>> equals() or hashCode() method. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Solution : Add missing equals() or hashCode() methods. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> > From Sergey.Bylokhov at oracle.com Thu Jul 28 12:41:37 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Jul 2016 15:41:37 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8148477: Native memory leak in font layout subsystem In-Reply-To: <5799307B.6010402@oracle.com> References: <5799307B.6010402@oracle.com> Message-ID: Looks fine. I wander is it possible to improve it via GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical? On 28.07.16 1:06, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8158477 > http://cr.openjdk.java.net/~prr/8158477/ > > Missing a call to ReleaseCharArrayElements() > > With this fix the test in the bug runs happily for many minutes without any > increase at all in virtual memory. About 1.5 million invocations of the > layout code so far. > > The JNI exception checking is just something I noticed was missing .. not > relevant to the leak. > > No reg. test since it is not something you can test easily from jtreg .. > > -phil. -- Best regards, Sergey. From philip.race at oracle.com Thu Jul 28 12:45:33 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Jul 2016 05:45:33 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8148477: Native memory leak in font layout subsystem In-Reply-To: References: <5799307B.6010402@oracle.com> Message-ID: <5799FE6D.6000500@oracle.com> There's usually some fairly lengthy processing going on in the layout code so I think it would be too long to hold a critical lock and not likely to show a detectable benefit. Also I think it possible we may make some Java upcalls there .. -phil. On 7/28/16, 5:41 AM, Sergey Bylokhov wrote: > Looks fine. > I wander is it possible to improve it via > GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical? > > On 28.07.16 1:06, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8158477 >> http://cr.openjdk.java.net/~prr/8158477/ >> >> Missing a call to ReleaseCharArrayElements() >> >> With this fix the test in the bug runs happily for many minutes >> without any >> increase at all in virtual memory. About 1.5 million invocations of the >> layout code so far. >> >> The JNI exception checking is just something I noticed was missing .. >> not >> relevant to the leak. >> >> No reg. test since it is not something you can test easily from jtreg .. >> >> -phil. > > From philip.race at oracle.com Thu Jul 28 13:40:26 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Jul 2016 06:40:26 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs In-Reply-To: <5799DDF7.30900@oracle.com> References: <577B791F.4020900@oracle.com> <5798E06A.5030909@oracle.com> <5799DDF7.30900@oracle.com> Message-ID: <579A0B4A.1060400@oracle.com> This can now be written more succinctly (and clearly) as : prPgRngSupported = psCurrent.isAttributeValueSupported(prAll, docFlavor,asCurrent); -phil. On 7/28/16, 3:27 AM, Prasanta Sadhukhan wrote: > Trying to be extra cautious. Please find modified webrev: > http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.01/ > > Regards > Prasanta > On 7/27/2016 9:55 PM, Phil Race wrote: >> prAll is final and initalised. So why are you testing !=null ? >> >> -phil. >> >> On 07/05/2016 02:08 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen "Page range >>> (From/To) " field is not disabled for flavors such as postscript, >>> image flavors. >>> PageRanges attribute is supported only for Service Formatted flavors >>> such as Pageable and Printable and so for >>> other flavors such as postscript, image flavors page ranges fields >>> must be disabled on the print dialog so as not to allow the user to >>> select the same >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ >>> >>> Proposed fix is to check for attribute against the specified doc flavor >>> and not against attribute category to decide whether to enable / >>> disable it. >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 28 15:49:23 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 Jul 2016 08:49:23 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <5799D5B1.4090808@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> <579886BF.30600@oracle.com> <5798BC1F.2010605@oracle.com> <5799D5B1.4090808@oracle.com> Message-ID: <361e6046-dd03-b524-061e-955e8da3658b@oracle.com> right .. when we talked off-line yesterday I said that if IPP is reporting a default we should honour it. The default of standard/on is only for the case we do not use IPP or it reports nothing. if (noJobSheet) { 885 pFlags |= NOSHEET; 886 ncomps+=1; 887 } else { 888 ncomps+=1; 889 } .... 905 if ((pFlags & NOSHEET) != 0) { 906 execCmd[n++] = "-o nobanner"; 907 } else if (getPrintService(). 908 isAttributeCategorySupported(JobSheets.class)) { 909 execCmd[n++] = "-o job-sheets=standard"; 910 } So shouldn't the else at line 887 have the same condition as at line 907 ? 2750 JobSheets js = (JobSheets)asCurrent.get(jsCategory); 2751 if (js == null) { 2752 js = (JobSheets)psCurrent.getDefaultAttributeValue(jsCategory); 2753 if (js == null) { 2754 js = JobSheets.STANDARD; 2755 } Please make sure this isn't causing a surprise on OSX or Windows .. ie that we report correctly a value there so that "null" doesn't end up causing us to print a banner page where we did not before. -phil. On 7/28/2016 2:51 AM, Prasanta Sadhukhan wrote: > The banner checkbox is not enabled initially as it calls > getDefaultAttributeValue() and it seems printer is reporting the > default job-sheet value as "none" so the below check is not satisfied. > cbJobSheets.setSelected(js != JobSheets.NONE); > > When IPPPrintService#readIPPResponse() is called, it invokes /new > AttributeClass(attribStr, valTagByte, outArray); > /and stored the value corresponding to each attribute. > > I saw that IPP response has > *job-sheets-default => job-sheets-default *and* > **job-sheets-supported => job-sheets-supported* > > When AttributeClass constructor is called with ("job-sheets-default", > 66, value) the value is > [ 0] = (byte) 4 [ 1] = (byte) 110 [ 2] = (byte) 111 [ 3] = > (byte) 110 [ 4] = (byte) 101 [ 5] = (byte) 4 [ 6] = (byte) > 110 [ 7] = (byte) 111 [ 8] = (byte) 110 [ 9] = (byte) 101 > [10] = (byte) 2 > which basically translates to '',n,o,n,e,'',n,o,n,e,'' > > so when ServiceDialog calls > IPPPrintService#getDefaultAttributeValue(JobSheets) > ---------------- > if (attribClass != null && > attribClass.getStringValue().equals("none")) { > return JobSheets.NONE; > } else { > return JobSheets.STANDARD; > } > -------------- > we have attribClass.getStringValue() as "none" so default job sheet > value is coming out to be NONE. > Since it is coming out from IPP response, I think we should not change > default value of JobSheets to STANDARD. Do you think otherwise? > > In the modified webrev, I have made the jobsheet default value > STANDARD, only when IPP does not report any default value. > > http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.03/ > > Tested in ubuntu & solaris11. > > Regards > Prasanta > On 7/27/2016 7:20 PM, Philip Race wrote: >> 883 } else { >> 884 Class[] supportedCats = getPrintService(). >> 885 getSupportedAttributeCategories(); >> 886 for (int i=0;i> 887 if (JobSheets.class == supportedCats[i]) { >> 888 pFlags |= JOBSHEET; >> 889 ncomps+=1; >> 890 break; >> 891 } >> 892 } >> >> What is wrong with >> >> getPrintService().isAttributeCategorySupported(JobSheets.class) ? >> >> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeCategorySupported-java.lang.Class- >> >> >> I am also very confused about why you added JOBSHEET >> which seems to duplicate the functionality of NOSHEET. >> >> Also it seems to me like it was intentional that the banner page be >> printed by default .. which is why the variable was called >> "*no*JobSheet .. >> so as to over-ride that behaviour. >> >> It is kind of what you'd want if you walk over to the shared printer in >> your office to have a banner page which declares it as yours ... >> >> So the checkbox should probably be enabled in that case. >> >> Also you should verify that we report the default value for JobSheets >> as being STANDARD, not NONE. >> >> >> -phil. >> >> On 7/27/16, 3:02 AM, Prasanta Sadhukhan wrote: >>> Modified webrev to take care of a problem in webrev.01 whereby >>> banner page was getting printed by default. >>> Now, banner page will get printed only if the checkbox is checked in >>> printer dialog. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: >>>> Hi Phil, >>>> >>>> I have modified the code to check if job-sheets is supported and >>>> then only proceed to print the banner page. >>>> Also, rectified the jobTitle and banner confusion by adding >>>> jobsheet check. >>>> Also added the same code in UnixPrintJob even though I found its >>>> printExecCmd() does not get executed in linux and solaris >>>> PSPrinterJob's printExecCmd() is executed instead. In mac, neither >>>> UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets >>>> executed. >>>> >>>> Tested on ubuntu and solaris 11 with the fix and banner page is >>>> printed with the fix. In mac, cover page gets printed without any >>>> change. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ >>>> >>>> Regards >>>> Prasanta >>>> On 7/20/2016 8:56 PM, Philip Race wrote: >>>>> In my evaluation of that bug (which was 9 yrs ago so I do not have >>>>> any memory of it :-)), I note that we first need to check >>>>> that job-sheets is supported .. you are not doing that .. >>>>> what happens if we pass an unsupported option ? >>>>> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >>>>> >>>>> Also -J (job-title) is something you can see in the queue when >>>>> you do lpq. I don't know why it is tied to banner here but >>>>> removing it seems wrong. Perhaps this should be renamed from >>>>> "banner" and "BANNER" to jobTitle ?? Please examine this. >>>>> >>>>> In fact you seem to be conflicting with the -o nobanner. >>>>> >>>>> So in general we have some lack of clarity around job title and >>>>> banner page >>>>> (aka job sheet). >>>>> >>>>> Also we have PSPrinterJob and UnixPrinterJob with similar code. >>>>> Please examine it to make sure no similar case is going missed. >>>>> >>>>> -phil. >>>>> >>>>> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where it is seen that Banner >>>>>> page in linux does not get printed despite user selecting the >>>>>> Banner page checkbox in Printer dialog. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>>>>> >>>>>> It seems if we pass "-J " option to lpr command, it >>>>>> has no effect. >>>>>> To print Banner page, we need to pass >>>>>> "-o job-sheets=>>>>> "standard", "topsecret", or "unclassified">" >>>>>> >>>>>> Since we support only standard banner or none via a checkbox, >>>>>> the proposed fix passes option "-o job-sheets=standard" to lpr >>>>>> command to print the banner page. >>>>>> >>>>>> Regards >>>>>> PRasanta >>>> >>> > From james.graham at oracle.com Thu Jul 28 22:56:00 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 28 Jul 2016 15:56:00 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method In-Reply-To: References: <9fae0981-42a0-1af5-0de0-45f131b8555b@oracle.com> <57743DC2.7040001@oracle.com> <5774510D.1020307@oracle.com> Message-ID: <014f0016-0bb4-b8a3-7a08-d62ed8c41a82@oracle.com> These classes are a mess. CSM has numBands, but so does the super class. We should probably delete the copy in the subclass. CSM constructors re-initialize data members that were already initialized in the super() constructor. CSM.equals() and hashCode() include code that really should belong in SM.equals() and SM.hashCode(), but SM doesn't override those. CSM constructor comments talk about exceptions thrown for things like "numBands" even though there is no such argument in the constructor - the number of bands is inferred from the number of band offsets, so it should really be expressed in terms of that array length instead. We should follow the same pattern as CM, have SM override equals/hash and calculate its own values. Have the subclasses stop duplicating fields and initialization steps that would be found in the super class, etc... ...jim On 07/28/2016 04:42 AM, Jayathirth D V wrote: > Hi, > > We can follow the same approach of what we did in ColorModel.equals() for JDK-7107905. > > We can use getClass() check in ComponentSampleModel.equals() to differentiate between BandedSampleModel and PixelInterleavedSampleModel in rare cases where they can have same values and remove the need for equals() & hashCode() methods in these subclasses. > We can update the specification of ComponentSampleModel.equals() to mention what properties we are checking and what its subclasses to follow as we did in ColorModel. > > Please find webrev for the above changes: > http://cr.openjdk.java.net/~jdv/8153943/webrev.04/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, June 30, 2016 4:22 AM > To: Phil Race > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method > > Hi Phil, > > The following 2 statements are factually correct ignoring what we plan to do about these classes: > > - If they don't override equals() then they shouldn't override hash > > - Their raw casts were wrong (and the fact that nobody ever noticed that is a good indication that these methods have probably not been used in the wild). > > What I'm waffling on is that while the equals() methods appeared functionally useless, in practice they can either block or allow disparate class objects from being equal to each other and I'm thinking that one could argue that it makes strategic sense to enforce the correct class type (using instanceof) to match the behavioral expectations of a developer. > > Since I sent that out I also checked a similar case in the Number subclasses and an Integer and a Long will not evaluate to equals even if they hold the same cardinal value. Arguably that's even a stronger case of when 2 disparate objects might want to be seen as equals(), but we don't allow it there. > > Arguably, the override of hash is still unnecessary since it would be fine to allow disparate classes to have the same hash value from the super class - that doesn't violate any contracts. You can't allow it to inherit from Object.hashCode() since that hash value is very strict, but it would be OK to override the somewhat "property oriented" hash code from their immediate superclass. I would lean towards leaving it in if we decide to override equals() just to avoid the argument. > > Given the fact that these equals() methods have obviously not been used much, I don't have a strong opinion between "saving code by just not overriding them" and "making the different subclasses have unique identities by overriding and preventing them from being equal to each other". > > In the end, if we do fix the equals() for these classes, we should document why they are overriding equals() even if it appears to do not really value added testing compared to the super class... > > ...jim > > On 06/29/2016 02:29 PM, Phil Race wrote: >> >> To remind myself and others .. this review started out with changes to >> the ColorModel classes mixed in. >> Those were separated out making it easier to review just the >> SampleModel hierachy here. >> >> Jim observed (see some way below for the context) :- >> >> > PixelInterleavedSampleModel and BandedSampleModel also have a > >> meaningless override of super.equals/hashCode(). >> >> I think that comment is from when the webrev for those files looked >> like this :- >> >> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/sha >> re/classes/java/awt/image/BandedSampleModel.java.sdiff.html >> >> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/sha >> re/classes/java/awt/image/PixelInterleavedSampleModel.java.sdiff.html >> >> >> So Jim, are you suggesting a preferred option is to go back to that >> proposal - at least for the equals methods ? >> [Caveat : the proposed equals method there should test instanceof >> before doing a cast but I actually don't know why it needs the cast >> anyway] >> >> The hashCode() could be left alone in that case. >> >> But if the equals methods are not added as there, then I think we do >> need to remove the >> hashCode() since it could be different even if (albeit only in a >> degenerate case), whilst instances (of the different classes) could >> compare as equal. >> >> But in either case we need to look to the super-class which is lacking >> any documentation of its own describing what makes two instances >> equal. >> We could try to explain there what might otherwise be surprising. >> >> -phil. >> >> >> On 06/28/2016 01:40 PM, Jim Graham wrote: >>> Still hoping to hear an opinion from Phil on this... >>> >>> The alternative is to add equals() overrides in the subclasses that >>> just do "obj instanceof && super.equals()" which would only >>> matter in some specific somewhat degenerate cases. >>> >>> The intent would be that even though the layout and pixel fetching >>> behavior for a specific configuration of PISM and BSM are identical, >>> they are philosophically not the same and so should not evaluate as >>> equals()... >>> >>> ...Or, should they? >>> >>> ...jim >>> >>> On 6/27/16 4:05 PM, Jim Graham wrote: >>>> This is odd that two completely different classes have identical >>>> "equals()" methods. After looking into it in more detail it looks >>>> as if ComponentSM is implemented as a general case that can >>>> encompass either PixelInterleaved or Banded pixel layouts - which >>>> means the subclasses are mostly just cosmetic (offering the >>>> constructors that make most sense if the pixels are laid out in the >>>> different ways) and only Banded offers a different implementation of >>>> getDataElements which is only different from the super >>>> implementation by virtue of eliminating a "multiply by a number >>>> which we know to be 1". >>>> >>>> There are also some restrictions in the constructors that enforce >>>> limits on the various values that CSM allows in its general >>>> implementation, so it isn't possible to use the PixelInterleaved >>>> constructor to create an arbitrarily-valued CSM nor to use the >>>> Banded constructors for the same purpose. The overlap in the type >>>> of CSM you can create from each of their constructors is very tiny >>>> to non-existant. >>>> >>>> The end result is that it ends up being infeasible to define a >>>> PixelInterleaved and a Banded SM that are equals() (not impossible, >>>> but you'd have to have a very degenerate case like a 1x1 image to >>>> make it through the various restrictions in the constructors and the >>>> offsets and the scanline strides and pixel strides, etc.). It's >>>> really odd in theory, and while not a problem in practice it still >>>> feels as if it violates an expectation. The primary restrictions I >>>> see getting in the way of different classed objects being equals() >>>> is that Banded forces a pixel stride of 1 and PixelInterleaved >>>> enforces that all band offsets are smaller than the scan stride. >>>> >>>> So, technically, I don't see any issue with just removing the hash >>>> method as the webrev proposes, but I'd like to see Phil's reaction >>>> to the situation we are in here with respect to intent vs. theory >>>> vs. practice vs. developer expectation... >>>> >>>> ...jim >>>> >>>> On 6/24/16 10:34 AM, Jayathirth D V wrote: >>>>> Hi, >>>>> >>>>> Please find following changes for review in JDK9 : >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.03/ >>>>> >>>>> Issue : We have hashCode() method in PixelInterleavedSampleModel >>>>> and BandedSampleModel, but we don't have corresponding equals() >>>>> method. >>>>> >>>>> Solution : In PixelInterleavedSampleModel and BandedSampleModel we >>>>> don't have unique properties that are specific to these subclasses >>>>> and we have proper equals() & hashCode() method in parent class >>>>> ComponentSampleModel. So removed >>>>> hashCode() method present in PixelInterleavedSampleModel and >>>>> BandedSampleModel. >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Wednesday, May 04, 2016 2:44 AM >>>>> To: Phil Race >>>>> Cc: 2d-dev at openjdk.java.net >>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>>>> java.awt.image package some of the classes are missing hashCode() >>>>> or equals() method >>>>> >>>>> Yes, the equals/hashcode chapter in Effective Java includes rules >>>>> about ignoring fields that can be calculated from other fields >>>>> (which applies to most internal fields). Basically, only things in >>>>> the constructors tend to be good candidates for equals/hashcode... >>>>> >>>>> ...jim >>>>> >>>>> On 5/3/2016 2:00 PM, Phil Race wrote: >>>>>> On 04/26/2016 04:10 PM, Jim Graham wrote: >>>>>>> The ComponentColorModel implementation is a meaningless wrapper >>>>>>> around super.equals/hashCode(). Why does it not test >>>>>>> CCM-specific fields? >>>>>> >>>>>> It should although this looks like it is more than just running >>>>>> through all the fields and testing them for equality. >>>>>> eg it looks like "initScale()" should be called if necessary >>>>>> before determining equality and the field "needScaleInit" is not >>>>>> one that has to be directly included in the equality comparison. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> The ComponentSampleModel.hashCode() method should be upgraded >>>>>>> based on the recommendations in Effective Java like the other methods here. >>>>>>> >>>>>>> PixelInterleavedSampleModel and BandedSampleModel also have a >>>>>>> meaningless override of super.equals/hashCode(). >>>>>>> >>>>>>> And all of these classes suffer from casting to the specific type >>>>>>> before verifying its class as I mentioned in the ICM.equals() >>>>>>> review... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 4/25/16 2:31 AM, Jayathirth D V wrote: >>>>>>>> Hi Jim, >>>>>>>> >>>>>>>> I have made changes to include check for class equality in base >>>>>>>> class and use super.equals() from subclasses. >>>>>>>> Please find updated webrev for review : >>>>>>>> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ >>>>>>>> >>>>>>>> Change related to ColorModel is present in JDK-7107905 review. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jay >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Graham >>>>>>>> Sent: Saturday, April 23, 2016 7:30 AM >>>>>>>> To: Phil Race; Jayathirth D V >>>>>>>> Cc: 2d-dev at openjdk.java.net >>>>>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : >>>>>>>> In java.awt.image package some of the classes are missing >>>>>>>> hashCode() or >>>>>>>> equals() method >>>>>>>> >>>>>>>> This is actually a pretty nasty issue that Joe Darcy also >>>>>>>> brought up in the CCC review. >>>>>>>> >>>>>>>> In order to have symmetric testing of .equals(), we pretty much >>>>>>>> have to enforce this test at all levels, including in the >>>>>>>> original >>>>>>>> ColorModels.equals() method. If we don't enforce this in >>>>>>>> CM.equals(), then we could run ccm.equals(othercm) and it would >>>>>>>> return false because the class is wrong, but turning it around >>>>>>>> and testing >>>>>>>> othercm.equals(ccm) would succeed because it doesn't enforce the >>>>>>>> class equality. >>>>>>>> >>>>>>>> So, I'd recommend that CM.equals() tests getClass() == >>>>>>>> getClass() at the base level and then all others will use >>>>>>>> super.equals() and get the same protection. It means you can't >>>>>>>> have a subclass of CCM be "equals" to a different subclass of >>>>>>>> CCM, but that's an unfortunate issue with equals needing to >>>>>>>> honor symmetry... :( >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 4/20/2016 10:17 AM, Phil Race wrote: >>>>>>>>> Hi, You removed the following test in CCM.java : 2941 if >>>>>>>>> (obj.getClass() != getClass()) { >>>>>>>>> 2942 return false; >>>>>>>>> >>>>>>>>> 2943 } >>>>>>>>> >>>>>>>>> What this means is that before your change an instance of a >>>>>>>>> subclass of CCM would never be equals() to any direct >>>>>>>>> instantiatation of CCM but after your change it can be. I >>>>>>>>> suspect the condition was there on purpose. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _Please review the following fix in JDK9:_ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is subtask of >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6588409 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Issue : Some of the java.awt.image classes are missing either >>>>>>>>>> equals() or hashCode() method. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Solution : Add missing equals() or hashCode() methods. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Jay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>> >> From philip.race at oracle.com Thu Jul 28 23:31:34 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Jul 2016 16:31:34 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v Message-ID: <579A95D6.3090604@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 Fix: http://cr.openjdk.java.net/~prr/8074843/ Here's a sampling of the warnings that I think covers most, maybe all, of the cases LINUX mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses around '-' in operand of '&' [-Werror=parentheses] res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << ^ mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses around '-' in operand of '&' [-Werror=parentheses] res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); ----------------- mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': mlib_c_ImageCopy.c:439:5: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] STRIP(pdst, psrc, src_width, src_height, mlib_u16); ^ - MAC ... mlib_c_ImageCopy.c:331:5: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] STRIP(pdst, psrc, src_width, src_height, mlib_u8); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' if (j = w & 1) \ ~~^~~~~~~ mlib_c_ImageCopy.c:331:5: note: place parentheses around the assignment to silence this warning\ --- --- SOLARIS mlib_ImageConv_16ext.c", line 532: statement not reached (E_STATEMENT_NOT_REACHED) This last one was not nice just the ";" was considered a statement after the {XX; YY; return Z} macro expansion and turning into "do { {....} } while (0)" did not help since then it said "loop terminator not reached - other cases we have like this have at least a condition in the macro. -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 29 05:28:27 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 29 Jul 2016 10:58:27 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs In-Reply-To: <579A0B4A.1060400@oracle.com> References: <577B791F.4020900@oracle.com> <5798E06A.5030909@oracle.com> <5799DDF7.30900@oracle.com> <579A0B4A.1060400@oracle.com> Message-ID: <579AE97B.6090403@oracle.com> Yes, right. Please find the modified webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.02/ Regards Prasanta On 7/28/2016 7:10 PM, Philip Race wrote: > This can now be written more succinctly (and clearly) as : > prPgRngSupported =psCurrent.isAttributeValueSupported(prAll, > docFlavor, asCurrent); > > -phil. > > On 7/28/16, 3:27 AM, Prasanta Sadhukhan wrote: >> Trying to be extra cautious. Please find modified webrev: >> http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.01/ >> >> Regards >> Prasanta >> On 7/27/2016 9:55 PM, Phil Race wrote: >>> prAll is final and initalised. So why are you testing !=null ? >>> >>> -phil. >>> >>> On 07/05/2016 02:08 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen "Page range >>>> (From/To) " field is not disabled for flavors such as postscript, >>>> image flavors. >>>> PageRanges attribute is supported only for Service Formatted >>>> flavors such as Pageable and Printable and so for >>>> other flavors such as postscript, image flavors page ranges fields >>>> must be disabled on the print dialog so as not to allow the user to >>>> select the same >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ >>>> >>>> Proposed fix is to check for attribute against the specified doc >>>> flavor >>>> and not against attribute category to decide whether to enable / >>>> disable it. >>>> >>>> Regards >>>> Prasanta >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Fri Jul 29 10:23:27 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 29 Jul 2016 13:23:27 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <579A95D6.3090604@oracle.com> References: <579A95D6.3090604@oracle.com> Message-ID: <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> Phil, I guess you wanted to remove the lines in the Awt2dLibraries.gmk? Do you think it's worth it to rewrite these assignments as separate assignment and a condition? Especially long ones with a lot of parentheses? Like this one, instead of if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; if (j != 0) { Also seeing macro calls without a semicolon is weird. I don't see any need in parentheses in the definition of FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it without trailing semicolon? Thanks, Vadim On 29.07.2016 2:31, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 > Fix: http://cr.openjdk.java.net/~prr/8074843/ > > Here's a sampling of the warnings that I think covers most, maybe all, > of the cases > LINUX > mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses around '-' > in operand of '&' [-Werror=parentheses] > res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT + > 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << > ^ > mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses around > '-' in operand of '&' [-Werror=parentheses] > res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT + > 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); > > ----------------- > mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': > mlib_c_ImageCopy.c:439:5: error: suggest parentheses around assignment > used as truth value [-Werror=parentheses] > STRIP(pdst, psrc, src_width, src_height, mlib_u16); > ^ > - > MAC ... > > mlib_c_ImageCopy.c:331:5: error: using the result of an assignment as > a condition without parentheses [-Werror,-Wparentheses] > STRIP(pdst, psrc, src_width, src_height, mlib_u8); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' > if (j = w & 1) \ > ~~^~~~~~~ > mlib_c_ImageCopy.c:331:5: note: place parentheses around the > assignment to silence this warning\ > > --- > > > --- > SOLARIS > mlib_ImageConv_16ext.c", line 532: statement not reached > (E_STATEMENT_NOT_REACHED) > > This last one was not nice just the ";" was considered a statement > after the {XX; YY; return Z} macro expansion > and turning into "do { {....} } while (0)" did not help since > then it said "loop terminator not reached - other cases we have > like this have at least a condition in the macro. > > -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 29 13:28:35 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 29 Jul 2016 06:28:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> Message-ID: <579B5A03.7000801@oracle.com> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: > Phil, > > I guess you wanted to remove the lines in the Awt2dLibraries.gmk? Ah, yes. Not just disable them > > Do you think it's worth it to rewrite these assignments as separate > assignment and a condition? > Especially long ones with a lot of parentheses? > Like this one, instead of > if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { > > j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; > if (j != 0) { I don't know. Where would I stop ? > > Also seeing macro calls without a semicolon is weird. > I don't see any need in parentheses in the definition of > FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it without > trailing semicolon? I anticipated the question and it is already addressed in my last paragraph right at the very bottom of the review request. Basically that pattern has an "if (x==NULL) return". If you don't have that "if" then the compiler would have objected to that too ! > > Thanks, > Vadim > > On 29.07.2016 2:31, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >> Fix: http://cr.openjdk.java.net/~prr/8074843/ >> >> Here's a sampling of the warnings that I think covers most, maybe >> all, of the cases >> LINUX >> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses around >> '-' in operand of '&' [-Werror=parentheses] >> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT >> + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >> >> ^ >> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses around >> '-' in operand of '&' [-Werror=parentheses] >> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT >> + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >> >> ----------------- >> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >> assignment used as truth value [-Werror=parentheses] >> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >> ^ >> - >> MAC ... >> >> mlib_c_ImageCopy.c:331:5: error: using the result of an assignment as >> a condition without parentheses [-Werror,-Wparentheses] >> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >> if (j = w & 1) \ >> ~~^~~~~~~ >> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >> assignment to silence this warning\ >> >> --- >> >> >> --- >> SOLARIS >> mlib_ImageConv_16ext.c", line 532: statement not reached >> (E_STATEMENT_NOT_REACHED) >> >> This last one was not nice just the ";" was considered a statement >> after the {XX; YY; return Z} macro expansion >> and turning into "do { {....} } while (0)" did not help since >> then it said "loop terminator not reached - other cases we have >> like this have at least a condition in the macro. >> >> -phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Fri Jul 29 14:00:56 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 29 Jul 2016 17:00:56 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <579B5A03.7000801@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> Message-ID: <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> On 29.07.2016 16:28, Philip Race wrote: > > > On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >> Phil, >> >> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? > > Ah, yes. Not just disable them >> >> Do you think it's worth it to rewrite these assignments as separate >> assignment and a condition? >> Especially long ones with a lot of parentheses? >> Like this one, instead of >> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >> >> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >> if (j != 0) { > > I don't know. Where would I stop ? Where it doesn't feel weird anymore? For example, is this line correct? if (j = (((mlib_addr) pdst_row & 2) != 0)) { It seems very weird for me that we assign a boolean value to the loop variable. It looks like there's an error in parentheses and it should instead look like: if ((j = (((mlib_addr) pdst_row & 2) != 0) { Yeah, in this particular case it doesn't even matter but still assignments in conditions can very easily lead to errors. > >> >> Also seeing macro calls without a semicolon is weird. >> I don't see any need in parentheses in the definition of >> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it without >> trailing semicolon? > > I anticipated the question and it is already addressed in my last > paragraph right at the very bottom of the review request. Oops, missed that. > Basically that pattern has an "if (x==NULL) return". If you don't > have that "if" then the compiler would have objected to that too ! I'm not sure I undestand this. I mean why not rewrite the macro like this: #define FREE_AND_RETURN_STATUS \ if (pbuff != buff) mlib_free(pbuff); \ if (k != akernel) mlib_free(k); \ return status #endif /* FREE_AND_RETURN_STATUS */ Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; but all its usages are separate statements. Vadim >> >> Thanks, >> Vadim >> >> On 29.07.2016 2:31, Philip Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>> >>> Here's a sampling of the warnings that I think covers most, maybe >>> all, of the cases >>> LINUX >>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses around >>> '-' in operand of '&' [-Werror=parentheses] >>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT >>> + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>> ^ >>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses around >>> '-' in operand of '&' [-Werror=parentheses] >>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> (MLIB_SHIFT >>> + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>> >>> ----------------- >>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>> assignment used as truth value [-Werror=parentheses] >>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>> ^ >>> - >>> MAC ... >>> >>> mlib_c_ImageCopy.c:331:5: error: using the result of an assignment >>> as a condition without parentheses [-Werror,-Wparentheses] >>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>> if (j = w & 1) \ >>> ~~^~~~~~~ >>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>> assignment to silence this warning\ >>> >>> --- >>> >>> >>> --- >>> SOLARIS >>> mlib_ImageConv_16ext.c", line 532: statement not reached >>> (E_STATEMENT_NOT_REACHED) >>> >>> This last one was not nice just the ";" was considered a statement >>> after the {XX; YY; return Z} macro expansion >>> and turning into "do { {....} } while (0)" did not help since >>> then it said "loop terminator not reached - other cases we have >>> like this have at least a condition in the macro. >>> >>> -phil. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 29 14:30:29 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 29 Jul 2016 07:30:29 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> Message-ID: <579B6885.6070706@oracle.com> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: > On 29.07.2016 16:28, Philip Race wrote: >> >> >> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>> Phil, >>> >>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >> >> Ah, yes. Not just disable them >>> >>> Do you think it's worth it to rewrite these assignments as separate >>> assignment and a condition? >>> Especially long ones with a lot of parentheses? >>> Like this one, instead of >>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>> >>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>> if (j != 0) { >> >> I don't know. Where would I stop ? > > Where it doesn't feel weird anymore? > For example, is this line correct? > if (j = (((mlib_addr) pdst_row & 2) != 0)) { > It seems very weird for me that we assign a boolean value to the loop > variable. > It looks like there's an error in parentheses and it should instead > look like: > if ((j = (((mlib_addr) pdst_row & 2) != 0) { > Yeah, in this particular case it doesn't even matter but still > assignments in conditions can very easily lead to errors. OK I will take a *limited* look at this. > >> >>> >>> Also seeing macro calls without a semicolon is weird. >>> I don't see any need in parentheses in the definition of >>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it without >>> trailing semicolon? >> >> I anticipated the question and it is already addressed in my last >> paragraph right at the very bottom of the review request. > > Oops, missed that. > >> Basically that pattern has an "if (x==NULL) return". If you don't >> have that "if" then the compiler would have objected to that too ! > > I'm not sure I undestand this. I mean I without the condition the compiler can tell you *never* reach the while (0) and so objected on those grounds. I tried this. > > I mean why not rewrite the macro like this: > #define FREE_AND_RETURN_STATUS \ > if (pbuff != buff) mlib_free(pbuff); \ > if (k != akernel) mlib_free(k); \ > return status > #endif /* FREE_AND_RETURN_STATUS */ > > Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; but all > its usages are separate statements. hmm .. I suppose could .. but not pretty either. Also if going that route it could be #define FREE_AND_RETURN_STATUS \ { \ if (pbuff != buff) mlib_free(pbuff); \ if (k != akernel) mlib_free(k); \ } \ return status #endif /* FREE_AND_RETURN_STATUS */ ?? -phil. > > Vadim > >>> >>> Thanks, >>> Vadim >>> >>> On 29.07.2016 2:31, Philip Race wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>> >>>> Here's a sampling of the warnings that I think covers most, maybe >>>> all, of the cases >>>> LINUX >>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses around >>>> '-' in operand of '&' [-Werror=parentheses] >>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>> >>>> ^ >>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses around >>>> '-' in operand of '&' [-Werror=parentheses] >>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>> >>>> ----------------- >>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>> assignment used as truth value [-Werror=parentheses] >>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>> ^ >>>> - >>>> MAC ... >>>> >>>> mlib_c_ImageCopy.c:331:5: error: using the result of an assignment >>>> as a condition without parentheses [-Werror,-Wparentheses] >>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>> if (j = w & 1) \ >>>> ~~^~~~~~~ >>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>> assignment to silence this warning\ >>>> >>>> --- >>>> >>>> >>>> --- >>>> SOLARIS >>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>> (E_STATEMENT_NOT_REACHED) >>>> >>>> This last one was not nice just the ";" was considered a statement >>>> after the {XX; YY; return Z} macro expansion >>>> and turning into "do { {....} } while (0)" did not help since >>>> then it said "loop terminator not reached - other cases we have >>>> like this have at least a condition in the macro. >>>> >>>> -phil. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Fri Jul 29 14:35:44 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 29 Jul 2016 17:35:44 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <579B6885.6070706@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> Message-ID: <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> On 29.07.2016 17:30, Philip Race wrote: > > > On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >> On 29.07.2016 16:28, Philip Race wrote: >>> >>> >>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>> Phil, >>>> >>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>> >>> Ah, yes. Not just disable them >>>> >>>> Do you think it's worth it to rewrite these assignments as separate >>>> assignment and a condition? >>>> Especially long ones with a lot of parentheses? >>>> Like this one, instead of >>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>> >>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>> if (j != 0) { >>> >>> I don't know. Where would I stop ? >> >> Where it doesn't feel weird anymore? >> For example, is this line correct? >> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >> It seems very weird for me that we assign a boolean value to the loop >> variable. >> It looks like there's an error in parentheses and it should instead >> look like: >> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >> Yeah, in this particular case it doesn't even matter but still >> assignments in conditions can very easily lead to errors. > > OK I will take a *limited* look at this. Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >> >>> >>>> >>>> Also seeing macro calls without a semicolon is weird. >>>> I don't see any need in parentheses in the definition of >>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it without >>>> trailing semicolon? >>> >>> I anticipated the question and it is already addressed in my last >>> paragraph right at the very bottom of the review request. >> >> Oops, missed that. >> >>> Basically that pattern has an "if (x==NULL) return". If you don't >>> have that "if" then the compiler would have objected to that too ! >> >> I'm not sure I undestand this. > > I mean I without the condition the compiler can tell you *never* reach > the while (0) and so objected on those grounds. I tried this. Got it. >> >> I mean why not rewrite the macro like this: >> #define FREE_AND_RETURN_STATUS \ >> if (pbuff != buff) mlib_free(pbuff); \ >> if (k != akernel) mlib_free(k); \ >> return status >> #endif /* FREE_AND_RETURN_STATUS */ >> >> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; but >> all its usages are separate statements. > > hmm .. I suppose could .. but not pretty either. > Also if going that route it could be > > #define FREE_AND_RETURN_STATUS \ > { \ > if (pbuff != buff) mlib_free(pbuff); \ > if (k != akernel) mlib_free(k); \ > } \ > return status > #endif /* FREE_AND_RETURN_STATUS */ > > ?? What's the point of parentheses here? I thought that the whole point of curly braces and do .... while(0) stuff was to enable the macro calls in conditions like if (foo) CALL_MACRO; without the curly braces around CALL_MACRO. But if you put curly braces around only part of the macro definition this would be broken anyway. Vadim > > -phil. >> >> Vadim >> >>>> >>>> Thanks, >>>> Vadim >>>> >>>> On 29.07.2016 2:31, Philip Race wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>> >>>>> Here's a sampling of the warnings that I think covers most, maybe >>>>> all, of the cases >>>>> LINUX >>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses around >>>>> '-' in operand of '&' [-Werror=parentheses] >>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>> ^ >>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>> >>>>> ----------------- >>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>> assignment used as truth value [-Werror=parentheses] >>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>> ^ >>>>> - >>>>> MAC ... >>>>> >>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an assignment >>>>> as a condition without parentheses [-Werror,-Wparentheses] >>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>> if (j = w & 1) \ >>>>> ~~^~~~~~~ >>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>> assignment to silence this warning\ >>>>> >>>>> --- >>>>> >>>>> >>>>> --- >>>>> SOLARIS >>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>> (E_STATEMENT_NOT_REACHED) >>>>> >>>>> This last one was not nice just the ";" was considered a statement >>>>> after the {XX; YY; return Z} macro expansion >>>>> and turning into "do { {....} } while (0)" did not help since >>>>> then it said "loop terminator not reached - other cases we have >>>>> like this have at least a condition in the macro. >>>>> >>>>> -phil. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sat Jul 30 03:49:04 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 29 Jul 2016 20:49:04 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> Message-ID: <579C23B0.2030301@oracle.com> See http://cr.openjdk.java.net/~prr/8074843.1/ Also passes JPRT -phil. On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: > On 29.07.2016 17:30, Philip Race wrote: >> >> >> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>> On 29.07.2016 16:28, Philip Race wrote: >>>> >>>> >>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>> Phil, >>>>> >>>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>>> >>>> Ah, yes. Not just disable them >>>>> >>>>> Do you think it's worth it to rewrite these assignments as >>>>> separate assignment and a condition? >>>>> Especially long ones with a lot of parentheses? >>>>> Like this one, instead of >>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>> >>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>> if (j != 0) { >>>> >>>> I don't know. Where would I stop ? >>> >>> Where it doesn't feel weird anymore? >>> For example, is this line correct? >>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>> It seems very weird for me that we assign a boolean value to the >>> loop variable. >>> It looks like there's an error in parentheses and it should instead >>> look like: >>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>> Yeah, in this particular case it doesn't even matter but still >>> assignments in conditions can very easily lead to errors. >> >> OK I will take a *limited* look at this. > > Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c > >>> >>>> >>>>> >>>>> Also seeing macro calls without a semicolon is weird. >>>>> I don't see any need in parentheses in the definition of >>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>> without trailing semicolon? >>>> >>>> I anticipated the question and it is already addressed in my last >>>> paragraph right at the very bottom of the review request. >>> >>> Oops, missed that. >>> >>>> Basically that pattern has an "if (x==NULL) return". If you don't >>>> have that "if" then the compiler would have objected to that too ! >>> >>> I'm not sure I undestand this. >> >> I mean I without the condition the compiler can tell you *never* reach >> the while (0) and so objected on those grounds. I tried this. > > Got it. > >>> >>> I mean why not rewrite the macro like this: >>> #define FREE_AND_RETURN_STATUS \ >>> if (pbuff != buff) mlib_free(pbuff); \ >>> if (k != akernel) mlib_free(k); \ >>> return status >>> #endif /* FREE_AND_RETURN_STATUS */ >>> >>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; but >>> all its usages are separate statements. >> >> hmm .. I suppose could .. but not pretty either. >> Also if going that route it could be >> >> #define FREE_AND_RETURN_STATUS \ >> { \ >> if (pbuff != buff) mlib_free(pbuff); \ >> if (k != akernel) mlib_free(k); \ >> } \ >> return status >> #endif /* FREE_AND_RETURN_STATUS */ >> >> ?? > > What's the point of parentheses here? > I thought that the whole point of curly braces and do .... while(0) > stuff was to enable the macro calls in conditions like if (foo) > CALL_MACRO; without the curly braces around CALL_MACRO. > But if you put curly braces around only part of the macro definition > this would be broken anyway. > > Vadim > >> >> -phil. >>> >>> Vadim >>> >>>>> >>>>> Thanks, >>>>> Vadim >>>>> >>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>> >>>>>> Here's a sampling of the warnings that I think covers most, maybe >>>>>> all, of the cases >>>>>> LINUX >>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>> >>>>>> ^ >>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>>> >>>>>> ----------------- >>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>> assignment used as truth value [-Werror=parentheses] >>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>> ^ >>>>>> - >>>>>> MAC ... >>>>>> >>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>> assignment as a condition without parentheses [-Werror,-Wparentheses] >>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>> if (j = w & 1) \ >>>>>> ~~^~~~~~~ >>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>> assignment to silence this warning\ >>>>>> >>>>>> --- >>>>>> >>>>>> >>>>>> --- >>>>>> SOLARIS >>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>> (E_STATEMENT_NOT_REACHED) >>>>>> >>>>>> This last one was not nice just the ";" was considered a statement >>>>>> after the {XX; YY; return Z} macro expansion >>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>> then it said "loop terminator not reached - other cases we have >>>>>> like this have at least a condition in the macro. >>>>>> >>>>>> -phil. >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Sat Jul 30 05:13:45 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sat, 30 Jul 2016 08:13:45 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <579C23B0.2030301@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> Message-ID: Looks good! Vadim On 30.07.2016 6:49, Philip Race wrote: > See http://cr.openjdk.java.net/~prr/8074843.1/ > > Also passes JPRT > > -phil. > > On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >> On 29.07.2016 17:30, Philip Race wrote: >>> >>> >>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>> On 29.07.2016 16:28, Philip Race wrote: >>>>> >>>>> >>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>> Phil, >>>>>> >>>>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>>>> >>>>> Ah, yes. Not just disable them >>>>>> >>>>>> Do you think it's worth it to rewrite these assignments as >>>>>> separate assignment and a condition? >>>>>> Especially long ones with a lot of parentheses? >>>>>> Like this one, instead of >>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>> >>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>> if (j != 0) { >>>>> >>>>> I don't know. Where would I stop ? >>>> >>>> Where it doesn't feel weird anymore? >>>> For example, is this line correct? >>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>> It seems very weird for me that we assign a boolean value to the >>>> loop variable. >>>> It looks like there's an error in parentheses and it should instead >>>> look like: >>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>> Yeah, in this particular case it doesn't even matter but still >>>> assignments in conditions can very easily lead to errors. >>> >>> OK I will take a *limited* look at this. >> >> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >> >>>> >>>>> >>>>>> >>>>>> Also seeing macro calls without a semicolon is weird. >>>>>> I don't see any need in parentheses in the definition of >>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>> without trailing semicolon? >>>>> >>>>> I anticipated the question and it is already addressed in my last >>>>> paragraph right at the very bottom of the review request. >>>> >>>> Oops, missed that. >>>> >>>>> Basically that pattern has an "if (x==NULL) return". If you don't >>>>> have that "if" then the compiler would have objected to that too ! >>>> >>>> I'm not sure I undestand this. >>> >>> I mean I without the condition the compiler can tell you *never* reach >>> the while (0) and so objected on those grounds. I tried this. >> >> Got it. >> >>>> >>>> I mean why not rewrite the macro like this: >>>> #define FREE_AND_RETURN_STATUS \ >>>> if (pbuff != buff) mlib_free(pbuff); \ >>>> if (k != akernel) mlib_free(k); \ >>>> return status >>>> #endif /* FREE_AND_RETURN_STATUS */ >>>> >>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; but >>>> all its usages are separate statements. >>> >>> hmm .. I suppose could .. but not pretty either. >>> Also if going that route it could be >>> >>> #define FREE_AND_RETURN_STATUS \ >>> { \ >>> if (pbuff != buff) mlib_free(pbuff); \ >>> if (k != akernel) mlib_free(k); \ >>> } \ >>> return status >>> #endif /* FREE_AND_RETURN_STATUS */ >>> >>> ?? >> >> What's the point of parentheses here? >> I thought that the whole point of curly braces and do .... while(0) >> stuff was to enable the macro calls in conditions like if (foo) >> CALL_MACRO; without the curly braces around CALL_MACRO. >> But if you put curly braces around only part of the macro definition >> this would be broken anyway. >> >> Vadim >> >>> >>> -phil. >>>> >>>> Vadim >>>> >>>>>> >>>>>> Thanks, >>>>>> Vadim >>>>>> >>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>> >>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>> maybe all, of the cases >>>>>>> LINUX >>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>> ^ >>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>>>> >>>>>>> ----------------- >>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>> ^ >>>>>>> - >>>>>>> MAC ... >>>>>>> >>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>> assignment as a condition without parentheses >>>>>>> [-Werror,-Wparentheses] >>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>> if (j = w & 1) \ >>>>>>> ~~^~~~~~~ >>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>> assignment to silence this warning\ >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> SOLARIS >>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>> >>>>>>> This last one was not nice just the ";" was considered a statement >>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>> then it said "loop terminator not reached - other cases we have >>>>>>> like this have at least a condition in the macro. >>>>>>> >>>>>>> -phil. >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: