From alexey.ushakov at jetbrains.com Tue Sep 1 10:01:49 2020 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Tue, 1 Sep 2020 13:01:49 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8252133 The java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal pipeline is active In-Reply-To: <1d397660-e7b1-c222-86dd-d79a91552a96@oracle.com> References: <759cf878-1595-7a10-87d1-92d3f425b445@oracle.com> <8BDF72CA-ACA7-4BD1-B37B-52B80ABFFD6F@oracle.com> <1d397660-e7b1-c222-86dd-d79a91552a96@oracle.com> Message-ID: <7C2E996A-EE57-4A84-B10C-ECB58B30198B@jetbrains.com> Hi Sergey, The fix looks good for me. Looking forward to your pull request. Best Regards, Alexey > On 30 Aug 2020, at 03:45, Sergey Bylokhov wrote: > > On 29.08.2020 17:39, Phil Race wrote: >> Sergey, >> The priority now is to flush outstanding review requests ahead of the skara transition. I should have made that clearer in my email but I think new requests such as this will need to wait. Especially anything that requires some deep thought by a reviewer as we have just one working day left. > > It is not a big deal to convert such a request to the PR. So I will work to > the usual rhythm and convert all review requests to PR once we moved to the github. > >> -Phil. >>> On Aug 29, 2020, at 5:29 PM, Sergey Bylokhov wrote: >>> >>> ?Hello. >>> Please review the fix for jdk/client. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252133 >>> Fix: http://cr.openjdk.java.net/~serb/8252133/webrev.00 >>> >>> This bug easily reproduced by the test in question on the dual video card systems >>> when the metal pipeline is active. But it is possible to reproduce it in the OGL >>> pipeline as well, but it is required some additional steps. >>> >>> >>> Problem description: >>> Our CGraphicsEnvironment maintains the list of active graphics devices. The one >>> important feature of this CGraphicsEnvironment is to invalidate the old devices and >>> map them to the new devices. For example, if the user got a reference to the device, >>> and this device was removed then this reference will refer to the main screen. >>> >>> The problem in the current implementation arise when the system has two video cards: >>> 1 The user get some GraphicsDevice >>> 2 The user sets the full-screen window for this device >>> 3 The user change screen resolution for this device >>> 4 The resolution of the screen is not changed ->> BUG. >>> >>> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided >>> to switch to the discrete video card, but it does not report the old device(integrated VC) >>> as removed, because actually no screens were removed. >>> >>> Since it was not reported as removed we did not invalidate it and did not map it to the >>> new device ->> request to change the screen resolution at step 3 send to some non existed >>> deviceID. >>> >>> As a fix I suggest to change this logic: >>> - Invalidate devices reported by macOS as removed >>> - Initialize the main screen >>> - Initialize all NEW screens >>> >>> To this logic: >>> - Ignore devices reported by the macOS as removed >>> - Initialize the main screen >>> - Initialize all NEW screens >>> - Check that the main device is in the list of all NEW devices >>> - Invalidate all OLD devices which are not in the list of NEW devices >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Tue Sep 1 10:42:49 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 1 Sep 2020 16:12:49 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8171303 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: References: <5F4589D6.6020004@oracle.com> Message-ID: > On 26-Aug-2020, at 5:05 AM, Sergey Bylokhov wrote: > > On 25.08.2020 14:59, Philip Race wrote: >> This is fine but >> 1) I like to see the bug under which you fixed it in the @bug list. > > It is not a product bug and the test isn't reworked, so it is not necessary to have this test fix in the list of bugs > >> 2) I am not sure I see how all the various reasons for this test failing can be explained by this. > > In the HiDPI mode the VolatileImage internally have twice more pixels than BufferedImage, so when we draw the data to > the VolatileImage and then scale it back to the size of the BufferedImage for comparison, the test fails. This looks good. I checked with OGL and Metal (project Lanai) on macOS. One question is - do we need to support this test in HiDPI mode? > >> -phil. >> On 8/25/20, 1:37 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk/client. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171303 >>> Fix: http://cr.openjdk.java.net/~serb/8171303/webrev.00 >>> >>> This the only test which was created to check different types of interpolation. >>> It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. >>> But it does not take into account that rendering to the VolatileImage might be affected >>> by the HiDPI support. >>> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Sep 1 15:58:21 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 01 Sep 2020 08:58:21 -0700 Subject: [OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week In-Reply-To: <5F49448E.3020001@oracle.com> References: <5F49448E.3020001@oracle.com> Message-ID: <5F4E6F9D.9000404@oracle.com> As per the notifiication last week, as of NOW there should be NO MORE pushes to the hg://openjdk.java.net/jdk/client forest. --- So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to jdk/client should be >> 9am PDT Tuesday 1st Sept 2020 << --- -phil. On 8/28/20, 10:53 AM, Philip Race wrote: > All, > > Contingent on Project Skara (ie mercurial ->git / githib) going active > for the JDK project on schedule > on 5th September, we intend to retire the jdk/client repo/forest as > part of this transition. > > In other words, once mercurial is shut down and we move to git there > will ONLY be the main JDK repo > and all client pushes will go there. > > We will be making some internal testing changes which we hope will > help us spot any breakages > that pushes cause in time to prevent them making their way directly > into a promoted build but they > can't completely replace the manual testing we have been doing, so we > will also be > dependent on folks to be extra diligent from now on and not assume > there is a gatekeeper > who will spot their mistakes. > > But we do need some time to "flush" any last changes in client to jdk > before mercurial shuts down. > > So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to > jdk/client should be > >> 9am PDT Tuesday 1st Sept 2020 << > > Anything pushed after that time may be lost forever :-) > > We'll also further enforce this as of 9am PDT Wednesday 2nd Sept 2020 > by making the client repo > mercurial repo read-only. The 24 hours is to help the integrator/gate > keeper - not for your late pushes, > For example if there's a breakage we need to back out before > integrating we might need this. > So not even "doc" or "test" changes - nothing please ! > > You may reasonably ask why then Tue/Wed for this if skara is not > transitioning until Sat 5th September ? > The answer is that in an unfortunate coincidence of timing we have a > big lab move that begins around > 9am PT Wed 2nd September, and all our testing capabilities will be > off-line for several days. > So any test jobs submitted after sometime Tuesday won't have time > to complete, and the lab move won't be complete until after the skara > transition. > > Any outstanding reviews that don't make the cut-off will of course > have to be resubmitted as github pull requests > and any approvals they may have accumulated will need to be > re-approved. All of this is of course true for > folks pushing directly to the mercurial main JDK repo - it is not > related to the client repo retirement. > > -Phil > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Sep 2 05:16:56 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 1 Sep 2020 22:16:56 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8171303 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: References: <5F4589D6.6020004@oracle.com> Message-ID: On 01.09.2020 03:42, Ajit Ghaisas wrote: >> >> In the HiDPI mode the VolatileImage internally have twice more pixels than BufferedImage, so when we draw the data to >> the VolatileImage and then scale it back to the size of the BufferedImage for comparison, the test fails. > > This looks good. I checked with OGL and Metal (project Lanai) on macOS. > > One question is - do we need to support this test in HiDPI mode? The difference between HiDPI and non-HiDPI mode is that VolatileImage has more pixels and every draw operation use scaled blits. The test in question scales the graphics ourselves. To eliminate the "sun.java2d.uiScale=1" we will need to apply the scale to the BufferedImage size, then we should skip the usage of "getSnapshot", and then we will need to scale all rendering to the BufferedImage(simulating the HiDPI in VolatileImage), but in the end, the same scaled blit will be tested. -- Best regards, Sergey. From philip.race at oracle.com Wed Sep 2 16:53:11 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 02 Sep 2020 09:53:11 -0700 Subject: [OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week In-Reply-To: <5F4E6F9D.9000404@oracle.com> References: <5F49448E.3020001@oracle.com> <5F4E6F9D.9000404@oracle.com> Message-ID: <5F4FCDF7.6090300@oracle.com> The client mercurial repo is now read-only and retired. Also since all our test systems are going down right now for a lab move this means no pushes to jdk/jdk either please ! Wait until everything comes back on Monday as github at which point outstanding code reviews will need to be re-created as github pull requests. -phil. On 9/1/20, 8:58 AM, Philip Race wrote: > As per the notifiication last week, as of NOW there should be NO MORE > pushes to the hg://openjdk.java.net/jdk/client forest. > > --- > So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to > jdk/client should be > >> 9am PDT Tuesday 1st Sept 2020 << > --- > > -phil. > > On 8/28/20, 10:53 AM, Philip Race wrote: >> All, >> >> Contingent on Project Skara (ie mercurial ->git / githib) going >> active for the JDK project on schedule >> on 5th September, we intend to retire the jdk/client repo/forest as >> part of this transition. >> >> In other words, once mercurial is shut down and we move to git there >> will ONLY be the main JDK repo >> and all client pushes will go there. >> >> We will be making some internal testing changes which we hope will >> help us spot any breakages >> that pushes cause in time to prevent them making their way directly >> into a promoted build but they >> can't completely replace the manual testing we have been doing, so we >> will also be >> dependent on folks to be extra diligent from now on and not assume >> there is a gatekeeper >> who will spot their mistakes. >> >> But we do need some time to "flush" any last changes in client to jdk >> before mercurial shuts down. >> >> So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to >> jdk/client should be >> >> 9am PDT Tuesday 1st Sept 2020 << >> >> Anything pushed after that time may be lost forever :-) >> >> We'll also further enforce this as of 9am PDT Wednesday 2nd Sept >> 2020 by making the client repo >> mercurial repo read-only. The 24 hours is to help the integrator/gate >> keeper - not for your late pushes, >> For example if there's a breakage we need to back out before >> integrating we might need this. >> So not even "doc" or "test" changes - nothing please ! >> >> You may reasonably ask why then Tue/Wed for this if skara is not >> transitioning until Sat 5th September ? >> The answer is that in an unfortunate coincidence of timing we have a >> big lab move that begins around >> 9am PT Wed 2nd September, and all our testing capabilities will be >> off-line for several days. >> So any test jobs submitted after sometime Tuesday won't have time >> to complete, and the lab move won't be complete until after the skara >> transition. >> >> Any outstanding reviews that don't make the cut-off will of course >> have to be resubmitted as github pull requests >> and any approvals they may have accumulated will need to be >> re-approved. All of this is of course true for >> folks pushing directly to the mercurial main JDK repo - it is not >> related to the client repo retirement. >> >> -Phil >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Sep 3 09:08:37 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 3 Sep 2020 14:38:37 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8171303 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: References: <5F4589D6.6020004@oracle.com> Message-ID: <78285B3F-449D-4B61-8580-D30C9D88A550@oracle.com> > On 02-Sep-2020, at 10:46 AM, Sergey Bylokhov wrote: > > On 01.09.2020 03:42, Ajit Ghaisas wrote: >>> >>> In the HiDPI mode the VolatileImage internally have twice more pixels than BufferedImage, so when we draw the data to >>> the VolatileImage and then scale it back to the size of the BufferedImage for comparison, the test fails. >> This looks good. I checked with OGL and Metal (project Lanai) on macOS. >> One question is - do we need to support this test in HiDPI mode? > > The difference between HiDPI and non-HiDPI mode is that VolatileImage has more > pixels and every draw operation use scaled blits. The test in question scales > the graphics ourselves. To eliminate the "sun.java2d.uiScale=1" we will need to > apply the scale to the BufferedImage size, then we should skip the usage of > "getSnapshot", and then we will need to scale all rendering to the > BufferedImage(simulating the HiDPI in VolatileImage), but in the end, the same > scaled blit will be tested. OK. Thanks for the explanation. Test fix looks good. +1. (not a ?R? reviewer) Regards, Ajit > -- > Best regards, Sergey. From serb at openjdk.java.net Sat Sep 5 21:38:03 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 5 Sep 2020 21:38:03 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252817: Cleanup the classes in the java.awt.color package Message-ID: - Class declarations reformat - Docs cleanup ------------- Commit messages: - 8252817: Cleanup the classes in the java.awt.color package Changes: https://git.openjdk.java.net/jdk/pull/22/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=22&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252817 Stats: 142 lines in 7 files changed: 14 ins; 6 del; 122 mod Patch: https://git.openjdk.java.net/jdk/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/22/head:pull/22 PR: https://git.openjdk.java.net/jdk/pull/22 From serb at openjdk.java.net Sat Sep 5 21:38:06 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 5 Sep 2020 21:38:06 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252817: Cleanup the classes in the java.awt.color package In-Reply-To: References: Message-ID: On Sat, 5 Sep 2020 21:32:42 GMT, Sergey Bylokhov wrote: > - Class declarations reformat > - Docs cleanup src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 148: > 146: */ > 147: public static final int icSigXYZData = 0x58595A20; > 148: Inline comment: Looks like this type of documentation was used before we added javadoc for each constant. ------------- PR: https://git.openjdk.java.net/jdk/pull/22 From conor.cleary at oracle.com Tue Sep 8 09:34:20 2020 From: conor.cleary at oracle.com (Conor Cleary) Date: Tue, 8 Sep 2020 10:34:20 +0100 Subject: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs' In-Reply-To: <5F4D5A6A.90009@oracle.com> References: <891419e0-22aa-f9ff-ca93-5796a55819ac@oracle.com> <5F4D5A6A.90009@oracle.com> Message-ID: <8f152117-1563-77e6-a29a-fce090b65855@oracle.com> Hi everyone. Thanks for the feedback! Firstly, I changed the wording from 'Creates' to 'Constructs' as per Philip's suggestion (and corrected a spelling mistake). Secondly, for the protected constructors (in the abstract classes) I used the wording "Constructor for subclasses to call." as that seems to be the norm now. * webrev: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/ * specdiff: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/specdiff/overview-summary.html * CSR: https://bugs.openjdk.java.net/browse/JDK-8252495 * bug: https://bugs.openjdk.java.net/browse/JDK-8250859 Regards, Conor On 31/08/2020 21:15, Philip Race wrote: > Right we have started to be consistent using "Constructor for > subclasses to call": > > Also I prefer constructs over creates, even for the concrete classes, > eg this : > + > +??? /** > +???? * Creates an {@code ImageFilter}. > +???? */ > +??? public ImageFilter() {} > + > > should be "Constructs an {@code ImageFilter}" > > -phil. > > On 8/28/20, 5:29 PM, Sergey Bylokhov wrote: >> Hi, Conor. >> >> Please use such spec for the protected constructor: "Constructor for >> subclasses to call": >> https://cr.openjdk.java.net/~psadhukhan/8250850/webrev.1/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java.sdiff.html >> >> >> Actually the current text is also fine to me, but looks like many >> people use the text above as a description. >> >> On 28.08.2020 01:28, Conor Cleary wrote: >>> Hello all, >>> >>> Could someone please review my changes for JDK-8250855, 'Address >>> reliance on default constructors in the Java 2D APIs'? This issue >>> relates to JDK-8250639 '? Address reliance on default constructors >>> in the java.desktop module'. The changes address the reliance on >>> default constructors by adding in basic constructors in the >>> following classes: >>> >>> ? * java.awt.Image >>> ? * java.awt.PrintJob >>> ? * java.awt.font.GlyphVector >>> ? * java.awt.font.LayoutPath >>> ? * java.awt.font.LineMetrics >>> ? * java.awt.image.AbstractMultiResolutionImage >>> ? * java.awt.image.BufferStrategy >>> ? * java.awt.image.ImageFilter >>> ? * java.awt.image.RGBImageFilter >>> ? * java.awt.image.VolatileImage >>> ? * javax.print.PrintServiceLookup >>> ? * javax.print.ServiceUI >>> ? * javax.print.ServiceUIFactory >>> ? * javax.print.StreamPrintServiceFactory >>> ? * javax.print.event.PrintJobAdapter >>> >>> A key issue is the accompanying description for each of the added >>> constructors and is probably the feedback I would value most as it >>> has been a point of discussion previously. I have included a >>> specdiff to easily view the changes observed in the api >>> documentation. Currently drafting a CSR for these changes. >>> >>> ? * webrev: >>> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/ >>> ? * specdiff: >>> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/specdiff/overview-summary.html >>> ? * bug: https://bugs.openjdk.java.net/browse/JDK-8250855 >>> >>> Best Regards, >>> >>> -Conor >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.java.net Tue Sep 8 21:22:26 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 8 Sep 2020 21:22:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 7183828: Invalid Image Variant when using anything other than BufferedImage Message-ID: It is intended that our draw machinery works only on specific image formats that we know we support. But the user still able to create some image subclasses for their purpose and according to our spec of Graphics2D.drawImage() we should not throw any exceptions. I suggest handling this situation in a similar way as we handle some errors during rendering when the pipeline is in the wrong state, or the ToolkitImage is not loaded yet, just ignore the request and return false. All our pipelines have a special meaning of InvalidPipeException, if the pipeline found that it cannot complete the draw operation throws this exception which is handled by all methods in the SunGraphics2D class. So as a fix I suggest changing the IllegalArgumentException to the InvalidPipeException. Also, we need to add a try/catch block to the drawHiDPIImage(it uses the SurfaceManager.getManager method directly) Old review request: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010995.html ------------- Commit messages: - 7183828: Invalid Image Variant when using anything other than BufferedImage Changes: https://git.openjdk.java.net/jdk/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7183828 Stats: 413 lines in 3 files changed: 268 ins; 100 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk/pull/85 From serb at openjdk.java.net Tue Sep 8 22:01:05 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 8 Sep 2020 22:01:05 GMT Subject: [OpenJDK 2D-Dev] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux Message-ID: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> This the only test which was created to check different types of interpolation. It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. But it does not take into account that rendering to the VolatileImage might be affected by the HiDPI support. Old review request: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010982.html ------------- Commit messages: - 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux Changes: https://git.openjdk.java.net/jdk/pull/86/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=86&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8171303 Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/86/head:pull/86 PR: https://git.openjdk.java.net/jdk/pull/86 From prr at openjdk.java.net Tue Sep 8 22:10:43 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 8 Sep 2020 22:10:43 GMT Subject: [OpenJDK 2D-Dev] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> References: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> Message-ID: On Tue, 8 Sep 2020 21:54:43 GMT, Sergey Bylokhov wrote: > This the only test which was created to check different types of interpolation. > It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. > But it does not take into account that rendering to the VolatileImage might be affected > by the HiDPI support. > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010982.html Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/86 From jdv at openjdk.java.net Wed Sep 9 05:50:33 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 9 Sep 2020 05:50:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252817: Cleanup the classes in the java.awt.color package In-Reply-To: References: Message-ID: <0XIEmkCmBhuZinlfVDdc0bExMUsUhNB0jw_AbQN6gKw=.0943db2a-2c1b-48d3-a2ba-8f535e73885f@github.com> On Sat, 5 Sep 2020 21:32:42 GMT, Sergey Bylokhov wrote: > - Class declarations reformat > - Docs cleanup Looks good to me. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/22 From pbansal at openjdk.java.net Wed Sep 9 06:24:53 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 9 Sep 2020 06:24:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252817: Cleanup the classes in the java.awt.color package In-Reply-To: References: Message-ID: On Sat, 5 Sep 2020 21:32:42 GMT, Sergey Bylokhov wrote: > - Class declarations reformat > - Docs cleanup +1 ------------- Marked as reviewed by pbansal (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/22 From psadhukhan at openjdk.java.net Wed Sep 9 12:23:46 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 9 Sep 2020 12:23:46 GMT Subject: [OpenJDK 2D-Dev] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> References: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> Message-ID: On Tue, 8 Sep 2020 21:54:43 GMT, Sergey Bylokhov wrote: > This the only test which was created to check different types of interpolation. > It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. > But it does not take into account that rendering to the VolatileImage might be affected > by the HiDPI support. > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010982.html Looks ok albeit with author change in the test. test/jdk/sun/java2d/pipe/InterpolationQualityTest.java line 31: > 29: * image via rendering hints for default, xrender and opengl pipelines. > 30: * > 31: * @author Vadim.Pakhnushev at oracle.com I think we are supposed to remove the author, if present historically, if we are making changes to any test. rest looks ok. ------------- Marked as reviewed by psadhukhan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/86 From prr at openjdk.java.net Wed Sep 9 16:52:43 2020 From: prr at openjdk.java.net (Phil Race) Date: Wed, 9 Sep 2020 16:52:43 GMT Subject: [OpenJDK 2D-Dev] RFR: 7183828: Invalid Image Variant when using anything other than BufferedImage In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 21:16:10 GMT, Sergey Bylokhov wrote: > It is intended that our draw machinery works only on specific image formats that we know we support. > But the user still able to create some image subclasses for their purpose and according to our spec of > Graphics2D.drawImage() we should not throw any exceptions. > > I suggest handling this situation in a similar way as we handle some errors during rendering when > the pipeline is in the wrong state, or the ToolkitImage is not loaded yet, just ignore the request and > return false. > > All our pipelines have a special meaning of InvalidPipeException, if the pipeline found that it cannot complete the draw > operation throws this exception which is handled by all methods in the SunGraphics2D class. > > So as a fix I suggest changing the IllegalArgumentException to the InvalidPipeException. > Also, we need to add a try/catch block to the drawHiDPIImage(it uses the SurfaceManager.getManager method directly) > > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010995.html I have very mixed feelings about this whole idea. InvalidPipeException is being co-opted for a different purpose. The user no longer gets a clear message that their image type isn't supported. Is there any specification we can point to ? ------------- PR: https://git.openjdk.java.net/jdk/pull/85 From kcr at openjdk.java.net Wed Sep 9 22:13:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Sep 2020 22:13:15 GMT Subject: [OpenJDK 2D-Dev] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> References: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> Message-ID: On Tue, 8 Sep 2020 21:54:43 GMT, Sergey Bylokhov wrote: > This the only test which was created to check different types of interpolation. > It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. > But it does not take into account that rendering to the VolatileImage might be affected > by the HiDPI support. > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010982.html Marked as reviewed by kcr (no project role). ------------- PR: https://git.openjdk.java.net/jdk/pull/86 From serb at openjdk.java.net Wed Sep 9 22:42:14 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 9 Sep 2020 22:42:14 GMT Subject: [OpenJDK 2D-Dev] RFR: 7183828: Invalid Image Variant when using anything other than BufferedImage In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 16:50:22 GMT, Phil Race wrote: > I have very mixed feelings about this whole idea. > InvalidPipeException is being co-opted for a different purpose. We already use this exception in such cases, and I think it is intended for this: https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/opengl/OGLMaskFill.java#L75 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/NullSurfaceData.java#L92 > The user no longer gets a clear message that their image type isn't supported. > Is there any specification we can point to ? The spec for the Image class: > * The abstract class {@code Image} is the superclass of all > * classes that represent graphical images. The image must be > * obtained in a platform-specific manner. https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/Image.java#L40 Or the spec for the VolatileImage > * This image should not be subclassed directly but should be created > * by using the {@link java.awt.Component#createVolatileImage(int, int) > * Component.createVolatileImage} or > * {@link java.awt.GraphicsConfiguration#createCompatibleVolatileImage(int, int) > * GraphicsConfiguration.createCompatibleVolatileImage(int, int)} methods. https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/VolatileImage.java#L74 ------------- PR: https://git.openjdk.java.net/jdk/pull/85 From prr at openjdk.java.net Wed Sep 9 22:51:24 2020 From: prr at openjdk.java.net (Phil Race) Date: Wed, 9 Sep 2020 22:51:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 7183828: Invalid Image Variant when using anything other than BufferedImage In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 21:16:10 GMT, Sergey Bylokhov wrote: > It is intended that our draw machinery works only on specific image formats that we know we support. > But the user still able to create some image subclasses for their purpose and according to our spec of > Graphics2D.drawImage() we should not throw any exceptions. > > I suggest handling this situation in a similar way as we handle some errors during rendering when > the pipeline is in the wrong state, or the ToolkitImage is not loaded yet, just ignore the request and > return false. > > All our pipelines have a special meaning of InvalidPipeException, if the pipeline found that it cannot complete the draw > operation throws this exception which is handled by all methods in the SunGraphics2D class. > > So as a fix I suggest changing the IllegalArgumentException to the InvalidPipeException. > Also, we need to add a try/catch block to the drawHiDPIImage(it uses the SurfaceManager.getManager method directly) > > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010995.html Ok. Fair enough. Please copy those spec. excerpts into the bug report. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/85 From serb at openjdk.java.net Wed Sep 9 23:17:21 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 9 Sep 2020 23:17:21 GMT Subject: [OpenJDK 2D-Dev] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux [v2] In-Reply-To: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> References: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> Message-ID: > This the only test which was created to check different types of interpolation. > It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. > But it does not take into account that rendering to the VolatileImage might be affected > by the HiDPI support. > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010982.html Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: @author tag is removed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/86/files - new: https://git.openjdk.java.net/jdk/pull/86/files/2e6a0251..99235829 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=86&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=86&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/86/head:pull/86 PR: https://git.openjdk.java.net/jdk/pull/86 From kcr at openjdk.java.net Wed Sep 9 23:20:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Sep 2020 23:20:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux [v2] In-Reply-To: References: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> Message-ID: On Wed, 9 Sep 2020 23:17:21 GMT, Sergey Bylokhov wrote: >> This the only test which was created to check different types of interpolation. >> It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. >> But it does not take into account that rendering to the VolatileImage might be affected >> by the HiDPI support. >> >> Old review request: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010982.html > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > @author tag is removed Marked as reviewed by kcr (no project role). ------------- PR: https://git.openjdk.java.net/jdk/pull/86 From github.com+2210496+thatsIch at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+2210496+thatsIch at openjdk.java.net (thatsIch) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). @doom369 jcheck requires an associated issue ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:21 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:21 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: replace all String.equals("") usages with String.isEmpty() Message-ID: **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). ------------- Commit messages: - Merge branch 'master' of https://github.com/doom369/jdk into reaplce_equals_with_is_empty - revert change in classes that maintain jdk 1.4 compatibility - Improvement: replace all occurrences of the .equals("") usages with .isEmpty() Changes: https://git.openjdk.java.net/jdk/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252999 Stats: 234 lines in 150 files changed: 0 ins; 0 del; 234 mod Patch: https://git.openjdk.java.net/jdk/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 08:52:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy wrote: >> @doom369 jcheck requires an associated issue > > @mrserb hello. Thanks for the review. Any further actions required from me? Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you should expect a longer review process, since someone from each functional area will need to look at the changes in their area (like @mrserb started to do for the `2d` area). ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 18:08:15 GMT, thatsIch wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > @doom369 jcheck requires an associated issue @mrserb hello. Thanks for the review. Any further actions required from me? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From serb at openjdk.java.net Thu Sep 10 08:52:29 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 08:52:29 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java line 187: > 185: String format = spi.getFormatNames()[0].toLowerCase(); > 186: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 187: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java line 146: > 144: String format = spi.getFormatNames()[0].toLowerCase(); > 145: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 146: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:26 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:21:44 GMT, Kevin Rushforth wrote: >> @mrserb hello. Thanks for the review. Any further actions required from me? > > Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a > Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement > request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once > you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing > "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you > should expect a longer review process, since someone from each functional area will need to look at the changes in > their area (like @mrserb started to do for the `2d` area). @kevinrushforth thanks. Done. Similar issues: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 could be joined somehow? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From alanb at openjdk.java.net Thu Sep 10 10:42:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 10:42:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement >> request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once >> you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing >> "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you >> should expect a longer review process, since someone from each functional area will need to look at the changes in >> their area (like @mrserb started to do for the `2d` area). > > @kevinrushforth thanks. Done. > > Similar issues: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 > > could be joined somehow? The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use JDK-8215014 rather than creating a new issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From dholmes at openjdk.java.net Thu Sep 10 11:24:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 11:24:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote: >> @kevinrushforth thanks. Done. >> >> Similar issues: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 >> >> could be joined somehow? > > The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do > the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more > more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code > (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan > code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use > JDK-8215014 rather than creating a new issue. This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 12:07:57 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 12:07:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. I have in mind dozens of improvements all over the code like this one. I already did some further review and in most cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 12:21:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 12:21:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. Maybe @AlanBateman or @jddarcy can offer some advice? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From dholmes at openjdk.java.net Thu Sep 10 13:56:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 13:56:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote: >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests > each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. > Maybe @AlanBateman or @jddarcy can offer some advice? 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will be delayed due to all of the mails being held up for moderator approval due to: " Too many recipients to the message" I have a longer email coming once it gets through the moderator approval delay. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From alanb at openjdk.java.net Thu Sep 10 15:53:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 15:53:05 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. >> Maybe @AlanBateman or @jddarcy can offer some advice? > > 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will > be delayed due to all of the mails being held up for moderator approval due to: > " Too many recipients to the message" > > I have a longer email coming once it gets through the moderator approval delay. :( Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should reduce the patch down to a manageable 24 or so files that should be trivial to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From jvernee at openjdk.java.net Thu Sep 10 16:40:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Sep 2020 16:40:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> Message-ID: On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote: >> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will >> be delayed due to all of the mails being held up for moderator approval due to: >> " Too many recipients to the message" >> >> I have a longer email coming once it gets through the moderator approval delay. :( > > Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests > or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from > the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should > reduce the patch down to a manageable 24 or so files that should be trivial to review. Since one of the motivations for this change is micro benchmark performance, please add a benchmark to the JDKs micro benchmark suite as well. (see e.g. https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang). Also, what testing has been done for these changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From serb at openjdk.java.net Thu Sep 10 19:29:32 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 19:29:32 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8252817: Cleanup the classes in the java.awt.color package In-Reply-To: References: Message-ID: On Sat, 5 Sep 2020 21:32:42 GMT, Sergey Bylokhov wrote: > - Class declarations reformat > - Docs cleanup This pull request has now been integrated. Changeset: ff21696b Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/ff21696b Stats: 142 lines in 7 files changed: 6 ins; 14 del; 122 mod 8252817: Cleanup the classes in the java.awt.color package Reviewed-by: jdv, pbansal ------------- PR: https://git.openjdk.java.net/jdk/pull/22 From serb at openjdk.java.net Thu Sep 10 21:30:58 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 21:30:58 GMT Subject: [OpenJDK 2D-Dev] Integrated: 7183828: Invalid Image Variant when using anything other than BufferedImage In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 21:16:10 GMT, Sergey Bylokhov wrote: > It is intended that our draw machinery works only on specific image formats that we know we support. > But the user still able to create some image subclasses for their purpose and according to our spec of > Graphics2D.drawImage() we should not throw any exceptions. > > I suggest handling this situation in a similar way as we handle some errors during rendering when > the pipeline is in the wrong state, or the ToolkitImage is not loaded yet, just ignore the request and > return false. > > All our pipelines have a special meaning of InvalidPipeException, if the pipeline found that it cannot complete the draw > operation throws this exception which is handled by all methods in the SunGraphics2D class. > > So as a fix I suggest changing the IllegalArgumentException to the InvalidPipeException. > Also, we need to add a try/catch block to the drawHiDPIImage(it uses the SurfaceManager.getManager method directly) > > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010995.html This pull request has now been integrated. Changeset: 8da6c8d6 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/8da6c8d6 Stats: 395 lines in 3 files changed: 82 ins; 250 del; 63 mod 7183828: Invalid Image Variant when using anything other than BufferedImage Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/85 From serb at openjdk.java.net Thu Sep 10 21:49:46 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 21:49:46 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> References: <8PWvHPgmOYMdI6LCIuX_nnKM7-2H0wDKtmSv_5Sk86Q=.c1b2ea3a-00e1-4e9c-9c52-85dcbd1d1c46@github.com> Message-ID: On Tue, 8 Sep 2020 21:54:43 GMT, Sergey Bylokhov wrote: > This the only test which was created to check different types of interpolation. > It checks the rendering to the VolatileImage and uses BufferedImage as a gold image. > But it does not take into account that rendering to the VolatileImage might be affected > by the HiDPI support. > > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010982.html This pull request has now been integrated. Changeset: 48802268 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/48802268 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux Reviewed-by: prr, psadhukhan, kcr ------------- PR: https://git.openjdk.java.net/jdk/pull/86 From serb at openjdk.java.net Thu Sep 10 22:54:46 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 22:54:46 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252070: Some platform-specific BLIT optimizations are not effective Message-ID: <6k2Lv4n9z7v0qBngY5b8dOhIOvRx0Ad3s6gKxdMZ968=.1572dc90-9bd4-414c-baa0-95cf1a0a3477@github.com> Some of our code assumes that the native system(XRender, D3D, OGL) makes some effective optimizations, but in some cases, we can do better. One of the areas for improvement is direct blitting. If the source is much bigger than the destination we should not try to copy to the non-existent area and could cut coordinates accordingly. The actual change is: 951 Rectangle dst = 952 new Rectangle(dx, dy, w, h).intersection(dstData.getBounds()); 953 if (dst.isEmpty()) { 972 // return 975 } 979 sx += dst.x - dx; 980 sy += dst.y - dy; See performance data and some additional comments: https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864 The old review request: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011007.html ------------- Commit messages: - 8252070: Some platform-specific BLIT optimizations are not effective Changes: https://git.openjdk.java.net/jdk/pull/121/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=121&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252070 Stats: 81 lines in 1 file changed: 42 ins; 28 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/121.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/121/head:pull/121 PR: https://git.openjdk.java.net/jdk/pull/121 From jjg at openjdk.java.net Thu Sep 10 23:31:29 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Sep 2020 23:31:29 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy wrote: > I have in mind dozens of improvements all over the code like this one. That sounds scary. Broad updates like these cause unnecessary churn in the codebase, and can make merging and back porting harder. Changes should be discussed ahead of time with the appropriate teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From prr at openjdk.java.net Fri Sep 11 00:00:15 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 11 Sep 2020 00:00:15 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). 1) This is un-necessary churn. 2) I can't even be sure I am finding the ones in my area because there's so much here 3) The ones I can find have no need of whatever performance improvement this might bring. I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates you are making. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: [OpenJDK 2D-Dev] Withdrawn: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 23:57:38 GMT, Phil Race wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > 1) This is un-necessary churn. > 2) I can't even be sure I am finding the ones in my area because there's so much here > 3) The ones I can find have no need of whatever performance improvement this might bring. > I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various > cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates > you are making. Ok, sorry for the distraction. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From wetmore at openjdk.java.net Fri Sep 11 15:20:36 2020 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 11 Sep 2020 15:20:36 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:15:26 GMT, Dmitriy Dumanskiy wrote: >> 1) This is un-necessary churn. >> 2) I can't even be sure I am finding the ones in my area because there's so much here >> 3) The ones I can find have no need of whatever performance improvement this might bring. >> I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various >> cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates >> you are making. > > Ok, sorry for the distraction. Our local Santuario maintainer says: In general, changes to Apache Santuario should also be made at Apache so we stay in sync. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From Sergey.Bylokhov at oracle.com Sat Sep 12 00:46:42 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 Sep 2020 17:46:42 -0700 Subject: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs' In-Reply-To: <8f152117-1563-77e6-a29a-fce090b65855@oracle.com> References: <891419e0-22aa-f9ff-ca93-5796a55819ac@oracle.com> <5F4D5A6A.90009@oracle.com> <8f152117-1563-77e6-a29a-fce090b65855@oracle.com> Message-ID: Hi, Conor The change looks fine, please note that you will need to crate a PR on the GitHub to integrate this fix. > * CSR: https://bugs.openjdk.java.net/browse/JDK-8252495The CSR could be improved, take a look to this example: https://bugs.openjdk.java.net/browse/JDK-8250581 The body of the CSR contains all changes in the specification, the link to the webrev is not enough. -- Best regards, Sergey. From prr at openjdk.java.net Sun Sep 13 04:21:10 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 13 Sep 2020 04:21:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252070: Some platform-specific BLIT optimizations are not effective In-Reply-To: <6k2Lv4n9z7v0qBngY5b8dOhIOvRx0Ad3s6gKxdMZ968=.1572dc90-9bd4-414c-baa0-95cf1a0a3477@github.com> References: <6k2Lv4n9z7v0qBngY5b8dOhIOvRx0Ad3s6gKxdMZ968=.1572dc90-9bd4-414c-baa0-95cf1a0a3477@github.com> Message-ID: On Thu, 10 Sep 2020 22:47:53 GMT, Sergey Bylokhov wrote: > Some of our code assumes that the native system(XRender, D3D, OGL) makes some > effective optimizations, but in some cases, we can do better. > > One of the areas for improvement is direct blitting. If the source is much > bigger than the destination we should not try to copy to the non-existent area > and could cut coordinates accordingly. > > The actual change is: > 951 Rectangle dst = > 952 new Rectangle(dx, dy, w, h).intersection(dstData.getBounds()); > 953 if (dst.isEmpty()) { > 972 // return > 975 } > 979 sx += dst.x - dx; > 980 sy += dst.y - dy; > > See performance data and some additional comments: > https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864 > > The old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011007.html Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/121 From github.com+69505734+ccleary-oracle at openjdk.java.net Mon Sep 14 16:18:26 2020 From: github.com+69505734+ccleary-oracle at openjdk.java.net (Conor Cleary) Date: Mon, 14 Sep 2020 16:18:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs Message-ID: This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The changes address the reliance on default constructors by adding in basic constructors in the following classes: - java.awt.Image - java.awt.PrintJob - java.awt.font.GlyphVector - java.awt.font.LayoutPath - java.awt.font.LineMetrics - java.awt.image.AbstractMultiResolutionImage - java.awt.image.BufferStrategy - java.awt.image.ImageFilter - java.awt.image.RGBImageFilter - java.awt.image.VolatileImage - javax.print.PrintServiceLookup - javax.print.ServiceUI - javax.print.ServiceUIFactory - javax.print.StreamPrintServiceFactory - javax.print.event.PrintJobAdapter specdiff: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/specdiff/overview-summary.html csr: https://bugs.openjdk.java.net/browse/JDK-8252495 ------------- Commit messages: - 8250855: Address reliance on default constructors in the Java 2D APIs Changes: https://git.openjdk.java.net/jdk/pull/153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=153&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250855 Stats: 85 lines in 14 files changed: 71 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/153/head:pull/153 PR: https://git.openjdk.java.net/jdk/pull/153 From prr at openjdk.java.net Mon Sep 14 19:05:16 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 14 Sep 2020 19:05:16 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 19:02:27 GMT, Phil Race wrote: >> This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The changes >> address the reliance on default constructors by adding in basic constructors in the following classes: >> - java.awt.Image >> - java.awt.PrintJob >> - java.awt.font.GlyphVector >> - java.awt.font.LayoutPath >> - java.awt.font.LineMetrics >> - java.awt.image.AbstractMultiResolutionImage >> - java.awt.image.BufferStrategy >> - java.awt.image.ImageFilter >> - java.awt.image.RGBImageFilter >> - java.awt.image.VolatileImage >> - javax.print.PrintServiceLookup >> - javax.print.ServiceUI >> - javax.print.ServiceUIFactory >> - javax.print.StreamPrintServiceFactory >> - javax.print.event.PrintJobAdapter >> >> specdiff: >> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/specdiff/overview-summary.html csr: >> https://bugs.openjdk.java.net/browse/JDK-8252495 > > Marked as reviewed by prr (Reviewer). This needs the CSR to be approved before integration ------------- PR: https://git.openjdk.java.net/jdk/pull/153 From prr at openjdk.java.net Mon Sep 14 19:05:16 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 14 Sep 2020 19:05:16 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 14:32:18 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The changes > address the reliance on default constructors by adding in basic constructors in the following classes: > - java.awt.Image > - java.awt.PrintJob > - java.awt.font.GlyphVector > - java.awt.font.LayoutPath > - java.awt.font.LineMetrics > - java.awt.image.AbstractMultiResolutionImage > - java.awt.image.BufferStrategy > - java.awt.image.ImageFilter > - java.awt.image.RGBImageFilter > - java.awt.image.VolatileImage > - javax.print.PrintServiceLookup > - javax.print.ServiceUI > - javax.print.ServiceUIFactory > - javax.print.StreamPrintServiceFactory > - javax.print.event.PrintJobAdapter > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/specdiff/overview-summary.html csr: > https://bugs.openjdk.java.net/browse/JDK-8252495 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/153 From serb at openjdk.java.net Mon Sep 14 21:30:20 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 14 Sep 2020 21:30:20 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 14:32:18 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The changes > address the reliance on default constructors by adding in basic constructors in the following classes: > - java.awt.Image > - java.awt.PrintJob > - java.awt.font.GlyphVector > - java.awt.font.LayoutPath > - java.awt.font.LineMetrics > - java.awt.image.AbstractMultiResolutionImage > - java.awt.image.BufferStrategy > - java.awt.image.ImageFilter > - java.awt.image.RGBImageFilter > - java.awt.image.VolatileImage > - javax.print.PrintServiceLookup > - javax.print.ServiceUI > - javax.print.ServiceUIFactory > - javax.print.StreamPrintServiceFactory > - javax.print.event.PrintJobAdapter > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/specdiff/overview-summary.html csr: > https://bugs.openjdk.java.net/browse/JDK-8252495 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/153 From ccleary at openjdk.java.net Tue Sep 15 09:40:54 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Sep 2020 09:40:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 21:27:46 GMT, Sergey Bylokhov wrote: >> This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The changes >> address the reliance on default constructors by adding in basic constructors in the following classes: >> - java.awt.Image >> - java.awt.PrintJob >> - java.awt.font.GlyphVector >> - java.awt.font.LayoutPath >> - java.awt.font.LineMetrics >> - java.awt.image.AbstractMultiResolutionImage >> - java.awt.image.BufferStrategy >> - java.awt.image.ImageFilter >> - java.awt.image.RGBImageFilter >> - java.awt.image.VolatileImage >> - javax.print.PrintServiceLookup >> - javax.print.ServiceUI >> - javax.print.ServiceUIFactory >> - javax.print.StreamPrintServiceFactory >> - javax.print.event.PrintJobAdapter >> >> specdiff: >> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/specdiff/overview-summary.html csr: >> https://bugs.openjdk.java.net/browse/JDK-8252495 > > Marked as reviewed by serb (Reviewer). Now awaiting CSR approval as advised ------------- PR: https://git.openjdk.java.net/jdk/pull/153 From ccleary at openjdk.java.net Tue Sep 15 10:16:59 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Sep 2020 10:16:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250859: Address reliance on default constructors in the Accessibility APIs In-Reply-To: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 Changes require approval of CSR, can't request that requirement myself as I am not a reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/174 From ccleary at openjdk.java.net Tue Sep 15 10:16:55 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Sep 2020 10:16:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250859: Address reliance on default constructors in the Accessibility APIs Message-ID: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API description: - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor - Default ctor on javax.accessibility.AccessibleContext - Default ctor on javax.accessibility.AccessibleHyperlink The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API description: - Default ctor on javax.accessibility.AccessibleResourceBundle - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList - Default ctor on com.sun.java.accessibility.util.EventID specdiff: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: https://bugs.openjdk.java.net/browse/JDK-8250859 ------------- Commit messages: - 8250859: Address reliance on default constructors in the Accessibility APIs Changes: https://git.openjdk.java.net/jdk/pull/174/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=174&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250859 Stats: 42 lines in 7 files changed: 35 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/174/head:pull/174 PR: https://git.openjdk.java.net/jdk/pull/174 From AnaweshaK at in.ibm.com Tue Sep 15 12:57:44 2020 From: AnaweshaK at in.ibm.com (Anawesha Khuntia) Date: Tue, 15 Sep 2020 12:57:44 +0000 Subject: [OpenJDK 2D-Dev] In windows GlyphVector produces poorer quality output versus using Graphics.drawString Message-ID: Hi, As Per Apache PDFBOX-4709 ( https://issues.apache.org/jira/browse/PDFBOX-4709 ), while printing in windows using GlyphVector produces poorer quality output versus using Graphics.drawString(...). There's a significant quality difference ,especially on low-dpi (e.g. thermal) printers printing with createGlyphVector versus drawString. Leveraging RenderingHints does not appear to help. Incase of GlyphVector,the issue seems to be caused by precision loss in WPrinterJob.lineTo which maps to wingdi.h LineTo. In all of the jni functions, floats are passed, but in native, only ints and longs are accepted. However , the drawstring function utilizes the wingdi TextOut function and is unaffected due to the text never being converted to curves. It is simply saved as text and the recipient renders it. We have explored various options such as, 1. alternate to lineTo function. However there was no alternate function found in GDI. 2. using setmapmode option, it sets the mapping mode of the specified device context. Using this too did not help us. 3. another alternate lineadd function was evaluated and found inappropriate coz of its dependency on fixed X and Y co-ordinate values which is not the case here. 4. renderingHint options too were tried out, however neither the resulted characters printed were not smooth, nor the curve of characters were smooth.Below options were tried graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); graphics.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BICUBIC); graphics.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY); A similar rendering issues have been reported in the bugs : https://bugs.openjdk.java.net/browse/JDK-7129078 and https://bugs.openjdk.java.net/browse/JDK-6322554 We understand this is a very old issue and various challenges related to GDI rendering.These days more and more customers moving into opensource and this could well sound like a limitation for a certain set of consumers who has strong business need to extensively use low-dpi printers.Hence the recommended option would be to look into this issue by the community and fix it. Regards, Anawesha From jdv at openjdk.java.net Tue Sep 15 13:55:54 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 15 Sep 2020 13:55:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252100: NumberOverflow in class MemoryCache Message-ID: Number overflow in javax/imageio/stream/MemoryCache.java I tried to reproduce the issue but was not able to create stream or BufferedImage of such a large size because of array size limitations. Submitter has mentioned simple fix for overflow which has solved his issue. I have verified the fix by running jtreg and compatibility tests and there are no failures. ------------- Commit messages: - 8252100: NumberOverflow in class MemoryCache Changes: https://git.openjdk.java.net/jdk/pull/182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=182&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252100 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/182/head:pull/182 PR: https://git.openjdk.java.net/jdk/pull/182 From prr at openjdk.java.net Tue Sep 15 17:31:13 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 15 Sep 2020 17:31:13 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252100: NumberOverflow in class MemoryCache In-Reply-To: References: Message-ID: <9oZ_TJmfG1zdMDM21CNJGvooUS8KGHKuag-HnU8Zibo=.8d83fc80-8ba6-4bbb-85cd-9df189de4523@github.com> On Tue, 15 Sep 2020 13:49:19 GMT, Jayathirth D V wrote: > Number overflow in javax/imageio/stream/MemoryCache.java > I tried to reproduce the issue but was not able to create stream or BufferedImage of such a large size because of array > size limitations. Submitter has mentioned simple fix for overflow which has solved his issue. I have verified the fix > by running jtreg and compatibility tests and there are no failures. If pos is big enough you could still theoretically have overflow, but this is still better. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/182 From prr at openjdk.java.net Tue Sep 15 19:41:28 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 15 Sep 2020 19:41:28 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 09:38:02 GMT, Conor Cleary wrote: >> Marked as reviewed by serb (Reviewer). > > Now awaiting CSR approval as advised The CSR needs some updates to put the spec inline ------------- PR: https://git.openjdk.java.net/jdk/pull/153 From prr at openjdk.java.net Tue Sep 15 19:43:19 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 15 Sep 2020 19:43:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250859: Address reliance on default constructors in the Accessibility APIs In-Reply-To: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 This looks OK but the CSR needs updates first. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/174 From kcr at openjdk.java.net Tue Sep 15 22:27:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Sep 2020 22:27:23 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253206: Enforce whitespace checking for additional source files Message-ID: This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: .cc, .hh, .m, .mm All files with the above extensions are now white-space clean after the fix for [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). ------------- Commit messages: - 8253206: Enforce whitespace checking for additional source files Changes: https://git.openjdk.java.net/jdk/pull/195/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=195&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253206 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/195/head:pull/195 PR: https://git.openjdk.java.net/jdk/pull/195 From prr at openjdk.java.net Tue Sep 15 23:09:21 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 15 Sep 2020 23:09:21 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From serb at openjdk.java.net Wed Sep 16 01:21:30 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 16 Sep 2020 01:21:30 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252100: NumberOverflow in class MemoryCache In-Reply-To: <9oZ_TJmfG1zdMDM21CNJGvooUS8KGHKuag-HnU8Zibo=.8d83fc80-8ba6-4bbb-85cd-9df189de4523@github.com> References: <9oZ_TJmfG1zdMDM21CNJGvooUS8KGHKuag-HnU8Zibo=.8d83fc80-8ba6-4bbb-85cd-9df189de4523@github.com> Message-ID: <-8OnbBiumcR6WoQnon-KR-mch3Ey3ZsII0tpV07LEG0=.97eb8e47-590d-4c6d-9137-52de820586d2@github.com> On Tue, 15 Sep 2020 17:28:44 GMT, Phil Race wrote: >> Number overflow in javax/imageio/stream/MemoryCache.java >> I tried to reproduce the issue but was not able to create stream or BufferedImage of such a large size because of array >> size limitations. Submitter has mentioned simple fix for overflow which has solved his issue. I have verified the fix >> by running jtreg and compatibility tests and there are no failures. > > If pos is big enough you could still theoretically have overflow, but this is still better. You can try to create such images using some separate tools, BTW I have found one here(32768 ? 32768): https://forums.bohemia.net/forums/topic/202016-high-quality-maps-for-altis-and-stratis/ ------------- PR: https://git.openjdk.java.net/jdk/pull/182 From chegar at openjdk.java.net Wed Sep 16 08:55:40 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 16 Sep 2020 08:55:40 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250859: Address reliance on default constructors in the Accessibility APIs In-Reply-To: References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Tue, 15 Sep 2020 19:40:28 GMT, Phil Race wrote: >> This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The >> following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API >> description: >> - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor >> - Default ctor on javax.accessibility.AccessibleContext >> - Default ctor on javax.accessibility.AccessibleHyperlink >> >> The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API >> description: >> - Default ctor on javax.accessibility.AccessibleResourceBundle >> - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor >> - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor >> - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList >> - Default ctor on com.sun.java.accessibility.util.EventID >> >> specdiff: >> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: >> https://bugs.openjdk.java.net/browse/JDK-8250859 > > This looks OK but the CSR needs updates first. The CSR lists `com.sun.java.accessibility.util.SwingEventMonitor` as being changed, but I cannot find that class in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/174 From erikj at openjdk.java.net Wed Sep 16 13:09:32 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Sep 2020 13:09:32 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From jdv at openjdk.java.net Wed Sep 16 13:49:33 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 16 Sep 2020 13:49:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252100: NumberOverflow in class MemoryCache In-Reply-To: <-8OnbBiumcR6WoQnon-KR-mch3Ey3ZsII0tpV07LEG0=.97eb8e47-590d-4c6d-9137-52de820586d2@github.com> References: <9oZ_TJmfG1zdMDM21CNJGvooUS8KGHKuag-HnU8Zibo=.8d83fc80-8ba6-4bbb-85cd-9df189de4523@github.com> <-8OnbBiumcR6WoQnon-KR-mch3Ey3ZsII0tpV07LEG0=.97eb8e47-590d-4c6d-9137-52de820586d2@github.com> Message-ID: On Wed, 16 Sep 2020 01:18:00 GMT, Sergey Bylokhov wrote: >> If pos is big enough you could still theoretically have overflow, but this is still better. > > You can try to create such images using some separate tools, BTW I have found one here(32768 ? 32768): > https://forums.bohemia.net/forums/topic/202016-high-quality-maps-for-altis-and-stratis/ Hi Sergey, I tried reading images from https://forums.bohemia.net/forums/topic/202016-high-quality-maps-for-altis-and-stratis/, we are trying to create destination BufferedImage of huge size and again we will hit: Exception in thread "main" java.lang.IllegalArgumentException: Invalid scanline stride at java.desktop/java.awt.image.ComponentSampleModel.getBufferSize(ComponentSampleModel.java:268) where we check scanline with Integer.MAX_VALUE. From the description in JBS i can see that submitter has his own plugin for TIFF and that is the only reason that he is able to read such a large images. With default plugin we will hit this issue whenever we try to read large images as it is not supported. Thanks, Jay ------------- PR: https://git.openjdk.java.net/jdk/pull/182 From jdv at openjdk.java.net Wed Sep 16 14:01:33 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 16 Sep 2020 14:01:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252070: Some platform-specific BLIT optimizations are not effective In-Reply-To: <6k2Lv4n9z7v0qBngY5b8dOhIOvRx0Ad3s6gKxdMZ968=.1572dc90-9bd4-414c-baa0-95cf1a0a3477@github.com> References: <6k2Lv4n9z7v0qBngY5b8dOhIOvRx0Ad3s6gKxdMZ968=.1572dc90-9bd4-414c-baa0-95cf1a0a3477@github.com> Message-ID: On Thu, 10 Sep 2020 22:47:53 GMT, Sergey Bylokhov wrote: > Some of our code assumes that the native system(XRender, D3D, OGL) makes some > effective optimizations, but in some cases, we can do better. > > One of the areas for improvement is direct blitting. If the source is much > bigger than the destination we should not try to copy to the non-existent area > and could cut coordinates accordingly. > > The actual change is: > 951 Rectangle dst = > 952 new Rectangle(dx, dy, w, h).intersection(dstData.getBounds()); > 953 if (dst.isEmpty()) { > 972 // return > 975 } > 979 sx += dst.x - dx; > 980 sy += dst.y - dy; > > See performance data and some additional comments: > https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864 > > The old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011007.html Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/121 From jdv at openjdk.java.net Wed Sep 16 14:05:18 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 16 Sep 2020 14:05:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From kcr at openjdk.java.net Wed Sep 16 14:05:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Sep 2020 14:05:18 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). This pull request has now been integrated. Changeset: 10867134 Author: Kevin Rushforth Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/10867134 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253206: Enforce whitespace checking for additional source files Reviewed-by: prr, erikj, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From serb at openjdk.java.net Thu Sep 17 01:30:27 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 17 Sep 2020 01:30:27 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252100: NumberOverflow in class MemoryCache In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 13:49:19 GMT, Jayathirth D V wrote: > Number overflow in javax/imageio/stream/MemoryCache.java > I tried to reproduce the issue but was not able to create stream or BufferedImage of such a large size because of array > size limitations. Submitter has mentioned simple fix for overflow which has solved his issue. I have verified the fix > by running jtreg and compatibility tests and there are no failures. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/182 From jdv at openjdk.java.net Thu Sep 17 04:34:03 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 17 Sep 2020 04:34:03 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8252100: NumberOverflow in class MemoryCache In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 13:49:19 GMT, Jayathirth D V wrote: > Number overflow in javax/imageio/stream/MemoryCache.java > I tried to reproduce the issue but was not able to create stream or BufferedImage of such a large size because of array > size limitations. Submitter has mentioned simple fix for overflow which has solved his issue. I have verified the fix > by running jtreg and compatibility tests and there are no failures. This pull request has now been integrated. Changeset: b87a1599 Author: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/b87a1599 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8252100: NumberOverflow in class MemoryCache Reviewed-by: prr, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/182 From peterhull90 at gmail.com Thu Sep 17 06:53:18 2020 From: peterhull90 at gmail.com (Peter Hull) Date: Thu, 17 Sep 2020 07:53:18 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: Just for my curiosity, what issues can arise relying on default constructors? I couldn't find anything with google (apart from links back to these messages!) Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccleary at openjdk.java.net Thu Sep 17 11:04:11 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Thu, 17 Sep 2020 11:04:11 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250859: Address reliance on default constructors in the Accessibility APIs [v2] In-Reply-To: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 Conor Cleary has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8250859: Added no-arg constructor to SwingEventMonitor.java - Merge remote-tracking branch 'origin/master' into JDK-8250859 - Merge remote-tracking branch 'origin/master' into JDK-8250859 - 8250859: Address reliance on default constructors in the Accessibility APIs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/174/files - new: https://git.openjdk.java.net/jdk/pull/174/files/a2946aca..bc02a4de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=174&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=174&range=00-01 Stats: 2012 lines in 47 files changed: 486 ins; 1201 del; 325 mod Patch: https://git.openjdk.java.net/jdk/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/174/head:pull/174 PR: https://git.openjdk.java.net/jdk/pull/174 From ccleary at openjdk.java.net Thu Sep 17 11:04:13 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Thu, 17 Sep 2020 11:04:13 GMT Subject: [OpenJDK 2D-Dev] RFR: 8250859: Address reliance on default constructors in the Accessibility APIs [v2] In-Reply-To: References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Wed, 16 Sep 2020 08:52:35 GMT, Chris Hegarty wrote: > The CSR lists `com.sun.java.accessibility.util.SwingEventMonitor` as being changed, but I cannot find that class in > this PR. Changes to this class were indeed missing. This has now been addressed. Thanks for spotting that! ------------- PR: https://git.openjdk.java.net/jdk/pull/174 From kevin.rushforth at oracle.com Thu Sep 17 11:49:12 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Sep 2020 04:49:12 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: <1d444e74-e79f-d592-85f2-20a21f6ed0a5@oracle.com> It is an anti-pattern to rely on an implicit default constructor in a publicly exported class in a library. There are (at least) three good reasons to avoid this: 1. The default constructor will have no API docs 2. You could end up with a public constructor in a class where you don't want a publicly visible constructor, for example a class with factory methods. 3. In a class where you do intend a public constructor, if you later add another constructor with an argument, it will have the effect of removing the default one, which is an incompatible API change. -- Kevin On 9/16/2020 11:53 PM, Peter Hull wrote: > Just for my curiosity, what issues can arise relying on default > constructors? I couldn't find anything with google (apart from links > back to these messages!) > Thanks, > Peter From philip.race at oracle.com Thu Sep 17 23:56:15 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 17 Sep 2020 16:56:15 -0700 Subject: [OpenJDK 2D-Dev] EA5 build of Project Lanai (Metal rendering pipeline for macOS) is now posted Message-ID: <5F63F79F.7000702@oracle.com> After some technical hiccups which delayed it, https://jdk.java.net/lanai/ is now hosting the EA 5 build of Lanai EA 5 Build 16-lanai+1-129 (2020/9/7) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. EA 5 contains the following new bug fixes relative to EA 4 # 8252845: Regressions in Sanity tests after JDK-8251032 # 8252798: Cleanup LCD text rendering code # 8252386: Lanai: Implement RadialGradientPaint in shader # 8252706: Enable usage of rowBytesOffset for LCD non cache rendering # 8251032: Colors with texture background look different with Alpha Com... # 8252385: Lanai: Implement LinearGradient paint in shader # 8243547: Lanai - Netbeans IDE has BLACK background for the Toolbar and Statusbar # 8240164: Test java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java fails for metal # 8240074: Test java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java fails for metal # 8251027: DrawString with TexturePaint is corrupted # 8242920: Gradient Paint doesn't work with metal # 8252371: LCD text rendered with Metal pipeline is corrupted # 8252217: Crash in metal pipeline which running J2DBench test # 8252057: Crash in metal pipeline when dragging any Swing app to other... # 8251484: Performace drop in FlatBoxAA renderperf test for metal pipeline # 8251242: Tile based rendering results in artifacts in last column while using metal pipeline # 8249659: [Lanai] Crash while running RenderPerfTest with metal pipeli... # 8251167: Drawing polyline twice in XOR mode leaves out some traces on screen (only with uiScale=1.0) -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smarks at openjdk.java.net Fri Sep 18 02:50:45 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Sep 2020 02:50:45 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR, > I have in mind dozens of improvements all over the code like this one. It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 18 11:07:46 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 18 Sep 2020 11:07:46 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <668fR1wEZWaC0TDCyRIeOZ4AddXZXnKQhyHQdXtOab8=.6cb419cb-632b-4524-980e-18a6e06958e8@github.com> On Fri, 18 Sep 2020 02:48:15 GMT, Stuart Marks wrote: >> Our local Santuario maintainer says: >> >> In general, changes to Apache Santuario should also be made at Apache so we stay in sync. > > Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made > earlier in this PR, >> I have in mind dozens of improvements all over the code like this one. > > It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and > sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source > bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... > so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to > code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything > outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and > sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. > There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some > code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is > definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd > like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. @stuart-marks thanks. Sure, I understand that maintaining OpenJDK is not a simple task. I thought as change is super simple without any side effects it can go through. But I was wrong. That's fine. I'll focus on `java.base` when I have some free time. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From prr at openjdk.java.net Fri Sep 18 17:17:58 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 18 Sep 2020 17:17:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable Message-ID: This test is being marked intermittent, although at the same time I am trying to make it less likely to fail. However since we have a known issue around NIO mmap'd files not being directly unmappable, the deletes the font system make may be stymied on Windows. So marking it intermittent is probably for the best One other thing is that I changed it so that the tmp files created are now of different sizes so we can now tell which createFont() call resulted in the font that can't be deleted. If it is always the Type 1 fonts then that will be good evidence it is mmap that is the problem. We likely need to stop using mmap for this reason. ------------- Commit messages: - 8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable Changes: https://git.openjdk.java.net/jdk/pull/256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=256&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249142 Stats: 19 lines in 2 files changed: 9 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/256/head:pull/256 PR: https://git.openjdk.java.net/jdk/pull/256 From prr at openjdk.java.net Fri Sep 18 20:30:37 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 18 Sep 2020 20:30:37 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252199: Reimplement support of Type 1 fonts without MappedByteBuffer Message-ID: <-itaQjUAbkFlLmueMsIiqLBxyS1bQz6pAT1lDxOlnXY=.2616565b-104f-4fe4-a190-ee6755586955@github.com> I changed it to read the file into a ByteBuffer to avoid the problem that we can't control when NIO free's the mmaped buffer. This is a problem for leaking tmp Type1 font files when using createFont and I thought maybe we could just change that case, but Type 1 fonts are getting very rare. Neither Mac nor Windows ship them and Mac at least does not support them at all, and current Linuxes seem to be almost all TTF and OTF fonts. Also T1 fonts are small, so any minimal peformance benefit is not worth it. There isn't a specific regression test. I verified this on Ubuntu 20.04 which has at least a (very) few Type 1 fonts. ------------- Commit messages: - 8252199: Reimplement support of Type 1 fonts without MappedByteBuffer Changes: https://git.openjdk.java.net/jdk/pull/258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=258&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252199 Stats: 13 lines in 1 file changed: 1 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/258/head:pull/258 PR: https://git.openjdk.java.net/jdk/pull/258 From serb at openjdk.java.net Sat Sep 19 01:48:43 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 19 Sep 2020 01:48:43 GMT Subject: [OpenJDK 2D-Dev] RFR: 8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 17:11:04 GMT, Phil Race wrote: > This test is being marked intermittent, although at the same time I am trying to make it less likely to fail. > However since we have a known issue around NIO mmap'd files not being directly unmappable, the > deletes the font system make may be stymied on Windows. So marking it intermittent is probably for the best > One other thing is that I changed it so that the tmp files created are now of different sizes so we can now > tell which createFont() call resulted in the font that can't be deleted. If it is always the Type 1 fonts then > that will be good evidence it is mmap that is the problem. > We likely need to stop using mmap for this reason. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/256 From serb at openjdk.java.net Sat Sep 19 01:51:56 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 19 Sep 2020 01:51:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252199: Reimplement support of Type 1 fonts without MappedByteBuffer In-Reply-To: <-itaQjUAbkFlLmueMsIiqLBxyS1bQz6pAT1lDxOlnXY=.2616565b-104f-4fe4-a190-ee6755586955@github.com> References: <-itaQjUAbkFlLmueMsIiqLBxyS1bQz6pAT1lDxOlnXY=.2616565b-104f-4fe4-a190-ee6755586955@github.com> Message-ID: <3T7p8AZjVPUyAKQxW49nR2zrSXSkjgAcnU9gLgjnyto=.64cbd240-6b91-43e3-a67e-5a39e5d4ed43@github.com> On Fri, 18 Sep 2020 20:23:25 GMT, Phil Race wrote: > I changed it to read the file into a ByteBuffer to avoid the problem that we can't control when NIO free's the mmaped > buffer. This is a problem for leaking tmp Type1 font files when using createFont and I thought maybe we could just > change that case, but Type 1 fonts are getting very rare. Neither Mac nor Windows ship them and Mac at least does not > support them at all, and current Linuxes seem to be almost all TTF and OTF fonts. Also T1 fonts are small, so any > minimal peformance benefit is not worth it. There isn't a specific regression test. I verified this on Ubuntu 20.04 > which has at least a (very) few Type 1 fonts. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/258 From prr at openjdk.java.net Sat Sep 19 17:32:25 2020 From: prr at openjdk.java.net (Phil Race) Date: Sat, 19 Sep 2020 17:32:25 GMT Subject: [OpenJDK 2D-Dev] Withdrawn: 8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 17:11:04 GMT, Phil Race wrote: > This test is being marked intermittent, although at the same time I am trying to make it less likely to fail. > However since we have a known issue around NIO mmap'd files not being directly unmappable, the > deletes the font system make may be stymied on Windows. So marking it intermittent is probably for the best > One other thing is that I changed it so that the tmp files created are now of different sizes so we can now > tell which createFont() call resulted in the font that can't be deleted. If it is always the Type 1 fonts then > that will be good evidence it is mmap that is the problem. > We likely need to stop using mmap for this reason. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/256 From prr at openjdk.java.net Sat Sep 19 17:39:03 2020 From: prr at openjdk.java.net (Phil Race) Date: Sat, 19 Sep 2020 17:39:03 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable In-Reply-To: References: Message-ID: <5AHg4LprA1-4gqMKFMpml0hIhSk06Ni1YxdBQqRv5m0=.f2d2419f-449f-43a7-b6cb-9c468e2acba1@github.com> On Fri, 18 Sep 2020 17:11:04 GMT, Phil Race wrote: > This test is being marked intermittent, although at the same time I am trying to make it less likely to fail. > However since we have a known issue around NIO mmap'd files not being directly unmappable, the > deletes the font system make may be stymied on Windows. So marking it intermittent is probably for the best > One other thing is that I changed it so that the tmp files created are now of different sizes so we can now > tell which createFont() call resulted in the font that can't be deleted. If it is always the Type 1 fonts then > that will be good evidence it is mmap that is the problem. > We likely need to stop using mmap for this reason. This pull request has now been integrated. Changeset: d27835b3 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/d27835b3 Stats: 19 lines in 2 files changed: 2 ins; 9 del; 8 mod 8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/256 From serb at openjdk.java.net Sun Sep 20 04:36:08 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 20 Sep 2020 04:36:08 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8252070: Some platform-specific BLIT optimizations are not effective In-Reply-To: <6k2Lv4n9z7v0qBngY5b8dOhIOvRx0Ad3s6gKxdMZ968=.1572dc90-9bd4-414c-baa0-95cf1a0a3477@github.com> References: <6k2Lv4n9z7v0qBngY5b8dOhIOvRx0Ad3s6gKxdMZ968=.1572dc90-9bd4-414c-baa0-95cf1a0a3477@github.com> Message-ID: On Thu, 10 Sep 2020 22:47:53 GMT, Sergey Bylokhov wrote: > Some of our code assumes that the native system(XRender, D3D, OGL) makes some > effective optimizations, but in some cases, we can do better. > > One of the areas for improvement is direct blitting. If the source is much > bigger than the destination we should not try to copy to the non-existent area > and could cut coordinates accordingly. > > The actual change is: > 951 Rectangle dst = > 952 new Rectangle(dx, dy, w, h).intersection(dstData.getBounds()); > 953 if (dst.isEmpty()) { > 972 // return > 975 } > 979 sx += dst.x - dx; > 980 sy += dst.y - dy; > > See performance data and some additional comments: > https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864 > > The old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011007.html This pull request has now been integrated. Changeset: 3d88d387 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/3d88d387 Stats: 80 lines in 1 file changed: 27 ins; 41 del; 12 mod 8252070: Some platform-specific BLIT optimizations are not effective Reviewed-by: prr, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/121 From jdv at openjdk.java.net Sun Sep 20 13:30:33 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Sun, 20 Sep 2020 13:30:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252199: Reimplement support of Type 1 fonts without MappedByteBuffer In-Reply-To: <-itaQjUAbkFlLmueMsIiqLBxyS1bQz6pAT1lDxOlnXY=.2616565b-104f-4fe4-a190-ee6755586955@github.com> References: <-itaQjUAbkFlLmueMsIiqLBxyS1bQz6pAT1lDxOlnXY=.2616565b-104f-4fe4-a190-ee6755586955@github.com> Message-ID: On Fri, 18 Sep 2020 20:23:25 GMT, Phil Race wrote: > I changed it to read the file into a ByteBuffer to avoid the problem that we can't control when NIO free's the mmaped > buffer. This is a problem for leaking tmp Type1 font files when using createFont and I thought maybe we could just > change that case, but Type 1 fonts are getting very rare. Neither Mac nor Windows ship them and Mac at least does not > support them at all, and current Linuxes seem to be almost all TTF and OTF fonts. Also T1 fonts are small, so any > minimal peformance benefit is not worth it. There isn't a specific regression test. I verified this on Ubuntu 20.04 > which has at least a (very) few Type 1 fonts. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/258 From prr at openjdk.java.net Sun Sep 20 16:20:21 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 20 Sep 2020 16:20:21 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8252199: Reimplement support of Type 1 fonts without MappedByteBuffer In-Reply-To: <-itaQjUAbkFlLmueMsIiqLBxyS1bQz6pAT1lDxOlnXY=.2616565b-104f-4fe4-a190-ee6755586955@github.com> References: <-itaQjUAbkFlLmueMsIiqLBxyS1bQz6pAT1lDxOlnXY=.2616565b-104f-4fe4-a190-ee6755586955@github.com> Message-ID: On Fri, 18 Sep 2020 20:23:25 GMT, Phil Race wrote: > I changed it to read the file into a ByteBuffer to avoid the problem that we can't control when NIO free's the mmaped > buffer. This is a problem for leaking tmp Type1 font files when using createFont and I thought maybe we could just > change that case, but Type 1 fonts are getting very rare. Neither Mac nor Windows ship them and Mac at least does not > support them at all, and current Linuxes seem to be almost all TTF and OTF fonts. Also T1 fonts are small, so any > minimal peformance benefit is not worth it. There isn't a specific regression test. I verified this on Ubuntu 20.04 > which has at least a (very) few Type 1 fonts. This pull request has now been integrated. Changeset: cc7521c4 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/cc7521c4 Stats: 13 lines in 1 file changed: 1 ins; 1 del; 11 mod 8252199: Reimplement support of Type 1 fonts without MappedByteBuffer Reviewed-by: serb, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/258 From prr at openjdk.java.net Mon Sep 21 20:51:31 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 21 Sep 2020 20:51:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252195: AWT Accessibility API nested classes rely on default constructors Message-ID: https://bugs.openjdk.java.net/browse/JDK-8252195 is another one of the issues adding missing explicit no-args constructors in the desktop module. As well as being nested, these are all concrete, but protected, classes and so the constructors are protected. CSR here https://bugs.openjdk.java.net/browse/JDK-8253450 needs a reviewer too. ------------- Commit messages: - 8252195: AWT Accessibility API nested classes rely on default constructors - 8252195: AWT Accessibility API nested classes rely on default constructors Changes: https://git.openjdk.java.net/jdk/pull/288/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=288&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252195 Stats: 117 lines in 19 files changed: 117 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/288/head:pull/288 PR: https://git.openjdk.java.net/jdk/pull/288 From github.com+70650887+skodanda at openjdk.java.net Mon Sep 21 22:00:52 2020 From: github.com+70650887+skodanda at openjdk.java.net (skodanda) Date: Mon, 21 Sep 2020 22:00:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open Message-ID: Hello All, Could you please review a TEST_BUG fix for the JDK 16? Bug: https://bugs.openjdk.java.net/browse/JDK-8248352 Problem description: The test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can potentially leave the frame open if it fails. If it were not for the frame, the test could be headless. So probably, we can remove the call to showText() from the test and make it headless.. Fix: An argument is added to the test. If "-show" is passed, the test will show UI for visual inspection. ------------- Commit messages: - Update ArabicDiacriticTest.java Changes: https://git.openjdk.java.net/jdk/pull/255/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=255&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248352 Stats: 11 lines in 1 file changed: 2 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/255/head:pull/255 PR: https://git.openjdk.java.net/jdk/pull/255 From prr at openjdk.java.net Mon Sep 21 22:00:52 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 21 Sep 2020 22:00:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 17:05:42 GMT, skodanda wrote: > Hello All, > > Could you please review a TEST_BUG fix for the JDK 16? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248352 > > Problem description: The test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can potentially leave the > frame open if it fails. If it were not for the frame, the test could be headless. So probably, we can remove the call > to showText() from the test and make it headless.. Fix: An argument is added to the test. If "-show" is passed, the > test will show UI for visual inspection. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/255 From serb at openjdk.java.net Tue Sep 22 03:03:15 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 22 Sep 2020 03:03:15 GMT Subject: [OpenJDK 2D-Dev] RFR: 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 23:01:57 GMT, Phil Race wrote: >> Hello All, >> >> Could you please review a TEST_BUG fix for the JDK 16? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8248352 >> >> Problem description: The test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can potentially leave the >> frame open if it fails. If it were not for the frame, the test could be headless. So probably, we can remove the call >> to showText() from the test and make it headless.. Fix: An argument is added to the test. If "-show" is passed, the >> test will show UI for visual inspection. > > Marked as reviewed by prr (Reviewer). Since you remove the @headful keyword, did you check that the test works fine via mach5? It will now select a completely different set of test systems. ------------- PR: https://git.openjdk.java.net/jdk/pull/255 From serb at openjdk.java.net Tue Sep 22 03:06:31 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 22 Sep 2020 03:06:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252195: AWT Accessibility API nested classes rely on default constructors In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 20:17:36 GMT, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8252195 > is another one of the issues adding missing explicit no-args constructors in the desktop module. > > As well as being nested, these are all concrete, but protected, classes and so the constructors > are protected. > > CSR here https://bugs.openjdk.java.net/browse/JDK-8253450 needs a reviewer too. src/java.desktop/share/classes/java/LS line 1: > 1: -rw-r--r-- 1 prrace staff 22640 Sep 21 12:12 CheckboxMenuItem.java This extra file seems accidentally added ------------- PR: https://git.openjdk.java.net/jdk/pull/288 From github.com+70650887+skodanda at openjdk.java.net Tue Sep 22 05:03:05 2020 From: github.com+70650887+skodanda at openjdk.java.net (skodanda) Date: Tue, 22 Sep 2020 05:03:05 GMT Subject: [OpenJDK 2D-Dev] RFR: 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 03:00:20 GMT, Sergey Bylokhov wrote: >> Marked as reviewed by prr (Reviewer). > > Since you remove the @headful keyword, did you check that the test works fine via mach5? It will now select a > completely different set of test systems. Dear Sergey, I did test my changes via mach5. It runs successfully on all the 3 platforms. Please find below the result link after running the test using mach5 https://mach5.us.oracle.com/mdash/jobs/skodanda-open-20200902-1336-13932582 Best Regards, K Suman Rajkumaar On 22/09/2020 08:30, Sergey Bylokhov wrote: > > Since you remove the @headful > > keyword, did you check that the test works fine via mach5? It will now > select a completely different set of test systems. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/255 From vipinmv1 at in.ibm.com Tue Sep 22 05:40:32 2020 From: vipinmv1 at in.ibm.com (Vipin Mv1) Date: Tue, 22 Sep 2020 05:40:32 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray In-Reply-To: References: , <5F4BD451.9020200@oracle.com>, <5F47FD26.8090307@oracle.com> <5F4A9A23.9030002@oracle.com> Message-ID: Hi, May I ask for a status on this please. -----Vipin Mv1/India/IBM wrote: ----- To: Philip Race From: Vipin Mv1/India/IBM Date: 08/31/2020 05:52PM Cc: 2d-dev at openjdk.java.net Subject: Re: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray Hi Philip, Thanks for the review comments. The testcase test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java seems to be intended to test only the MediaTray functionality. Also, it doesn't seems to have anything that is Linux specific. Rather than having a new testcase wouldn't it be fine to have os.family == "mac" change alone to the existing one.? Regarding the testing, the patch was already tested by our customer using a multi tray printer and was found to be working. Owing to WFH factor due to COVID19, multi tray printer is not accessible to us at this point of time. May I request if the community can help us do further testing with the multi tray printer. Thanks & Regards Vipin MV -----Philip Race wrote: ----- To: Vipin Mv1 From: Philip Race Date: 08/30/2020 10:02PM Cc: 2d-dev at openjdk.java.net Subject: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray PS there is an existing manual regression test but it is currently geared towards Linux and in fact is set to run only on Linux test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java So you still may find it easier to create a new test rather than modify this one to avoid breaking what it tests. -phil On 8/29/20, 11:10 AM, Philip Race wrote: > PS, there's a test case in the bug. Seems like it could be used as the > basis for a manual regression test. > > Make sure you use @requires printer as well as adding the manual and > headful keywords > and next you'll have to check for an installed printer with multiple > trays > > -phil > > On 8/27/20, 11:36 AM, Philip Race wrote: >> This looks reasonable but we need to test it first before approving it. >> >> -phil. >> >> On 8/27/20, 6:16 AM, Vipin Mv1 wrote: >>> Hi, >>> >>> Please find below a patch for the following issue. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8234393 >>> >>> >>> http://cr.openjdk.java.net/~aleonard/8234393/webrev.00 >>> >>> Thanks& Regards >>> Vipin MV >>> >>> From serb at openjdk.java.net Tue Sep 22 06:26:05 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 22 Sep 2020 06:26:05 GMT Subject: [OpenJDK 2D-Dev] RFR: 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 17:05:42 GMT, skodanda wrote: > Hello All, > > Could you please review a TEST_BUG fix for the JDK 16? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248352 > > Problem description: The test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can potentially leave the > frame open if it fails. If it were not for the frame, the test could be headless. So probably, we can remove the call > to showText() from the test and make it headless.. Fix: An argument is added to the test. If "-show" is passed, the > test will show UI for visual inspection. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/255 From aivanov at openjdk.java.net Tue Sep 22 09:57:39 2020 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 22 Sep 2020 09:57:39 GMT Subject: [OpenJDK 2D-Dev] RFR: 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 17:05:42 GMT, skodanda wrote: > Hello All, > > Could you please review a TEST_BUG fix for the JDK 16? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248352 > > Problem description: The test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can potentially leave the > frame open if it fails. If it were not for the frame, the test could be headless. So probably, we can remove the call > to showText() from the test and make it headless.. Fix: An argument is added to the test. If "-show" is passed, the > test will show UI for visual inspection. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/255 From github.com+70650887+skodanda at openjdk.java.net Tue Sep 22 10:02:01 2020 From: github.com+70650887+skodanda at openjdk.java.net (skodanda) Date: Tue, 22 Sep 2020 10:02:01 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 17:05:42 GMT, skodanda wrote: > Hello All, > > Could you please review a TEST_BUG fix for the JDK 16? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248352 > > Problem description: The test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can potentially leave the > frame open if it fails. If it were not for the frame, the test could be headless. So probably, we can remove the call > to showText() from the test and make it headless.. Fix: An argument is added to the test. If "-show" is passed, the > test will show UI for visual inspection. This pull request has now been integrated. Changeset: aa386240 Author: skodanda <70650887+skodanda at users.noreply.github.com> Committer: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/aa386240 Stats: 11 lines in 1 file changed: 4 ins; 2 del; 5 mod 8248352: [TEST_BUG] Test test/jdk/java/awt/font/TextLayout/ArabicDiacriticTest.java can leave frame open Reviewed-by: prr, serb, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/255 From prr at openjdk.java.net Tue Sep 22 16:08:12 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 22 Sep 2020 16:08:12 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252195: AWT Accessibility API nested classes rely on default constructors [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8252195 > is another one of the issues adding missing explicit no-args constructors in the desktop module. > > As well as being nested, these are all concrete, but protected, classes and so the constructors > are protected. > > CSR here https://bugs.openjdk.java.net/browse/JDK-8253450 needs a reviewer too. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8252195: AWT Accessibility API nested classes rely on default constructors ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/288/files - new: https://git.openjdk.java.net/jdk/pull/288/files/8dab932c..c57687ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=288&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=288&range=00-01 Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/288/head:pull/288 PR: https://git.openjdk.java.net/jdk/pull/288 From prr at openjdk.java.net Tue Sep 22 16:08:13 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 22 Sep 2020 16:08:13 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252195: AWT Accessibility API nested classes rely on default constructors In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 20:17:36 GMT, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8252195 > is another one of the issues adding missing explicit no-args constructors in the desktop module. > > As well as being nested, these are all concrete, but protected, classes and so the constructors > are protected. > > CSR here https://bugs.openjdk.java.net/browse/JDK-8253450 needs a reviewer too. extra file deleted. That'll teach me not to do 'git add ' ------------- PR: https://git.openjdk.java.net/jdk/pull/288 From philip.race at oracle.com Tue Sep 22 19:07:05 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 22 Sep 2020 12:07:05 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray In-Reply-To: References: , <5F4BD451.9020200@oracle.com>, <5F47FD26.8090307@oracle.com> <5F4A9A23.9030002@oracle.com> Message-ID: <5F6A4B59.8010405@oracle.com> I guess the status is every one has been busy with transitioning to github [1] This should be re-sent as a github PR to be considered further. However I think that one way or another *you* need to provide the test. Saying a customer tested it or vaguely hoping the community will help you out is just going to delay this. -phil. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004691.html On 9/21/20, 10:40 PM, Vipin Mv1 wrote: > Hi, > > May I ask for a status on this please. > > > -----Vipin Mv1/India/IBM wrote: ----- > To: Philip Race > From: Vipin Mv1/India/IBM > Date: 08/31/2020 05:52PM > Cc: 2d-dev at openjdk.java.net > Subject: Re: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray > > Hi Philip, > > Thanks for the review comments. The testcase test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java seems to be intended to test only the MediaTray functionality. Also, it doesn't seems to have anything that is Linux specific. > > Rather than having a new testcase wouldn't it be fine to have os.family == "mac" change alone to the existing one.? > > Regarding the testing, the patch was already tested by our customer using a multi tray printer and was found to be working. Owing to WFH factor due to COVID19, multi tray printer is not accessible to us at this point of time. > > May I request if the community can help us do further testing with the multi tray printer. > > Thanks& Regards > Vipin MV > > -----Philip Race wrote: ----- > To: Vipin Mv1 > From: Philip Race > Date: 08/30/2020 10:02PM > Cc: 2d-dev at openjdk.java.net > Subject: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray > > PS there is an existing manual regression test but it is currently > geared towards Linux and in fact is set to run only on Linux > test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java > So you still may find it easier to create a new test rather than modify > this one to avoid breaking what it tests. > > -phil > > > On 8/29/20, 11:10 AM, Philip Race wrote: >> PS, there's a test case in the bug. Seems like it could be used as the >> basis for a manual regression test. >> >> Make sure you use @requires printer as well as adding the manual and >> headful keywords >> and next you'll have to check for an installed printer with multiple >> trays >> >> -phil >> >> On 8/27/20, 11:36 AM, Philip Race wrote: >>> This looks reasonable but we need to test it first before approving it. >>> >>> -phil. >>> >>> On 8/27/20, 6:16 AM, Vipin Mv1 wrote: >>>> Hi, >>>> >>>> Please find below a patch for the following issue. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8234393 >>>> >>>> >>>> http://cr.openjdk.java.net/~aleonard/8234393/webrev.00 >>>> >>>> Thanks& Regards >>>> Vipin MV >>>> >>>> > From serb at openjdk.java.net Tue Sep 22 19:52:59 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 22 Sep 2020 19:52:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8252195: AWT Accessibility API nested classes rely on default constructors [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 16:08:12 GMT, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8252195 >> is another one of the issues adding missing explicit no-args constructors in the desktop module. >> >> As well as being nested, these are all concrete, but protected, classes and so the constructors >> are protected. >> >> CSR here https://bugs.openjdk.java.net/browse/JDK-8253450 needs a reviewer too. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8252195: AWT Accessibility API nested classes rely on default constructors Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/288 From prr at openjdk.java.net Tue Sep 22 22:17:46 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 22 Sep 2020 22:17:46 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8252195: AWT Accessibility API nested classes rely on default constructors In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 20:17:36 GMT, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8252195 > is another one of the issues adding missing explicit no-args constructors in the desktop module. > > As well as being nested, these are all concrete, but protected, classes and so the constructors > are protected. > > CSR here https://bugs.openjdk.java.net/browse/JDK-8253450 needs a reviewer too. This pull request has now been integrated. Changeset: 93a2018d Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/93a2018d Stats: 100 lines in 18 files changed: 0 ins; 100 del; 0 mod 8252195: AWT Accessibility API nested classes rely on default constructors Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/288 From serb at openjdk.java.net Wed Sep 23 07:54:19 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 23 Sep 2020 07:54:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253322 : Update the specification added to some of some newly added constructors Message-ID: Looks like different people use a different style for the new constructors, it will be good to unify them. I have started from https://bugs.openjdk.java.net/browse/JDK-8252721 See https://bugs.openjdk.java.net/browse/JDK-8252908?focusedCommentId=14370006&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14370006 But since I already touched a bunch of classes, I decided to update some other fixes as well. This will update the changes for: https://bugs.openjdk.java.net/browse/JDK-8252721 https://bugs.openjdk.java.net/browse/JDK-8252195 https://bugs.openjdk.java.net/browse/JDK-8250858 ------------- Commit messages: - update the JDK-8250858 - Update the JDK-8252195 - update the JDK-8252721 Changes: https://git.openjdk.java.net/jdk/pull/315/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=315&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253322 Stats: 152 lines in 67 files changed: 15 ins; 0 del; 137 mod Patch: https://git.openjdk.java.net/jdk/pull/315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/315/head:pull/315 PR: https://git.openjdk.java.net/jdk/pull/315 From psadhukhan at openjdk.java.net Wed Sep 23 08:45:24 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 23 Sep 2020 08:45:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253322 : Update the specification in the newly added constructors In-Reply-To: References: Message-ID: <5DsJaueJzOQ7k0uf9c5TtcJWMeH-E6jcOyXiP1QE9G8=.8e38909f-248e-4c45-a117-5a55e4f70541@github.com> On Wed, 23 Sep 2020 07:03:59 GMT, Sergey Bylokhov wrote: > Looks like different people use a different style for the new constructors, it will be good to unify them. > I have started from https://bugs.openjdk.java.net/browse/JDK-8252721 > See > https://bugs.openjdk.java.net/browse/JDK-8252908?focusedCommentId=14370006&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14370006 > > But since I already touched a bunch of classes, I decided to update some other fixes as well. > > This will update the changes for: > https://bugs.openjdk.java.net/browse/JDK-8252721 > https://bugs.openjdk.java.net/browse/JDK-8252195 > https://bugs.openjdk.java.net/browse/JDK-8250858 Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/315 From prr at openjdk.java.net Wed Sep 23 19:34:50 2020 From: prr at openjdk.java.net (Phil Race) Date: Wed, 23 Sep 2020 19:34:50 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253322 : Update the specification in the newly added constructors In-Reply-To: References: Message-ID: <69P7vOGOUOX8tI47cIO-4G3lbjXN25_gVdPUHMER644=.839e4271-b133-4a30-903c-628f5926b660@github.com> On Wed, 23 Sep 2020 07:03:59 GMT, Sergey Bylokhov wrote: > Looks like different people use a different style for the new constructors, it will be good to unify them. > I have started from https://bugs.openjdk.java.net/browse/JDK-8252721 > See > https://bugs.openjdk.java.net/browse/JDK-8252908?focusedCommentId=14370006&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14370006 > > But since I already touched a bunch of classes, I decided to update some other fixes as well. > > This will update the changes for: > https://bugs.openjdk.java.net/browse/JDK-8252721 > https://bugs.openjdk.java.net/browse/JDK-8252195 > https://bugs.openjdk.java.net/browse/JDK-8250858 I don't think we should have to deduce what are all the "styles" you are proposing. The PR AND the bug should both say things like 1. Add a period (full stop) to the end of all javadoc comments. .. and so forth. otherwise where will be the record other than the scattered changes themselves ? Please summarise along those lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/315 From serb at openjdk.java.net Wed Sep 23 22:52:19 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 23 Sep 2020 22:52:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253322 : Update the specification in the newly added constructors In-Reply-To: <69P7vOGOUOX8tI47cIO-4G3lbjXN25_gVdPUHMER644=.839e4271-b133-4a30-903c-628f5926b660@github.com> References: <69P7vOGOUOX8tI47cIO-4G3lbjXN25_gVdPUHMER644=.839e4271-b133-4a30-903c-628f5926b660@github.com> Message-ID: On Wed, 23 Sep 2020 19:31:28 GMT, Phil Race wrote: > otherwise where will be the record other than the scattered changes themselves ? > Please summarise along those lines. The description is updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/315 From prr at openjdk.java.net Wed Sep 23 23:24:49 2020 From: prr at openjdk.java.net (Phil Race) Date: Wed, 23 Sep 2020 23:24:49 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253322 : Update the specification in the newly added constructors In-Reply-To: References: Message-ID: <_Pac9-OCb-L3zYjzB1WPcs_ugW5-ksqdbwnmLgTiaWk=.3e2d4212-65b4-4d15-98aa-8bb05bca3bda@github.com> On Wed, 23 Sep 2020 07:03:59 GMT, Sergey Bylokhov wrote: > Looks like different people use a different style for the new constructors, it will be good to unify them. > > The text "Constructor for subclasses to call." should be used in the protected constructors in the abstract classes > In all other cases the text "Constructs an {@code ClassName}." should be used > A period (full stop) to the end of all javadoc comments, should be added if it is missing > > I have started from https://bugs.openjdk.java.net/browse/JDK-8252721 > See > https://bugs.openjdk.java.net/browse/JDK-8252908?focusedCommentId=14370006&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14370006 > > But since I already touched a bunch of classes, I decided to update some other fixes as well. > > This will update the changes for: > https://bugs.openjdk.java.net/browse/JDK-8252721 > https://bugs.openjdk.java.net/browse/JDK-8252195 > https://bugs.openjdk.java.net/browse/JDK-8250858 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/315 From vipinmv1 at in.ibm.com Thu Sep 24 15:28:00 2020 From: vipinmv1 at in.ibm.com (Vipin Mv1) Date: Thu, 24 Sep 2020 15:28:00 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray In-Reply-To: <5F6A4B59.8010405@oracle.com> References: <5F6A4B59.8010405@oracle.com>, , <5F4BD451.9020200@oracle.com>, <5F47FD26.8090307@oracle.com> <5F4A9A23.9030002@oracle.com> Message-ID: Hi Philip, Thanks for your time in getting back. I will pursue it further through github. Thanks & regards Vipin MV From ccleary at openjdk.java.net Thu Sep 24 16:09:52 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Thu, 24 Sep 2020 16:09:52 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8250859: Address reliance on default constructors in the Accessibility APIs In-Reply-To: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: <3FqU0WjqVGbE97ym1wO3Fxi-VbaV10JQbjBRPUsKdkU=.3df8563d-59fc-4696-b077-261ff0a81096@github.com> On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 This pull request has now been integrated. Changeset: a9d04408 Author: Conor Cleary Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/a9d04408 Stats: 47 lines in 8 files changed: 39 ins; 0 del; 8 mod 8250859: Address reliance on default constructors in the Accessibility APIs Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/174 From ccleary at openjdk.java.net Thu Sep 24 16:10:53 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Thu, 24 Sep 2020 16:10:53 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8250855: Address reliance on default constructors in the Java 2D APIs In-Reply-To: References: Message-ID: <4-bJDAvMsU-U8uSQ8UD4a-auBj-hqfUBu_hqcaj9mWI=.eee43585-fd05-4f6a-91b9-c58841bcd9f8@github.com> On Mon, 14 Sep 2020 14:32:18 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The changes > address the reliance on default constructors by adding in basic constructors in the following classes: > - java.awt.Image > - java.awt.PrintJob > - java.awt.font.GlyphVector > - java.awt.font.LayoutPath > - java.awt.font.LineMetrics > - java.awt.image.AbstractMultiResolutionImage > - java.awt.image.BufferStrategy > - java.awt.image.ImageFilter > - java.awt.image.RGBImageFilter > - java.awt.image.VolatileImage > - javax.print.PrintServiceLookup > - javax.print.ServiceUI > - javax.print.ServiceUIFactory > - javax.print.StreamPrintServiceFactory > - javax.print.event.PrintJobAdapter > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.02/specdiff/overview-summary.html csr: > https://bugs.openjdk.java.net/browse/JDK-8252495 This pull request has now been integrated. Changeset: 3495c19d Author: Conor Cleary Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/3495c19d Stats: 85 lines in 14 files changed: 71 ins; 0 del; 14 mod 8250855: Address reliance on default constructors in the Java 2D APIs Reviewed-by: prr, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/153 From prr at openjdk.java.net Thu Sep 24 16:50:43 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Sep 2020 16:50:43 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. Message-ID: A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. The new test can directly test printing to file in an automated way - so long as there is a printer. The updated manual test can be used to verify the cross-platform dialog case. ------------- Commit messages: - 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead Changes: https://git.openjdk.java.net/jdk/pull/339/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=339&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7179006 Stats: 242 lines in 4 files changed: 173 ins; 51 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/339.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/339/head:pull/339 PR: https://git.openjdk.java.net/jdk/pull/339 From prr at openjdk.java.net Thu Sep 24 16:50:45 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Sep 2020 16:50:45 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 16:38:50 GMT, Phil Race wrote: > A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 > > The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. > > Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. > > The new test can directly test printing to file in an automated way - so long as there is a printer. > > The updated manual test can be used to verify the cross-platform dialog case. label /remove awt ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From serb at openjdk.java.net Thu Sep 24 17:15:15 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 24 Sep 2020 17:15:15 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253606: Need to add missed constructor to the SwingEventMonitor Message-ID: The javadoc for this class was added, but the constructor itsef is missed...... ------------- Commit messages: - Update SwingEventMonitor.java Changes: https://git.openjdk.java.net/jdk/pull/340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253606 Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/340/head:pull/340 PR: https://git.openjdk.java.net/jdk/pull/340 From phh at openjdk.java.net Thu Sep 24 21:36:59 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Thu, 24 Sep 2020 21:36:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: Please review this small patch to enable the OSX build using Xcode 12.0. Thanks, Paul ------------- Commit messages: - JDK-8253375 Changes: https://git.openjdk.java.net/jdk/pull/348/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253375 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348 PR: https://git.openjdk.java.net/jdk/pull/348 From prr at openjdk.java.net Thu Sep 24 21:51:19 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Sep 2020 21:51:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul The awt change looks fine although it would be nice if you could paste the compiler error message into the bug report, since I'd like to see the compiler's reason why this is ambiguous today and not before - assuming that is the issue. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From serb at openjdk.java.net Thu Sep 24 22:52:50 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 24 Sep 2020 22:52:50 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8253322 : Update the specification in the newly added constructors In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 07:03:59 GMT, Sergey Bylokhov wrote: > Looks like different people use a different style for the new constructors, it will be good to unify them. > > The text "Constructor for subclasses to call." should be used in the protected constructors in the abstract classes > In all other cases the text "Constructs an {@code ClassName}." should be used > A period (full stop) to the end of all javadoc comments, should be added if it is missing > > I have started from https://bugs.openjdk.java.net/browse/JDK-8252721 > See > https://bugs.openjdk.java.net/browse/JDK-8252908?focusedCommentId=14370006&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14370006 > > But since I already touched a bunch of classes, I decided to update some other fixes as well. > > This will update the changes for: > https://bugs.openjdk.java.net/browse/JDK-8252721 > https://bugs.openjdk.java.net/browse/JDK-8252195 > https://bugs.openjdk.java.net/browse/JDK-8250858 This pull request has now been integrated. Changeset: 8239b67d Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/8239b67d Stats: 152 lines in 67 files changed: 15 ins; 0 del; 137 mod 8253322: Update the specification in the newly added constructors Reviewed-by: psadhukhan, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/315 From serb at openjdk.java.net Fri Sep 25 01:52:34 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 25 Sep 2020 01:52:34 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 16:38:50 GMT, Phil Race wrote: > A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 > > The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. > > Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. > > The new test can directly test printing to file in an automated way - so long as there is a printer. > > The updated manual test can be used to verify the cross-platform dialog case. src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 441: > 439: NSURL *nsURL = [NSURL fileURLWithPath:nsDestStr isDirectory:NO]; > 440: [printingDictionary setObject:nsURL forKey:NSPrintJobSavingURL]; > 441: // JNFCallVoidMethod(env, dstPrinterJob, jm_setPrintToFile, true); Does it look like the commented lines are not needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From dholmes at openjdk.java.net Fri Sep 25 02:26:32 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 25 Sep 2020 02:26:32 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/sharedRuntime.cpp line 2851: > 2849: if (buf != NULL) { > 2850: CodeBuffer buffer(buf); > 2851: short locs_buf[80]; This code is just weird. Why is the buf array not declared to be the desired type? If the compiler rejects double because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From psadhukhan at openjdk.java.net Fri Sep 25 04:33:01 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 25 Sep 2020 04:33:01 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 16:38:50 GMT, Phil Race wrote: > A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 > > The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. > > Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. > > The new test can directly test printing to file in an automated way - so long as there is a printer. > > The updated manual test can be used to verify the cross-platform dialog case. test/jdk/java/awt/print/PrinterJob/PrintToFileTest.java line 60: > 58: if (!file.exists()) { > 59: throw new RuntimeException("No file created"); > 60: } I guess we need to delete the file in finally block, if created. ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From psadhukhan at openjdk.java.net Fri Sep 25 05:00:39 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 25 Sep 2020 05:00:39 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 16:38:50 GMT, Phil Race wrote: > A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 > > The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. > > Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. > > The new test can directly test printing to file in an automated way - so long as there is a printer. > > The updated manual test can be used to verify the cross-platform dialog case. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 257: > 255: > 256: private void setDestinationFile(String dest) { > 257: System.out.println("dest="+dest+" attrs="+attributes); Probably this println should be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From kbarrett at openjdk.java.net Fri Sep 25 05:49:08 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 25 Sep 2020 05:49:08 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul No, don't do this. In the original, double is used to obtain the desired alignmnent. Changing the element type to short reduces the alignment requirement for the variable. initialize_shared_locs will then adjust the alignment, potentially shrinking the effective array size. So this is a real change that I think shouldn't be made. I think changing the declaration for locs_buf to any of the following gives equivalent behavior to the current code. I don't know whether any of them will trigger the new clang warning though. I don't have access to that version right now, and the documentation for the warning is useless (like so much of clang's warning options documentation). (1) alignas(double) char locs_buf[20 * sizeof(double)]; (but alignas is not yet in the "permitted features" list in the Style Guide: https://bugs.openjdk.java.net/browse/JDK-8252584) (2) union { char locs_buf[20 * sizeof(double)]; double align; }; (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf and #include This has the benefit of being explicit that we're just stack allocating a block of storage. I'll make a wild guess that (1) and (2) will still warn, though char arrays are somewhat special in the language so maybe they won't. I'm pretty sure (3) should do the trick. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From kbarrett at openjdk.java.net Fri Sep 25 06:09:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 25 Sep 2020 06:09:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: > 127: NSColor* result = nil; > 128: > 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : > java_awt_SystemColor_NUM_COLORS)) { This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues related to the compiler upgrade. Someone might want to backport just this fix, for example. ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Fri Sep 25 06:12:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 02:12:27 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <26D262B7-A73B-450D-8789-16F33B950379@oracle.com> > On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul [I tried submitting this comment through the github UI and somehow managed to lose all the context in the process. In case it?s not (eventually) obvious, this is about the change to src/hotspot/share/runtime/sharedRuntime.cpp. Still figuring out github?] > No, don't do this. In the original, double is used to obtain the desired > alignmnent. Changing the element type to short reduces the alignment > requirement for the variable. initialize_shared_locs will then adjust the > alignment, potentially shrinking the effective array size. So this is a > real change that I think shouldn't be made. > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. I don't know whether any of them > will trigger the new clang warning though. I don't have access to that > version right now, and the documentation for the warning is useless (like so > much of clang's warning options documentation). > > (1) alignas(double) char locs_buf[20 * sizeof(double)]; > (but alignas is not yet in the "permitted features" list in the Style Guide: > https://bugs.openjdk.java.net/browse/JDK-8252584) > > (2) union { char locs_buf[20 * sizeof(double)]; double align; }; > > (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; > and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf > and #include > This has the benefit of being explicit that we're just stack allocating a > block of storage. > > I'll make a wild guess that (1) and (2) will still warn, though char arrays > are somewhat special in the language so maybe they won't. I'm pretty sure > (3) should do the trick. > > ------------- > > Changes requested by kbarrett (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Fri Sep 25 08:00:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 04:00:48 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <0CC7FB67-55D9-4E7F-9B45-BA7FD6E3BE43@oracle.com> > On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > [?] > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. [?] > > [?] Another variant that probably avoids both the warning and avoids any C++14 features: (4) union { char data[20 * sizeof(double)]; double align; } locs_buf; and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf. > ------------- > > Changes requested by kbarrett (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From lucy at openjdk.java.net Fri Sep 25 10:22:08 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 25 Sep 2020 10:22:08 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > No, don't do this. In the original, double is used to obtain the desired > alignmnent. Changing the element type to short reduces the alignment > requirement for the variable. initialize_shared_locs will then adjust the > alignment, potentially shrinking the effective array size. So this is a > real change that I think shouldn't be made. > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. I don't know whether any of them > will trigger the new clang warning though. I don't have access to that > version right now, and the documentation for the warning is useless (like so > much of clang's warning options documentation). > > (1) alignas(double) char locs_buf[20 * sizeof(double)]; > (but alignas is not yet in the "permitted features" list in the Style Guide: > https://bugs.openjdk.java.net/browse/JDK-8252584) > > (2) union { char locs_buf[20 * sizeof(double)]; double align; }; > > (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; > and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf > and #include > This has the benefit of being explicit that we're just stack allocating a > block of storage. > > I'll make a wild guess that (1) and (2) will still warn, though char arrays > are somewhat special in the language so maybe they won't. I'm pretty sure > (3) should do the trick. I checked Kim Barrett's proposals (1) and (2) on my machine (MacOS 10.15, Xcode 12.0). Both proposals make the warning go away. Another note, actually, it's more like a question: Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* buf, int length)? To my understanding, "buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is that a good idea? "locs_buf" points into the stack. This pointer becomes invalid at the end of the "locs_buf" scope. Did I get something wrong here? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Fri Sep 25 10:37:08 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 06:37:08 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <7298FBE4-01E9-4857-B213-B2A7F0A41621@oracle.com> > On Sep 25, 2020, at 6:22 AM, Lutz Schmidt wrote: > > On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote: > > Another note, actually, it's more like a question: > Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* buf, int length)? To my understanding, > "buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is that a good idea? "locs_buf" points into > the stack. This pointer becomes invalid at the end of the "locs_buf" scope. Did I get something wrong here? It?s ?odd? but I think it?s more or less okay. Here and in other uses we seem to be allocating dynamically scoped storage for temporary use by the CodeBuffer. I think a more normal formulation might be to allocate the buffer, then pass it to the CodeBuffer constructor as a non-transfer of ownership. But I haven?t looked at all the places where this is used, and that?s perhaps out of scope for the problem at hand. > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From prr at openjdk.java.net Fri Sep 25 18:30:08 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 25 Sep 2020 18:30:08 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 01:32:49 GMT, Sergey Bylokhov wrote: >> A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 >> >> The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. >> >> Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. >> >> The new test can directly test printing to file in an automated way - so long as there is a printer. >> >> The updated manual test can be used to verify the cross-platform dialog case. > > src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 441: > >> 439: NSURL *nsURL = [NSURL fileURLWithPath:nsDestStr isDirectory:NO]; >> 440: [printingDictionary setObject:nsURL forKey:NSPrintJobSavingURL]; >> 441: // JNFCallVoidMethod(env, dstPrinterJob, jm_setPrintToFile, true); > > Does it look like the commented lines are not needed? Hmm. I could swear I removed those and re-ordered the first two lines as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From prr at openjdk.java.net Fri Sep 25 18:30:09 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 25 Sep 2020 18:30:09 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: <8UrmSSDmJEgnMuaF2uHs1rNZ4i2T-9O6Nxfq0EEpzPM=.1304b78d-eefc-4c21-9e18-aaa9931d22e8@github.com> On Fri, 25 Sep 2020 04:57:48 GMT, Prasanta Sadhukhan wrote: >> A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 >> >> The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. >> >> Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. >> >> The new test can directly test printing to file in an automated way - so long as there is a printer. >> >> The updated manual test can be used to verify the cross-platform dialog case. > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 257: > >> 255: >> 256: private void setDestinationFile(String dest) { >> 257: System.out.println("dest="+dest+" attrs="+attributes); > > Probably this println should be removed. oops > test/jdk/java/awt/print/PrinterJob/PrintToFileTest.java line 60: > >> 58: if (!file.exists()) { >> 59: throw new RuntimeException("No file created"); >> 60: } > > I guess we need to delete the file in finally block, if created. I meant to leave it. So we can look at it if we need to. ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From prr at openjdk.java.net Fri Sep 25 18:47:40 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 25 Sep 2020 18:47:40 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. [v2] In-Reply-To: References: Message-ID: > A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 > > The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. > > Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. > > The new test can directly test printing to file in an automated way - so long as there is a printer. > > The updated manual test can be used to verify the cross-platform dialog case. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/339/files - new: https://git.openjdk.java.net/jdk/pull/339/files/048c7eeb..0165ae2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=339&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=339&range=00-01 Stats: 7 lines in 4 files changed: 2 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/339.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/339/head:pull/339 PR: https://git.openjdk.java.net/jdk/pull/339 From serb at openjdk.java.net Fri Sep 25 21:37:41 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 25 Sep 2020 21:37:41 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. [v2] In-Reply-To: References: Message-ID: <3mXkYVizM5eulPbUkh0w2Bh1NNY3s_-oP3jThKqq52o=.b7128d7b-a27f-4b4b-804c-d2da2847357b@github.com> On Fri, 25 Sep 2020 18:47:40 GMT, Phil Race wrote: >> A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 >> >> The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. >> >> Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. >> >> The new test can directly test printing to file in an automated way - so long as there is a printer. >> >> The updated manual test can be used to verify the cross-platform dialog case. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 261: > 259: URI destURI = new URI(dest); > 260: attributes.add(new Destination(destURI)); > 261: destinationAttr = "" + destURI.getSchemeSpecificPart(); This destinationAttr in the RasterPrinterJob is usually assigned to: destinationAttr = "" + new File(destination.getURI(). getSchemeSpecificPart()); Do we need to do the same here? src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 337: > 335: } > 336: > 337: // get the selected printer's name, and set the appropriate PrintService on the Java side The comment need to be moved up as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From serb at openjdk.java.net Fri Sep 25 22:00:42 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 25 Sep 2020 22:00:42 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments Message-ID: We have a number of missing javadoc tags and comments in the desktop module. Most of the missing comments are related to the serialized form. The fix: - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes - Adds comments to the "serializable" classes even if those classes are non-public - Fixes references/adds missing tags to the special methods(like readObject/writeObject) - Delete the java.awt.PeerFixer class. I need advice about what exact change should be reviewed in the CSR(except PeerFixer removal) Note that in some cases I added the comments to the "implementation details", so I did not specify it fully. The old review request: https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html ------------- Commit messages: - 8251123: doclint warnings about missing javadoc tags and comments Changes: https://git.openjdk.java.net/jdk/pull/369/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=369&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251123 Stats: 1306 lines in 69 files changed: 810 ins; 214 del; 282 mod Patch: https://git.openjdk.java.net/jdk/pull/369.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/369/head:pull/369 PR: https://git.openjdk.java.net/jdk/pull/369 From prr at openjdk.java.net Fri Sep 25 23:44:27 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 25 Sep 2020 23:44:27 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. [v3] In-Reply-To: References: Message-ID: > A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 > > The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. > > Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. > > The new test can directly test printing to file in an automated way - so long as there is a printer. > > The updated manual test can be used to verify the cross-platform dialog case. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/339/files - new: https://git.openjdk.java.net/jdk/pull/339/files/0165ae2e..ff4c7835 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=339&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=339&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/339.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/339/head:pull/339 PR: https://git.openjdk.java.net/jdk/pull/339 From prr at openjdk.java.net Fri Sep 25 23:44:28 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 25 Sep 2020 23:44:28 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: <8ssZfMrVrfFr6qd7nIwwmsWsNSHIa26nuS3begurEoE=.9dba42d3-63c2-45c2-bc08-01216f840d35@github.com> On Thu, 24 Sep 2020 16:43:48 GMT, Phil Race wrote: >> A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 >> >> The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. >> >> Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. >> >> The new test can directly test printing to file in an automated way - so long as there is a printer. >> >> The updated manual test can be used to verify the cross-platform dialog case. > > label /remove awt Updated with the comment moved. ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From prr at openjdk.java.net Fri Sep 25 23:44:31 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 25 Sep 2020 23:44:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. [v2] In-Reply-To: <3mXkYVizM5eulPbUkh0w2Bh1NNY3s_-oP3jThKqq52o=.b7128d7b-a27f-4b4b-804c-d2da2847357b@github.com> References: <3mXkYVizM5eulPbUkh0w2Bh1NNY3s_-oP3jThKqq52o=.b7128d7b-a27f-4b4b-804c-d2da2847357b@github.com> Message-ID: On Fri, 25 Sep 2020 21:31:01 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 261: > >> 259: URI destURI = new URI(dest); >> 260: attributes.add(new Destination(destURI)); >> 261: destinationAttr = "" + destURI.getSchemeSpecificPart(); > > This destinationAttr in the RasterPrinterJob is usually assigned to: > destinationAttr = "" + new File(destination.getURI(). > getSchemeSpecificPart()); > Do we need to do the same here? I see that in WPrinterJob.java we do the same as I am doing here. I think the difference in RPJ may bethat we want to get a full path name which is what the new File did. Here macOS gives us a full path name already. So I don't think it is needed. It gave the required value for sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From serb at openjdk.java.net Sat Sep 26 00:51:57 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 26 Sep 2020 00:51:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 23:44:27 GMT, Phil Race wrote: >> A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 >> >> The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. >> >> Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. >> >> The new test can directly test printing to file in an automated way - so long as there is a printer. >> >> The updated manual test can be used to verify the cross-platform dialog case. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From prr at openjdk.java.net Sat Sep 26 04:18:27 2020 From: prr at openjdk.java.net (Phil Race) Date: Sat, 26 Sep 2020 04:18:27 GMT Subject: [OpenJDK 2D-Dev] Integrated: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 16:38:50 GMT, Phil Race wrote: > A long-standing bug on macOS: https://bugs.openjdk.java.net/browse/JDK-7179006 > > The fix is to propagate whatever is set as the Destination down to native and set it on the native printing object. > > Also if using the native dialog, but with attributes, copy back the destination from native to the Java attribute set. > > The new test can directly test printing to file in an automated way - so long as there is a printer. > > The updated manual test can be used to verify the cross-platform dialog case. This pull request has now been integrated. Changeset: ea7c47c1 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/ea7c47c1 Stats: 239 lines in 4 files changed: 170 ins; 50 del; 19 mod 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead. Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/339 From serb at openjdk.java.net Sun Sep 27 22:47:11 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 27 Sep 2020 22:47:11 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) Message-ID: Hello. Please review the fix for jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8211999 Fix: http://cr.openjdk.java.net/~serb/8211999/webrev.04 Old review request: https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for Windows 7, because it does not support different DPI for different monitors) ======================================================== Short description: In the multi-screen configurations when each screen have different DPI we calculate the bounds of each monitor by these formulas: userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY devSpaceBounds = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY This formula makes the next configuration completely broken: - The main screen on the left and 100% DPI - The second screen on the right and 200% DPI When we translate the bounds of the config from the device space to the user's space, the bounds of both screen overlap in the user's space, because we use bounds of the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y. Since the screens are overlapped we cannot be sure how to translate the user's space coordinates to device space in the overlapped zone. As a result => we use the wrong screen => got wrong coordinates in the device space => show top-level windows/popups/tooltips/menus/etc on the wrong screen The proposed solution for this bug is to change the formulas to these: userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY devSpaceBounds = userX, userY, userW * scaleX, userH * scaleY In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will complicate the way of how we transform coordinates on the screen: user's <--> device spaces: Before the fix: userX = deviceX * scaleX; deviceX = userX / scaleX; After the fix(only the part appeared on this screen should be scaled) userX = screenX + (deviceX - screenX) * scaleX deviceX = screenX + (userX - screenX) / scaleX Note that these new formulas are applicable only for the coordinates on the screen such as X and Y. If we will need to calculate the "size" such as W and H then the old formula should be used. The main changes for the problem above are: - Skip transformation of X and Y of the screen bounds: http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html - A number of utility methods in java and native: http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html ======================================================== Long description: Unfortunately, the changes above are not enough to fix the problem when different monitors have different DPI, even if the bounds are *NOT* overlapped. - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the expected device position based on the current GraphicsConfiguration of the peer, and then additionally, tweak it in native using the device scale stored in native code. Unfortunately this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer, the config might be changed and the tweak in native will use a different screen). As a fix I have moved all transformation from the peer to the native code, it will be executed on the toolkit thread: See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html I think at some point we should delete all transformation in java, and apply it in the native code only. - We had a special code that tracked the dragging of the window by the user from one screen to another, and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a workaround for https://bugs.openjdk.java.net/browse/JDK-8249164 - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows. See the end of void AwtWindow::Reshape(): http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html - Currently the HW componets such as Canvas scales everything based on such code: 770 int AwtComponent::ScaleUpX(int x) { 4771 int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd()); 4772 Devices::InstanceAccess devices; 4773 AwtWin32GraphicsDevice* device = devices->GetDevice(screen); 4774 return device == NULL ? x : device->ScaleUpX(x); 4775 } But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200 As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn: http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size. As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds(): http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the Robot class, on windows we will use the new logic, on other platforms the old logic will be used. - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used. ======================================================== Some other bugs which are not fixed. - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space. For example when we create the component we read x/y/width/height by the JNI(of course in a user's space) but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently because later we reshape the component to the correct bounds. Will fix it later. - When the frame is iconized and we try to save a new bounds for the future use, we store the coordinates in the user's space to the field which use device space: https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664 Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues. ======================================================== The tests - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs in my initial implementation - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest ======================================================== I have run jck, regression tests in different configurations, when the main screen is on the left, up, down, right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far. The mach5 is also green. PS: hope I did not forget some important information, will send it later if any. ------------- Commit messages: - Update FullscreenWindowProps.java - Merge branch 'master' into JDK-8211999 - Fix fullscreen in HiDPI mode - self review - Initial fix version Changes: https://git.openjdk.java.net/jdk/pull/375/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=375&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211999 Stats: 1401 lines in 35 files changed: 967 ins; 280 del; 154 mod Patch: https://git.openjdk.java.net/jdk/pull/375.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/375/head:pull/375 PR: https://git.openjdk.java.net/jdk/pull/375 From jdv at openjdk.java.net Mon Sep 28 06:33:37 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Mon, 28 Sep 2020 06:33:37 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote: > We have a number of missing javadoc tags and comments in the desktop module. > Most of the missing comments are related to the serialized form. > > The fix: > - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes > - Adds comments to the "serializable" classes even if those classes are non-public > - Fixes references/adds missing tags to the special methods(like readObject/writeObject) > - Delete the java.awt.PeerFixer class. > > I need advice about what exact change should be reviewed in the CSR(except PeerFixer removal) > > Note that in some cases I added the comments to the "implementation details", so I did not specify it fully. > > The old review request: > https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html Inputs from https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000424.html are incorporated or is this fresh git review? ------------- PR: https://git.openjdk.java.net/jdk/pull/369 From serb at openjdk.java.net Mon Sep 28 07:52:48 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 28 Sep 2020 07:52:48 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 06:30:31 GMT, Jayathirth D V wrote: > Inputs from https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000424.html are incorporated or is this fresh > git review? It is a fresh update, it changes from the old review request. I made it less "dangerous". ------------- PR: https://git.openjdk.java.net/jdk/pull/369 From kizune at openjdk.java.net Mon Sep 28 15:47:28 2020 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 28 Sep 2020 15:47:28 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons Message-ID: Moving review from Mercurial. See https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016078.html for previous iteration. ------------- Commit messages: - emoved whitespaces from test - 8182043: Access to Windows Large Icons Changes: https://git.openjdk.java.net/jdk/pull/380/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=380&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8182043 Stats: 336 lines in 6 files changed: 270 ins; 25 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/380/head:pull/380 PR: https://git.openjdk.java.net/jdk/pull/380 From mbaesken at openjdk.java.net Tue Sep 29 07:14:29 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 07:14:29 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: > >> 127: NSColor* result = nil; >> 128: >> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >> java_awt_SystemColor_NUM_COLORS)) { > > This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just > has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues > related to the compiler upgrade. Someone might want to backport just this fix, for example. Hello Kim, Paul - so should we open a separate bug for the src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for the useAppleColor check in CSystemColors.m ? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From mbaesken at openjdk.java.net Tue Sep 29 07:59:05 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 07:59:05 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> References: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> Message-ID: On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > src/hotspot/share/runtime/sharedRuntime.cpp line 2851: > >> 2849: if (buf != NULL) { >> 2850: CodeBuffer buffer(buf); >> 2851: short locs_buf[80]; > > This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double > because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or > int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely on all supported compilers and on Xcode 12 as well ,see c1_Compilation.cpp 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, sharedRuntime.cpp 2681 CodeBuffer buffer(buf); 2682 short buffer_locs[20]; 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, 2684 sizeof(buffer_locs)/sizeof(relocInfo)); So probably using short would be consistent to what we do already in the coding at another place (looking into relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class and use the typedef). ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 11:22:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 07:22:48 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <751EE42A-4A0F-45EB-88EA-FD7A2B068CD2@oracle.com> > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 12:02:11 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 08:02:11 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> Message-ID: <20D716A9-C5BC-47A3-ADB4-CBA732A94DF6@oracle.com> > On Sep 29, 2020, at 3:59 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/hotspot/share/runtime/sharedRuntime.cpp line 2851: >> >>> 2849: if (buf != NULL) { >>> 2850: CodeBuffer buffer(buf); >>> 2851: short locs_buf[80]; >> >> This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double >> because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or >> int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? > > Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely > on all supported compilers and on Xcode 12 as well ,see > > c1_Compilation.cpp > > 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); > 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, > > sharedRuntime.cpp > > 2681 CodeBuffer buffer(buf); > 2682 short buffer_locs[20]; > 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > 2684 sizeof(buffer_locs)/sizeof(relocInfo)); > > So probably using short would be consistent to what we do already in the coding at another place (looking into > relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class > and use the typedef). That?s *not* consistent, because of buffer alignment. The call to NEW_RESOURCE_ARRAY is going to return a pointer to memory that is 2*word aligned. (Interesting, possibly a 32/64 bit ?bug? here.) The existing code in sharedRuntime.cpp is allocating double-aligned. iniitalize_shared_locs wants a HeapWordSize-aligned buffer, and adjusts the pointer it uses accordingly. (I think with existing code it could just make the alignment of the buffer a precondition, but I haven?t looked at all callers.) Changing the declaration in sharedRuntime.cpp to short[] reduces the alignment requirement for the array, possibly requiring alignment adjustment (and hence size reduction) by initialize_shared_locs. Since initialize_shared_locs specifically adjusts the alignment, some downstream use of the buffer probably actually cares. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From hohensee at amazon.com Tue Sep 29 13:46:27 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 13:46:27 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Thanks, Paul ?On 9/29/20, 4:23 AM, "hotspot-dev on behalf of Kim Barrett" wrote: > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From mbaesken at openjdk.java.net Tue Sep 29 14:09:25 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 14:09:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 07:11:34 GMT, Matthias Baesken wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I created https://bugs.openjdk.java.net/browse/JDK-8253791 8253791: Issue with useAppleColor check in CSystemColors.m for this issue (Kim and Paul are fine to have a separate JBS issue for this) ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From hohensee at amazon.com Tue Sep 29 14:18:18 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 14:18:18 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: Thanks for the reviews/discussion, and apologies for the delayed reply: I've been OOTO. Kim is correct, initialize_shared_locs specifically adjusts the alignment of its buffer argument, which is why short works. char would work as well, but short happens to be the size of a relocInfo. Maybe the author of the other use in sharedRuntime.cpp at line 2682 used short to remind of that. Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have int locs_buffer_size = 20 * (relocInfo::length_limit + sizeof(relocInfo)); char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, locs_buffer_size / sizeof(relocInfo)); relocInfo::length_limit is a count of shorts, while sizeof(relocInfo) is a count of chars. The units aren?t the same but are added together as if they were. relocInfo::length_limit is supposed to be the maximum size of a compressed relocation record, so why add sizeof(relocInfo)? And then in sharedRuntime.cpp, we have two places. The first: short buffer_locs[20]; buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, sizeof(buffer_locs)/sizeof(relocInfo)); relocInfo::length_limit is 15 on a 64-bit machine, so with a buffer of 20 shorts, alignment in initialize_shared_locs might take up to of 3 more, which is uncomfortably close to 20 afaic. And, if you add sizeof(relocInfo) as happens in c1_Compilation.cpp, you're bang on at 20. The unstated assumption seems to be that only a single relocation record will be needed. The second: double locs_buf[20]; buffer.insts()->initialize_shared_locs((relocInfo*)locs_buf, sizeof(locs_buf) / sizeof(relocInfo)); This at allocates a buffer that will hold 5 compressed relocation records with 10 bytes left over, and guarantees 8 byte alignment. Perhaps when it was written, initialize_shared_locs didn't align its buffer argument address. And, there's that sizeof(relocInfo) padding again: 2 extra bytes per relocation record. Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). So, for the sharedRuntime patch, would it be ok to just use short locs_buf[84]; to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Thanks, Paul ?On 9/29/20, 5:03 AM, "2d-dev on behalf of Kim Barrett" <2d-dev-retn at openjdk.java.net on behalf of kim.barrett at oracle.com> wrote: > On Sep 29, 2020, at 3:59 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/hotspot/share/runtime/sharedRuntime.cpp line 2851: >> >>> 2849: if (buf != NULL) { >>> 2850: CodeBuffer buffer(buf); >>> 2851: short locs_buf[80]; >> >> This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double >> because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or >> int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? > > Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely > on all supported compilers and on Xcode 12 as well ,see > > c1_Compilation.cpp > > 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); > 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, > > sharedRuntime.cpp > > 2681 CodeBuffer buffer(buf); > 2682 short buffer_locs[20]; > 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > 2684 sizeof(buffer_locs)/sizeof(relocInfo)); > > So probably using short would be consistent to what we do already in the coding at another place (looking into > relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class > and use the typedef). That?s *not* consistent, because of buffer alignment. The call to NEW_RESOURCE_ARRAY is going to return a pointer to memory that is 2*word aligned. (Interesting, possibly a 32/64 bit ?bug? here.) The existing code in sharedRuntime.cpp is allocating double-aligned. iniitalize_shared_locs wants a HeapWordSize-aligned buffer, and adjusts the pointer it uses accordingly. (I think with existing code it could just make the alignment of the buffer a precondition, but I haven?t looked at all callers.) Changing the declaration in sharedRuntime.cpp to short[] reduces the alignment requirement for the array, possibly requiring alignment adjustment (and hence size reduction) by initialize_shared_locs. Since initialize_shared_locs specifically adjusts the alignment, some downstream use of the buffer probably actually cares. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From matthias.baesken at sap.com Tue Sep 29 14:41:59 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Sep 2020 14:41:59 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> References: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> Message-ID: > Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Hi Paul, did that : https://bugs.openjdk.java.net/browse/JDK-8253791 https://github.com/openjdk/jdk/pull/403 Best regards, Matthias -----Original Message----- From: Hohensee, Paul Sent: Dienstag, 29. September 2020 15:46 To: Kim Barrett ; Matthias Baesken Cc: 2d-dev at openjdk.java.net; awt-dev at openjdk.java.net; build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RE: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Thanks, Paul ?On 9/29/20, 4:23 AM, "hotspot-dev on behalf of Kim Barrett" wrote: > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 16:32:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 12:32:27 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <0CA82EAC-9A42-411F-8761-6D9D4F85101E@oracle.com> > On Sep 29, 2020, at 10:18 AM, Hohensee, Paul wrote: > Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have Agreed there seems to be a bit of a mess around that function. > Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). > > So, for the sharedRuntime patch, would it be ok to just use > > short locs_buf[84]; > > to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Your analysis looks plausible. But consider instead struct { double data[20]; } locs_buf; and change next line to use &locs_buf This doesn't change the size or alignment from pre-existing code. I can't test whether this will suppress the warning, but I'm guessing it will. And the rest of below is off if that?s wrong. Changing the size and type and worrying about alignment changes seems beyond what's needed "to make the compiler warning go away, not figure out why the code is the way it is.? I dislike making weird changes to suppress compiler warnings, but changing the type and size seems more weird to me here. I mean, 84 looks like a number pulled out of a hat, unless you are going to add a bunch of commentary that probably really belongs in a bug report to look at this stuff more carefully. And file an RFE to look at initialize_shared_locs and its callers more carefully. From phh at openjdk.java.net Tue Sep 29 19:33:48 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 29 Sep 2020 19:33:48 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch - Merge branch 'master' into JDK-8253375 - JDK-8253375 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/348/files - new: https://git.openjdk.java.net/jdk/pull/348/files/5db5edc2..cb08da07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00-01 Stats: 27610 lines in 391 files changed: 4691 ins; 21610 del; 1309 mod Patch: https://git.openjdk.java.net/jdk/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348 PR: https://git.openjdk.java.net/jdk/pull/348 From kbarrett at openjdk.java.net Tue Sep 29 19:39:03 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 29 Sep 2020 19:39:03 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From lucy at openjdk.java.net Tue Sep 29 20:05:34 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 29 Sep 2020 20:05:34 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to pointer type 'relocInfo *' You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my machine. ------------- Changes requested by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 20:53:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 16:53:48 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: > On Sep 29, 2020, at 4:05 PM, Lutz Schmidt wrote: > > On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since >> the last revision: >> - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch >> - Merge branch 'master' into JDK-8253375 >> - JDK-8253375 > > The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): > > sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to > pointer type 'relocInfo *? Did you use the change from the PR, or apply it manually. That looks like the error one would get if only the type of locs_buf were changed, without changing to take the address in the reference. That is, without changing `(relocInfo*)locs_buf` to `(relocInfo*)&locs_buf`. That second change is in the PR. > You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my > machine. > > ------------- > > Changes requested by lucy (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From hohensee at amazon.com Tue Sep 29 22:14:27 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 22:14:27 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] Message-ID: <398178BA-0420-4ED1-9B70-7FBC3336638D@amazon.com> Hmm. I'm running Xcode 12.0.1 on 10.15.6 and don't see it. Are you sure you have the '&' in front of locs_buf? I.e., buffer.insts()->initialize_shared_locs((relocInfo*)&locs_buf, sizeof(locs_buf) / sizeof(relocInfo)); ^ Thanks, Paul ?On 9/29/20, 1:07 PM, "build-dev on behalf of Lutz Schmidt" wrote: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to pointer type 'relocInfo *' You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my machine. ------------- Changes requested by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From lucy at openjdk.java.net Wed Sep 30 05:54:42 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 30 Sep 2020 05:54:42 GMT Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 I just copied the declaration and oversaw that tiny little '&'. With it, sharedRuntime.cpp compiles fine. Sorry for not being careful enough. Reviewed. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From jdv at openjdk.java.net Wed Sep 30 06:14:27 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 30 Sep 2020 06:14:27 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote: > We have a number of missing javadoc tags and comments in the desktop module. > Most of the missing comments are related to the serialized form. > > The fix: > - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes > - Adds comments to the "serializable" classes even if those classes are non-public > - Fixes references/adds missing tags to the special methods(like readObject/writeObject) > - Delete the java.awt.PeerFixer class. > > I need advice about what exact change should be reviewed in the CSR(except PeerFixer removal) > > Note that in some cases I added the comments to the "implementation details", so I did not specify it fully. > > The old review request: > https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html src/java.desktop/share/classes/java/awt/Window.java line 248: > 246: * Focus transfers for the lightweight components request should be made > 247: * synchronously. > 248: */ More simpler way "Focus transfers should be synchronous for lightweight component requests" ------------- PR: https://git.openjdk.java.net/jdk/pull/369 From jdv at openjdk.java.net Wed Sep 30 06:48:23 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 30 Sep 2020 06:48:23 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote: > We have a number of missing javadoc tags and comments in the desktop module. > Most of the missing comments are related to the serialized form. > > The fix: > - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes > - Adds comments to the "serializable" classes even if those classes are non-public > - Fixes references/adds missing tags to the special methods(like readObject/writeObject) > - Delete the java.awt.PeerFixer class. > > I need advice about what exact change should be reviewed in the CSR(except PeerFixer removal) > > Note that in some cases I added the comments to the "implementation details", so I did not specify it fully. > > The old review request: > https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/369 From hohensee at amazon.com Wed Sep 30 12:15:07 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Sep 2020 12:15:07 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] Message-ID: <364A2F2E-E8C9-4A83-94EF-D067280FE037@amazon.com> Thanks, Lutz! ?On 9/29/20, 10:56 PM, "build-dev on behalf of Lutz Schmidt" wrote: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 I just copied the declaration and oversaw that tiny little '&'. With it, sharedRuntime.cpp compiles fine. Sorry for not being careful enough. Reviewed. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From phh at openjdk.java.net Wed Sep 30 12:19:01 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 30 Sep 2020 12:19:01 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <-aDiMyf9VRdCWuDRYzuFLBKq2amMJspLw7Cnqt1hhTg=.404ceda1-f8a3-4b99-9a38-269da1939573@github.com> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul This pull request has now been integrated. Changeset: f80a6066 Author: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/f80a6066 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253375: OSX build fails with Xcode 12.0 (12A7209) Replace double array with short array in AdapterHandlerLibrary::create_native_wrapper, add parens around ?: in CSystemColors:getColor Reviewed-by: prr, kbarrett, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From hohensee at amazon.com Wed Sep 30 17:28:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Sep 2020 17:28:26 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: <68FA0B26-8DB3-4F08-9F76-87DD570FDF28@amazon.com> I filed https://bugs.openjdk.java.net/browse/JDK-8253868: CodeSection::initialize_shared_locs buffer argument types and sizes are opaque Paul ?On 9/29/20, 9:35 AM, "Kim Barrett" wrote: > On Sep 29, 2020, at 10:18 AM, Hohensee, Paul wrote: > Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have Agreed there seems to be a bit of a mess around that function. > Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). > > So, for the sharedRuntime patch, would it be ok to just use > > short locs_buf[84]; > > to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Your analysis looks plausible. But consider instead struct { double data[20]; } locs_buf; and change next line to use &locs_buf This doesn't change the size or alignment from pre-existing code. I can't test whether this will suppress the warning, but I'm guessing it will. And the rest of below is off if that?s wrong. Changing the size and type and worrying about alignment changes seems beyond what's needed "to make the compiler warning go away, not figure out why the code is the way it is.? I dislike making weird changes to suppress compiler warnings, but changing the type and size seems more weird to me here. I mean, 84 looks like a number pulled out of a hat, unless you are going to add a bunch of commentary that probably really belongs in a bug report to look at this stuff more carefully. And file an RFE to look at initialize_shared_locs and its callers more carefully. From david.holmes at oracle.com Thu Sep 10 13:50:22 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Sep 2020 13:50:22 -0000 Subject: [OpenJDK 2D-Dev] RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote: > On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: > >>> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >>> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >>> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >>> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >>> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >>> JDK-8215014 rather than creating a new issue. >> >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > I have in mind dozens of improvements all over the code like this one. I already did some further review and in most > cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would > multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. Find a reasonable middle ground. You have around 14 mailing lists cc'd here, for changes on 150 files. It is very unlikely anyone will review all 150, and files in different areas are, by convention, reviewed by Reviewers for those areas. Even if people only look at a subset of files, communicating that to you effectively so you can figure out when all 150 have been reviewed, is not very practical. My initial breakdown would be: - build - desktop (awt/swing/2d) - serviceability/jmx (the SA and JVMTI changes) - security - core-libs Also note that while the original PR email went out to 14 lists, most people trying to reply-all won't be able to as they don't subscribe to all 14 lists, so the review threads will get very fragmented. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/29 >