From philip.race at oracle.com Mon Jul 3 17:40:50 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 3 Jul 2017 10:40:50 -0700 Subject: [OpenJDK 2D-Dev] [10] RFR 8078192: Path2D storage trimming In-Reply-To: <59386886.8050309@oracle.com> References: <4a1d1917-dad7-6139-937a-39170c07b196@oracle.com> <58F92273.6080403@oracle.com> <58F93390.3060302@oracle.com> <81bf576a-ddfe-9174-b234-7d070e163d26@oracle.com> <59386886.8050309@oracle.com> Message-ID: <6402b5d2-1179-3d6a-3c9d-34be974637a1@oracle.com> Laurent, Investigation has determined that since this was ported over in the "CCC migration project", due to the way that is set up it can't be assigned to non-Oracle employees. It won't affect any new CSRs that are created. Since the likelihood of any other similar case is extremely low, the simplest answer is that either Jim or myself will need to own and edit this one on your behalf. Send Jim or myself the changes you would like to make off-line and we'll take care of it. -phil. On 06/07/2017 01:56 PM, Philip Race wrote: > Oh this one is interesting. It already has a CSR :-) > > > > That's because we had created a CCC for it back in JDK 9 and then > withdrew it. > > All existing CSRs were ported over but as "confidential" since honestly > no one had time to look at all N thousand of them and vet them ... > we vetted and opened enough to give people a flavour. > > So I think that "create a csr" doesn't appear if there already is one > since you can't see it. > > I opened it so you can now see it. > > https://bugs.openjdk.java.net/browse/CCC-8078192 > > I re-opened it but don't seem to be able to target it to 10 or assign > it to you. > > I'll need to ask. > > -phil > > On 6/7/17, 1:35 PM, Laurent Bourg?s wrote: >> Phil, >> >> Could you initiate the CSR request in JBS ? >> I do not see how to create it from the current bug: I looked at the >> More menu but I do not have any Create CSR action. >> >> Cheers, >> Laurent >> >> Le 17 mai 2017 22:05, "Phil Race" > > a ?crit : >> >> Early next week is the hope. >> >> -phil >> >> On 05/16/2017 02:20 PM, Laurent Bourg?s wrote: >>> Phil, >>> >>> Did you get any answer from the CSR process on this bug ? >>> >>> Laurent >>> >>> >>> 2017-04-21 0:17 GMT+02:00 Philip Race >> >: >>> >>> OK. Although we still need to wait for the CSR process. >>> >>> -phil. >>> >>> >>> On 4/20/17, 3:05 PM, Laurent Bourg?s wrote: >>>> Sorry (bad shortcut); >>>> >>>> Here is the fixed webrev: >>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.3/ >>>> >>>> >>>> Laurent >>>> >>>> 2017-04-21 0:04 GMT+02:00 Laurent Bourg?s >>>> >: >>>> >>>> Sorry for the typo, I added also a newline before @since: >>>> >>>> >>>> 2017-04-20 23:04 GMT+02:00 Philip Race >>>> >: >>>> >>>> You have a capital letter here and I think it must >>>> be lower case .. >>>> >>>> >>>> 2499 * @Since 10 >>>> >>>> -phil. >>>> >>>> >>>> On 4/20/17, 1:58 PM, Laurent Bourg?s wrote: >>>>> Hi Phil & Jim, >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.2/ >>>>> >>>>> >>>>> Changes: >>>>> - trimToSize() return void >>>>> - fixed test + jtreg passed >>>>> >>>>> Bye, >>>>> Laurent >>>>> >>>>> 2017-04-20 21:30 GMT+02:00 Jim Graham >>>>> >>>> >: >>>>> >>>>> Hi Laurent, >>>>> >>>>> The implementation looks good, except that the >>>>> method chaining-style return value seems out >>>>> of place here. Similar trimToSize() methods in >>>>> Collections return void and none of the other >>>>> methods in this area use the method chaining >>>>> paradigm. In the interest of maintaining a >>>>> common design theme throughout 2D this method >>>>> should just return void. >>>>> >>>>> ...jim >>>>> >>>>> >>>>> On 4/18/17 11:49 PM, Laurent Bourg?s wrote: >>>>> >>>>> Hi, >>>>> >>>>> Here is a first attempt to propose a >>>>> Path2D patch (based on JDK10): >>>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.0/ >>>>> >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8078192 >>>>> >>>>> >>>>> Please review the Path2D changes, notably >>>>> the javadoc (english) and the modified >>>>> Path2DCopyConstructor test which checks >>>>> all public Path2D methods on concrete >>>>> classes (Path2D.Float, Path2D.Double, >>>>> GeneralPath) after calling path.trimToSize() >>>>> >>>>> Cheers, >>>>> Laurent >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Laurent Bourg?s >>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> Laurent Bourg?s >>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> Laurent Bourg?s >>> >>> >>> >>> >>> -- >>> -- >>> Laurent Bourg?s >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sreilly at infinitekind.com Mon Jul 3 22:30:28 2017 From: sreilly at infinitekind.com (Sean Reilly) Date: Mon, 3 Jul 2017 23:30:28 +0100 Subject: [OpenJDK 2D-Dev] printing from the mac sandbox In-Reply-To: <8e78cc64-17d5-d3fd-a6af-c48ede6268eb@oracle.com> References: <2457AAE3-CB15-472F-85C0-BC1C68CD255A@seanreilly.com> <8e78cc64-17d5-d3fd-a6af-c48ede6268eb@oracle.com> Message-ID: > On 2017.06.02, at 18:06, Phil Race wrote: >> 2) Is there a reason not to use the unix domain socket connection? The connection details seem to be encapsulated within the libcups code so I don't see why the java level needs to override the result returned by the call to `cupsServer` > > I don't follow your comment about encapsulation in libcups code. > The server name is returned to Java code and there a connection is made over HTTP. > The socket string would not work there .. and Java does not have any support I know of > for Unix domain sockets anyway. This would seem to require a lot of re-working of the > code unless I am missing something. I'm not sure how much reworking it would require, but IMO a bug preventing printing in any sandboxed (ie mac app store) app is a big deal. > Also I asked someone with 10.12.5 to run the following program and it worked fine for them. > What is your program doing and how are you running it ? The test code you included wouldn't reveal the problem because it wasn't running within the mac sandbox. I've created a small test case that shows the problem: https://infinitekind.com/tmp/javacups/ SandboxedJavaTestPrint.zip - has a signed sandboxed java app as well as the source and scripts that were used to build it. I've signed it with my developer key and added a debugging flag (-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005) so that you can trace through the steps while it runs within the sandbox. TEST CUPS Sandboxed.zip - contains an objective-c/Xcode project which shows how native connections to localhost port 631 through the CUPS API time out, but how passing the result of a call to cupsServer() (which returns the unix domain socket path) to httpConnect2() results in a successful connection. This shows that we can still (probably) use a call to httpConnect/httpConnect2, but the java-side code that assumes cupsServer() returns a hostname will need to change. It's not a trivial change, but it also doesn't look like it gets too hairy... mainly some changes in UnixPrintServiceLocalLookup.java and IPPPrintService.java. Both test apps have network-client and printing entitlements in the sandbox. The problem mainly seems to be a delay (often measured in tens of minutes) when attempting to print. Curiously the print dialog does appear after a very long delay and printing can then proceed. This makes me think that the problem is related to discovery of printers or print services for which there is a fallback. I've submitted a DTS incident to Apple and a friend there has followed-up. Their unofficial position is that java should be connecting to the cups interface returned by the cupsServer() function and not changing the interface string to "localhost". Security changes in 10.12.4 reject the TCP connection which they say confuses network-client access with print access. They don't seem interested in loosening that change. You can find Apple's CUPS port in github: https://github.com/apple/cups Their github repo seems to be a bit ahead of what is shipped in macOS Sierra. I'm still digging into this, but would appreciate hearing if Oracle would be interested in helping resolve the issue. Thanks, Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From sergey.bylokhov at oracle.com Wed Jul 5 17:31:26 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Jul 2017 10:31:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] Review Request: 8183576 Synchronization in BufferedImage.setRGB(int x, int y, int rgb) is not necessary Message-ID: Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8183576 Webrev can be found at: http://cr.openjdk.java.net/~serb/8183576/webrev.00 The method setRGB(int x, int y, int rgb) in BufferedImage is synchronized, but all other methods in this class are not. For example the similar method: setRGB(int startX, int startY, int w, int h, int[] rgbArray, int offset, int scansize) and get methods: getRGB(int x, int y) getRGB(int, int, int, int, int[], int, int). Since the BufferedImage class is not thread-safe it is unclear why the only this method was marked as synchronized. (Other possible fix: mark this class as a thread-safe and synchronize access to internal data in other methods). CSR will created after technical review. From philip.race at oracle.com Wed Jul 5 17:46:12 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 5 Jul 2017 10:46:12 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8183576 Synchronization in BufferedImage.setRGB(int x, int y, int rgb) is not necessary In-Reply-To: References: Message-ID: <577e78eb-99ac-5dfb-170c-d28a6ca6e4fe@oracle.com> This seems anomalous to me too. I don't see any likely real problem with removing it .. -phil. On 07/05/2017 10:31 AM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8183576 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8183576/webrev.00 > > The method setRGB(int x, int y, int rgb) in BufferedImage is synchronized, but all other methods in this class are not. For example the similar method: > setRGB(int startX, int startY, int w, int h, int[] rgbArray, int offset, int scansize) > and get methods: > getRGB(int x, int y) > getRGB(int, int, int, int, int[], int, int). > > Since the BufferedImage class is not thread-safe it is unclear why the only this method was marked as synchronized. > > (Other possible fix: mark this class as a thread-safe and synchronize access to internal data in other methods). > > CSR will created after technical review. From james.graham at oracle.com Wed Jul 5 21:50:32 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 5 Jul 2017 14:50:32 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8183576 Synchronization in BufferedImage.setRGB(int x, int y, int rgb) is not necessary In-Reply-To: References: Message-ID: <2d367a3f-1d9e-decb-d547-f33b6bd676ce@oracle.com> Looks fine to me... ...jim On 7/5/17 10:31 AM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8183576 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8183576/webrev.00 > > The method setRGB(int x, int y, int rgb) in BufferedImage is synchronized, but all other methods in this class are not. For example the similar method: > setRGB(int startX, int startY, int w, int h, int[] rgbArray, int offset, int scansize) > and get methods: > getRGB(int x, int y) > getRGB(int, int, int, int, int[], int, int). > > Since the BufferedImage class is not thread-safe it is unclear why the only this method was marked as synchronized. > > (Other possible fix: mark this class as a thread-safe and synchronize access to internal data in other methods). > > CSR will created after technical review. > From prahalad.kumar.narayanan at oracle.com Thu Jul 6 02:25:07 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 5 Jul 2017 19:25:07 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] Review Request: 8183576 Synchronization in BufferedImage.setRGB(int x, int y, int rgb) is not necessary In-Reply-To: References: Message-ID: <5c59d801-bae2-4f83-8a05-b7f22517d6d8@default> Hello Sergey I don?t see any trouble in removing 'synchronized' from the method signature. The change looks good. Thank you Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, July 05, 2017 11:01 PM To: 2d-Dev Cc: Jim A Graham Subject: [OpenJDK 2D-Dev] [10] Review Request: 8183576 Synchronization in BufferedImage.setRGB(int x, int y, int rgb) is not necessary Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8183576 Webrev can be found at: http://cr.openjdk.java.net/~serb/8183576/webrev.00 The method setRGB(int x, int y, int rgb) in BufferedImage is synchronized, but all other methods in this class are not. For example the similar method: setRGB(int startX, int startY, int w, int h, int[] rgbArray, int offset, int scansize) and get methods: getRGB(int x, int y) getRGB(int, int, int, int, int[], int, int). Since the BufferedImage class is not thread-safe it is unclear why the only this method was marked as synchronized. (Other possible fix: mark this class as a thread-safe and synchronize access to internal data in other methods). CSR will created after technical review. From bourges.laurent at gmail.com Sat Jul 8 07:20:41 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 8 Jul 2017 09:20:41 +0200 Subject: [OpenJDK 2D-Dev] [10] RFR 8078192: Path2D storage trimming In-Reply-To: <6402b5d2-1179-3d6a-3c9d-34be974637a1@oracle.com> References: <4a1d1917-dad7-6139-937a-39170c07b196@oracle.com> <58F92273.6080403@oracle.com> <58F93390.3060302@oracle.com> <81bf576a-ddfe-9174-b234-7d070e163d26@oracle.com> <59386886.8050309@oracle.com> <6402b5d2-1179-3d6a-3c9d-34be974637a1@oracle.com> Message-ID: Phil, Here are my comments on this CSR to be fixed in openjdk 10; I already submitted a patch and the review process happened in may. Le 3 juil. 2017 7:41 PM, "Phil Race" a ?crit : Laurent, Investigation has determined that since this was ported over in the "CCC migration project", due to the way that is set up it can't be assigned to non-Oracle employees. Ok, no problem. It won't affect any new CSRs that are created. Since the likelihood of any other similar case is extremely low, the simplest answer is that either Jim or myself will need to own and edit this one on your behalf. Send Jim or myself the changes you would like to make off-line and we'll take care of it. Just change the fix version to 10 and the @since javadoc tag as below: /** * Trims the capacity of this Path2D instance to its current * size. An application can use this operation to minimize the * storage of a path. * * @since 10 */ + public abstract void trimToSize(); It will match the proposed patch. Thanks, Laurent >>> 2017-04-20 23:04 GMT+02:00 Philip Race : >>> >>>> You have a capital letter here and I think it must be lower case .. >>>> >>>> >>>> 2499 * @Since 10 >>>> >>>> -phil. >>>> >>>> >>>> On 4/20/17, 1:58 PM, Laurent Bourg?s wrote: >>>> >>>> Hi Phil & Jim, >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.2/ >>>> >>>> Changes: >>>> - trimToSize() return void >>>> - fixed test + jtreg passed >>>> >>>> Bye, >>>> Laurent >>>> >>>> 2017-04-20 21:30 GMT+02:00 Jim Graham : >>>> >>>>> Hi Laurent, >>>>> >>>>> The implementation looks good, except that the method chaining-style >>>>> return value seems out of place here. Similar trimToSize() methods in >>>>> Collections return void and none of the other methods in this area use the >>>>> method chaining paradigm. In the interest of maintaining a common design >>>>> theme throughout 2D this method should just return void. >>>>> >>>>> ...jim >>>>> >>>>> >>>>> On 4/18/17 11:49 PM, Laurent Bourg?s wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Here is a first attempt to propose a Path2D patch (based on JDK10): >>>>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.0/ >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078192 >>>>>> >>>>>> Please review the Path2D changes, notably the javadoc (english) and >>>>>> the modified Path2DCopyConstructor >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Sat Jul 8 08:02:45 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 8 Jul 2017 10:02:45 +0200 Subject: [OpenJDK 2D-Dev] [10] RFR 8078192: Path2D storage trimming In-Reply-To: <6402b5d2-1179-3d6a-3c9d-34be974637a1@oracle.com> References: <4a1d1917-dad7-6139-937a-39170c07b196@oracle.com> <58F92273.6080403@oracle.com> <58F93390.3060302@oracle.com> <81bf576a-ddfe-9174-b234-7d070e163d26@oracle.com> <59386886.8050309@oracle.com> <6402b5d2-1179-3d6a-3c9d-34be974637a1@oracle.com> Message-ID: Phil, Here are my comments on this CSR to be fixed in openjdk 10; I already submitted a patch and the review process happened in may. Le 3 juil. 2017 7:41 PM, "Phil Race" a ?crit : Laurent, Investigation has determined that since this was ported over in the "CCC migration project", due to the way that is set up it can't be assigned to non-Oracle employees. Ok, no problem. It won't affect any new CSRs that are created. Since the likelihood of any other similar case is extremely low, the simplest answer is that either Jim or myself will need to own and edit this one on your behalf. Send Jim or myself the changes you would like to make off-line and we'll take care of it. Just change the fix version to 10 and the @since javadoc tag as below: /** * Trims the capacity of this Path2D instance to its current * size. An application can use this operation to minimize the * storage of a path. * * @since 10 */ + public abstract void trimToSize(); It will match the proposed patch. Thanks, Laurent >>> 2017-04-20 23:04 GMT+02:00 Philip Race : >>> >>>> You have a capital letter here and I think it must be lower case .. >>>> >>>> >>>> 2499 * @Since 10 >>>> >>>> -phil. >>>> >>>> >>>> On 4/20/17, 1:58 PM, Laurent Bourg?s wrote: >>>> >>>> Hi Phil & Jim, >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.2/ >>>> >>>> Changes: >>>> - trimToSize() return void >>>> - fixed test + jtreg passed >>>> >>>> Bye, >>>> Laurent >>>> >>>> 2017-04-20 21:30 GMT+02:00 Jim Graham : >>>> >>>>> Hi Laurent, >>>>> >>>>> The implementation looks good, except that the method chaining-style >>>>> return value seems out of place here. Similar trimToSize() methods in >>>>> Collections return void and none of the other methods in this area use the >>>>> method chaining paradigm. In the interest of maintaining a common design >>>>> theme throughout 2D this method should just return void. >>>>> >>>>> ...jim >>>>> >>>>> >>>>> On 4/18/17 11:49 PM, Laurent Bourg?s wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Here is a first attempt to propose a Path2D patch (based on JDK10): >>>>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.0/ >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078192 >>>>>> >>>>>> Please review the Path2D changes, notably the javadoc (english) and >>>>>> the modified Path2DCopyConstructor >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Jul 9 18:28:15 2017 From: philip.race at oracle.com (Philip Race) Date: Sun, 09 Jul 2017 11:28:15 -0700 Subject: [OpenJDK 2D-Dev] [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop In-Reply-To: References: <3633d215-ec1a-4c16-a74b-a80627e45cb5@default> <1db4e0a1-63a2-2d15-b6b6-16dba6c1c3b5@oracle.com> <3267ec4c-45ab-4a39-a620-bc987e1e2064@default> <4a9b07a8-5fc9-0ed2-3622-790a9f8f4ac6@oracle.com> <868ecb9f-8ce3-48dd-a347-c487223874f0@default> <3bf67087-64b4-0b50-f09c-abc680c562b9@oracle.com> <0142127f-a994-6f20-8a28-8afe64f8921e@oracle.com> <593877C8.3090708@oracle.com> <32a345ef-9dae-4f98-a6e7-b5dd72d4fc70@default> <9967f1d9-d062-0148-7526-f359e854c89a@oracle.com> <9dcb0639-f1da-6988-2611-b52ca305b876@oracle.com> <58620d3c-70cc-4355-8057-81cf9fc3c322@default> <58a532bd-7c07-fe08-b42c-b9145ead718c@oracle.com> Message-ID: <596275BF.50009@oracle.com> displays is misspelt as diplsays in at least two cases. imageable is misspelt as imagable in at least one case. "imageable area retains even after closing in the" Are you trying to say "is retained" ? I am still not happy that you are hard-coding values "2" and "3" in the instructions If the printer's default paper is < 6 inches wide this will fail. The whole thing should be adaptive to what it actually sees. I am also unclear how you are so sure it'll be inches ? I'd expect most locales to use centimetres, but what you see depends on the platform .. which I expect is why you excluded Mac ? But why are you excluding Solaris too ? java.awt.print.PrinterJob.getPrinterJob() You are importing all the other classes from java.awt.print, so why not this one too ? Whilst I don't have any objection to throwing a runtime exception if the tester presses your FAIL button, you could have just used the "yes/no" support in the jtreg test harness. -phil. On 6/21/17, 1:33 AM, Shashidhara Veerabhadraiah wrote: > > Hi, Here is the updated Webrev with comment fixes: > > http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_06/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, June 12, 2017 11:19 PM > *To:* Philip Race ; Prasanta Sadhukhan > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* RE: [9]JDK-6949753:[TEST BUG]: > java/awt/print/PageFormat/PDialogTest.java needs update by removing a > infinite loop > > Ok Phil. I shall update the test and send it for re-review tomorrow. > > Thanks and regards, > Shashi > > *From:*Phil Race > *Sent:* Monday, June 12, 2017 11:15 PM > *To:* Shashidhara Veerabhadraiah > >; Prasanta Sadhukhan > > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [9]JDK-6949753:[TEST BUG]: > java/awt/print/PageFormat/PDialogTest.java needs update by removing a > infinite loop > > The dialog does not show "Letter" because you said so. It shows it > because the printer reports it supports letter. > > -phil. > > On 06/12/2017 10:44 AM, Shashidhara Veerabhadraiah wrote: > > Just to clarify Phil for the part of cross platform print dialog, > here is that dialog representation: > > Since this dialog can appear on any platform, the Paper class > would represent the backend object for the front end dialog > properties(of a generic printer) as shown in the pic above. Hence > the use of the raw Paper object than obtaining it from the page > format. > > At the same time, as you pointed out, the test is not reliable > with the actual conditions. The only problem I see is that the > moment we change the test case to stay close to the actual > scenario we may have certain failures because the settings are > different for different locales and it may be difficult to adapt > to every possible locales. > > Thanks and regards, > > Shashi > > *From:*Phil Race > *Sent:* Monday, June 12, 2017 10:01 PM > *To:* Shashidhara Veerabhadraiah > > ; Prasanta Sadhukhan > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [9]JDK-6949753:[TEST BUG]: > java/awt/print/PageFormat/PDialogTest.java needs update by > removing a infinite loop > > */>[Shashi] Yes. I intend to use the default paper object as this is a test related to the cross platform default printer dialog./* > > */> In the modified test file, I have set the size of the physical paper instead of relying it on the default setting which may/* > > */> vary as you pointed out, depending on the locale./* > > */>Now that we have our own paper object(with a constant paper size) and based on the margin setting(which are const/* > > */> it won?t cause an undesirable behavior like going into negative space./* > > > > > > Sorry, that is not a valid thing to do. The print dialog is free to ignore this > > or workaround the incompatibility of that paper with the supported media so your test is not reliable. > > And I don't see what the cross platform print dialog has to do with it. > > It is, or should be, just as aware of the printer sizes as the native one. > > > > -phil. > > On 06/12/2017 03:34 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, Please see below for the comments: > > The updated Webrev is at: > > http://cr.openjdk.java.net/~aghaisas/shashi/6949753/webrev_05/ > > > > Modified in what way from the previous version ? > > -phil. > > > Thanks and regards, > Shashi > > *From:*Phil Race > *Sent:* Saturday, June 10, 2017 3:07 AM > *To:* Prasanta Sadhukhan > ; Shashidhara > Veerabhadraiah > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [9]JDK-6949753:[TEST BUG]: > java/awt/print/PageFormat/PDialogTest.java needs update by > removing a infinite loop > > private static void setValuesForPrintPageSetup(PageFormat pageFormat, int > > 118 marginValue) throws PrinterException { > > 119 Paper paper = new Paper(); > > double paperHeight = paper.getHeight(); > > 122 double paperWidth = paper.getWidth(); > > 123 double paperX = paper.getImageableX(); > > 124 double paperY = paper.getImageableY(); > > 125 paper.setImageableArea(paperX * marginValue, paperY * marginValue, > > 126 paperWidth - (paperX * 2 * marginValue), > > 127 paperHeight - (paperY * 2 * marginValue)); > > > > > > 105 setValuesForPrintPageSetup(pageFormat, 3); > > > > > > I see you call new Paper() above > > https://docs.oracle.com/javase/8/docs/api/java/awt/print/Paper.html#Paper-- > > > > Did you really intend to use a default paper instead of getting the one > > from the pageFormat ? On some label printer your Letter Paper may not > > even be supported. US (aka NA) Letter is 8.5" wide. > > > > Also although it probably will work out OK the maths isn't checking > > for boundary problems. > > > > default margin will be 1" so that's what you'll get for paperX and paperY > > > > Using your value of 3 we set the imagable area such that > > imageable X = 1 * 3 = 3 > > imageableWidth = 8.5 - (1 * 2 *3) = 8.5 - 6 = 2.5; > > > > Fortunately that worked out positive .. but it does not seem to be enforced. > > > > If we'd used 5 it would be a different story : > > > > ix = 5, iw = 8.5 - ( 1 * 2 * 5) = -1.5 > > > > The implementation will (should) clamp it to non-negative but it > > might still be better to have some defensive logic of your own. > > */[Shashi] Yes. I intend to use the default paper object as this is a test related to the cross platform default printer dialog. In the modified test file, I have set the size of the physical paper instead of relying it on the default setting which may vary as you pointed out, depending on the locale./* > > */Now that we have our own paper object(with a constant paper size) and based on the margin setting(which are constants), it won?t cause an undesirable behavior like going into negative space./* > > > > nit: there's a missing space here > > > > 75 } catch(PrinterException e) { > > */[Shashi] This is fixed now./* > > > > -phil. > > > > On 06/09/2017 03:27 AM, Prasanta Sadhukhan wrote: > > looks good to me. > > Regards > Prasanta > > On 6/9/2017 3:49 PM, Shashidhara Veerabhadraiah wrote: > > Hi All, Please find the updated Webrev with fixes for > the comments @ > http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_04/ > > > Thanks and regards, > Shashi > > *From:*Philip Race > *Sent:* Thursday, June 8, 2017 3:32 AM > *To:* Prasanta Sadhukhan > > > *Cc:* Shashidhara Veerabhadraiah > > ; > 2d-dev at openjdk.java.net > *Subject:* Re: [9]JDK-6949753:[TEST BUG]: > java/awt/print/PageFormat/PDialogTest.java needs > update by removing a infinite loop > > .. and please make sure all lines are <= 80 chars as > per the coding standards. > > -phil. > > On 6/6/17, 11:59 PM, Prasanta Sadhukhan wrote: > > do_test() does not need to be under EDT as it > invokes printer pagedialog and not swing > components. Actually, createUI() needs to be under > EDT which has not been done. > > Also, > > 79 SwingUtilities.invokeAndWait(() -> { > > 80 test.disposeUI(); > > 81 }); > > 82 } > > should be called before you throw RuntimeException when test times out . > > There is no need of calling this after > > 75 if (test.testResult == false) { > > 76 throw new RuntimeException("Test Failed."); > > 77 } > > as it has already been called in pass/fail actionlistener. > > > > Also, put a sleep after T1.start() and do_test() otherwise since they are in separate thread, in mycase, pagedialog is displayed before test instructions dialog. > > > > Regards > > Prasanta > > On 6/7/2017 11:50 AM, Shashidhara Veerabhadraiah > wrote: > > Hi All, > > I have altered the manual test template per > the comments. > > 1.Have moved the test instructions window > under newly created thread. > > 2.Have moved the print dialog(main test > module) under EDT. > > 3.Timer management shall be done on the main > thread. > > I have placed the updated Webrev @ > http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_03/ > > > Please let me know if any comments on it. > > Thanks and regards, > > Shashi > > *From:*Prasanta Sadhukhan > *Sent:* Tuesday, June 6, 2017 11:52 AM > *To:* Shashidhara Veerabhadraiah > > ; 2d-dev at openjdk.java.net > > *Cc:* Philip Race > > *Subject:* Re: [9]JDK-6949753:[TEST BUG]: > java/awt/print/PageFormat/PDialogTest.java > needs update by removing a infinite loop > > As I told, pageDialog is modal so > latch.await() will not be called if user does > not close the page dialog or do any > interaction. The actual test > > 59 PageFormat pageFormat = new PageFormat(); > > 60 > > 61 createNewPrintPageSetup(pageFormat); > > 62 > > 63 setValuesForPrintPageSetup(pageFormat, 2); > > 64 > > 65 createNewPrintPageSetup(pageFormat); > > 66 > > 67 setValuesForPrintPageSetup(pageFormat, 3); > > 68 > > 69 createNewPrintPageSetup(pageFormat); > > > should be done in other thread. > > Regards > Prasanta > > On 6/6/2017 11:24 AM, Shashidhara > Veerabhadraiah wrote: > > The manual test template that I received > from the team seems buggy and an older > version it seems. I have modified the same > per your inputs and now placed the updated > Webrev at > http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_02/ > . > > Thanks and regards, > > Shashi > > *From:*Prasanta Sadhukhan > *Sent:* Monday, June 5, 2017 12:35 PM > *To:* Shashidhara Veerabhadraiah > > ; > 2d-dev at openjdk.java.net > > *Cc:* Philip Race > > *Subject:* Re: [9]JDK-6949753:[TEST BUG]: > java/awt/print/PageFormat/PDialogTest.java > needs update by removing a infinite loop > > I guess there is one more problem in usage > of CountDown latch. Have you seen this > test fail with timeout even if you wait > for 5 minutes as per your timeout period? > > latch.await() needs to be wait on main > thread while the test needs to be executed > in another thread otherwise, pageDialog > being modal the control will not come to > latch.await() > > Iguess you need to do this. > > TestUI test = new TestUI(latch); > Thread T1 = new Thread(test); > T1.start(); > > class TestUI implements Runnable { > ... > @Override > public void run() { > try { > createUI(); > > Regards > Prasanta > > On 6/2/2017 4:00 PM, Shashidhara > Veerabhadraiah wrote: > > Hi, I have fixed the comments below > and updated the webrev @ > http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_01/ > > > Thanks and regards, > > Shashi > > *From:*Prasanta Sadhukhan > *Sent:* Friday, June 2, 2017 12:36 PM > *To:* Shashidhara Veerabhadraiah > ; > 2d-dev at openjdk.java.net > > *Cc:* Philip Race > > > *Subject:* Re: [9]JDK-6949753:[TEST > BUG]: > java/awt/print/PageFormat/PDialogTest.java > needs update by removing a infinite loop > > Test fix look ok. Only thing is, you > can call getPrinterJob() once and > reutilise instead of calling 3 times > and probably there is no need of > creating a > functioncreateNewPrintPageSetup() for > it (as it calls 1 method) but it is > upto you. > > Few comments: > > Copyright should have "," after 2017. > I guess createUI() does not have any > call that throws exception so no need > to have try-catch block for createUI(). > Also, there is no need to catch > PrinterException and rethrow > RuntimeException, so you can do away > with that try-catch. > Also, you can call disposeUI() in > passButton and failButton > actionlistener instead of in main(). > Also, there is no need to do > setVisible(false) in disposeUI(), > dispose() will take care of that. > You can throw RuntimeException when > test timed out (instead of just > println and later getting test fail > exception) which is different from > Test Failed RuntimeException. > > Regards > Prasanta > > On 6/1/2017 5:10 PM, Shashidhara > Veerabhadraiah wrote: > > Hi All, > > Please review a fix for a test bug which contained an infinite loop to test the printer setup dialog's margin attributes retention without the manual step procedure. > > > > The issue with PDialogTest.java which tests the printer setup dialog's margin attributes retention by having as infinite loop to keep popping up the dialog without a proper exit. The test does not cover the instruction steps necessary to properly test dialog's margin attributes retention. > > > > The updated test file includes the standard manual test template along with test cases to cover the printer dialog's margin attributes retention feature. > > > > Bug: > > > > > > Webrev: > > > > > > Note : PrintDialog on Mac does not show page margins and hence this test does not run on Mac. > > > > Thanks and regards, > > Shashi > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 31205 bytes Desc: not available URL: From jayathirth.d.v at oracle.com Mon Jul 10 10:41:50 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 10 Jul 2017 03:41:50 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Message-ID: <2e6c3cb9-1fe0-473d-a27d-3a664f77aa9d@default> Hello All, Please review the following fix in JDK10 : Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ Issue : Temporary image files created in test case are not getting deleted after test execution is finished. Root cause : ImageOutputStream related to the file was closed previously and not FileOutputStream which was its parent. Solution : Closing the FileOutputStream allows us to delete temporary file. Also replaced file.deleteOnExit() with Files.delete(). Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Jul 11 02:51:57 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 10 Jul 2017 19:51:57 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: <2e6c3cb9-1fe0-473d-a27d-3a664f77aa9d@default> References: <2e6c3cb9-1fe0-473d-a27d-3a664f77aa9d@default> Message-ID: Hello Jay I looked into the changes. Please find my suggestions herewith. . Refer to the javadocs of File class. It mentions that a directory could be deleted only if it's empty. Hence, invoking directory.delete() will not work because a temp file would already exist in it. Besides why should we delete a directory that is created by the test suite. 66 final File file = File.createTempFile("temp", ".img", directory); 67 directory.delete(); . Assuming the call to prepareWriteSequence fails, the subsequent call to Files.delete(...) at Line 78 will throw an exception. FileOutputStream should be closed here as well. Similar to changes in Line 86. 78 Files.delete(file.toPath()); Thank you Have a good day Prahalad N. -------------------- From: Jayathirth D V Sent: Monday, July 10, 2017 4:12 PM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Hello All, Please review the following fix in JDK10 : Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ Issue : Temporary image files created in test case are not getting deleted after test execution is finished. Root cause : ImageOutputStream related to the file was closed previously and not FileOutputStream which was its parent. Solution : Closing the FileOutputStream allows us to delete temporary file. Also replaced file.deleteOnExit() with Files.delete(). Thanks, Jay From shashidhara.veerabhadraiah at oracle.com Tue Jul 11 09:35:03 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 11 Jul 2017 02:35:03 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java Message-ID: Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Jul 11 11:27:26 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 11 Jul 2017 04:27:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: References: Message-ID: Hello Sashi Good day to you. I looked into the changes. Here are my suggestions . You are deleting the files with Files.delete(filePath) only when the test succeeds Shouldn't you delete the temp file upon failure as well ? (before throwing RuntimeException in Line 70) Besides, the nature of the bug and the proposed fix are similar to- JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java. The test cases corresponding to both the bugs use- File.deleteOnExit APIs. . As per the documentation- the API "Requests" deletion of the indicated file upon "normal termination" of the VM. . Since the spec doesn't guarantee the deletion (only requests), I think changes to the test source should be ok. . However, I 'm curious to know- . Was the bug reproducible at your end ? . If yes, was it reproducible when the test succeeded /or when the test failed ? . Is there a difference in the VM's termination based on the outcome of the test case. . How many such test cases exist that need similar clean up ? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. . grep on 'File.createTempFile' within same directory gives me 29 instances. Thank you Have a good day Prahalad N. -------------- From: Shashidhara Veerabhadraiah Sent: Tuesday, July 11, 2017 3:05 PM To: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi From sergey.bylokhov at oracle.com Tue Jul 11 18:38:28 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Jul 2017 11:38:28 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Message-ID: I guess the only change which is needed is to wrap the test() method in the try catch and add "Files.delete(file.toPath());fos.close();" to the finally block. It seems will have less code. It is unclear why the test was changed to the manual? ----- prahalad.kumar.narayanan at oracle.com wrote: > Hello Jay > > I looked into the changes. Please find my suggestions herewith. > > . Refer to the javadocs of File class. It mentions that a directory > could be deleted only if it's empty. > Hence, invoking directory.delete() will not work because a temp file > would already exist in it. > Besides why should we delete a directory that is created by the test > suite. > 66 final File file = File.createTempFile("temp", ".img", > directory); > 67 directory.delete(); > > . Assuming the call to prepareWriteSequence fails, the subsequent call > to Files.delete(...) at Line 78 will throw an exception. > FileOutputStream should be closed here as well. Similar to changes > in Line 86. > 78 Files.delete(file.toPath()); > > Thank you > Have a good day > > Prahalad N. > > -------------------- > From: Jayathirth D V > Sent: Monday, July 10, 2017 4:12 PM > To: 2d-dev at openjdk.java.net > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 > Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ > > Issue : Temporary image files created in test case are not getting > deleted after test execution is finished. > Root cause : ImageOutputStream related to the file was closed > previously and not FileOutputStream which was its parent. > Solution : Closing the FileOutputStream allows us to delete temporary > file. Also replaced file.deleteOnExit() with Files.delete(). > > Thanks, > Jay From sergey.bylokhov at oracle.com Tue Jul 11 18:43:24 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Jul 2017 11:43:24 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java Message-ID: Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- shashidhara.veerabhadraiah at oracle.com wrote: > [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create . The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating . Bug: < https://bugs.openjdk.java.net/browse/JDK-8183341 > Webrev: < http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_00/ > Note: The user had requ ested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Wed Jul 12 05:33:03 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 11 Jul 2017 22:33:03 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: References: Message-ID: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Wed Jul 12 05:41:39 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 11 Jul 2017 22:41:39 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> Message-ID: Hello Sashi As Sergey suggested, the deleting the file in the finally block resolves the issues. The change looks good. Thanks Have a good day Prahalad N. ---------------------------------------------------- From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net; Philip Race Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ Thanks and regards, Shashi From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi From jayathirth.d.v at oracle.com Wed Jul 12 06:16:10 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 11 Jul 2017 23:16:10 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: References: Message-ID: Hi Sergey & Prahalad, Thanks for your suggestions. I have updated the test case to use finally block to delete the resources. Some of the changes previously present in test case are because of typo mistakes picked from another test case. Please find the updated webrev: http://cr.openjdk.java.net/~jdv/8183349/webrev.01/ Regards, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:08 AM To: Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net; Jayathirth D V Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java I guess the only change which is needed is to wrap the test() method in the try catch and add "Files.delete(file.toPath());fos.close();" to the finally block. It seems will have less code. It is unclear why the test was changed to the manual? ----- prahalad.kumar.narayanan at oracle.com wrote: > Hello Jay > > I looked into the changes. Please find my suggestions herewith. > > . Refer to the javadocs of File class. It mentions that a directory > could be deleted only if it's empty. > Hence, invoking directory.delete() will not work because a temp file > would already exist in it. > Besides why should we delete a directory that is created by the test > suite. > 66 final File file = File.createTempFile("temp", ".img", > directory); > 67 directory.delete(); > > . Assuming the call to prepareWriteSequence fails, the subsequent call > to Files.delete(...) at Line 78 will throw an exception. > FileOutputStream should be closed here as well. Similar to changes > in Line 86. > 78 Files.delete(file.toPath()); > > Thank you > Have a good day > > Prahalad N. > > -------------------- > From: Jayathirth D V > Sent: Monday, July 10, 2017 4:12 PM > To: 2d-dev at openjdk.java.net > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 > Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ > > Issue : Temporary image files created in test case are not getting > deleted after test execution is finished. > Root cause : ImageOutputStream related to the file was closed > previously and not FileOutputStream which was its parent. > Solution : Closing the FileOutputStream allows us to delete temporary > file. Also replaced file.deleteOnExit() with Files.delete(). > > Thanks, > Jay From prahalad.kumar.narayanan at oracle.com Wed Jul 12 06:20:55 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 11 Jul 2017 23:20:55 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: References: Message-ID: Hello Jay The changes look good and contains lesser code than the earlier revision. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:46 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Hi Sergey & Prahalad, Thanks for your suggestions. I have updated the test case to use finally block to delete the resources. Some of the changes previously present in test case are because of typo mistakes picked from another test case. Please find the updated webrev: http://cr.openjdk.java.net/~jdv/8183349/webrev.01/ Regards, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:08 AM To: Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net; Jayathirth D V Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java I guess the only change which is needed is to wrap the test() method in the try catch and add "Files.delete(file.toPath());fos.close();" to the finally block. It seems will have less code. It is unclear why the test was changed to the manual? ----- prahalad.kumar.narayanan at oracle.com wrote: > Hello Jay > > I looked into the changes. Please find my suggestions herewith. > > . Refer to the javadocs of File class. It mentions that a directory > could be deleted only if it's empty. > Hence, invoking directory.delete() will not work because a temp file > would already exist in it. > Besides why should we delete a directory that is created by the test > suite. > 66 final File file = File.createTempFile("temp", ".img", > directory); > 67 directory.delete(); > > . Assuming the call to prepareWriteSequence fails, the subsequent call > to Files.delete(...) at Line 78 will throw an exception. > FileOutputStream should be closed here as well. Similar to changes > in Line 86. > 78 Files.delete(file.toPath()); > > Thank you > Have a good day > > Prahalad N. > > -------------------- > From: Jayathirth D V > Sent: Monday, July 10, 2017 4:12 PM > To: 2d-dev at openjdk.java.net > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 > Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ > > Issue : Temporary image files created in test case are not getting > deleted after test execution is finished. > Root cause : ImageOutputStream related to the file was closed > previously and not FileOutputStream which was its parent. > Solution : Closing the FileOutputStream allows us to delete temporary > file. Also replaced file.deleteOnExit() with Files.delete(). > > Thanks, > Jay From jayathirth.d.v at oracle.com Wed Jul 12 06:22:51 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 11 Jul 2017 23:22:51 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> Message-ID: Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Wed Jul 12 07:19:45 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Jul 2017 00:19:45 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Message-ID: <0bf1b847-7ddc-46a9-9b48-b06aaab49adb@default> +1 ----- prahalad.kumar.narayanan at oracle.com wrote: > Hello Jay > > The changes look good and contains lesser code than the earlier > revision. > > Thanks > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, July 12, 2017 11:46 AM > To: Sergey Bylokhov; Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > Hi Sergey & Prahalad, > > Thanks for your suggestions. > I have updated the test case to use finally block to delete the > resources. Some of the changes previously present in test case are > because of typo mistakes picked from another test case. > Please find the updated webrev: > http://cr.openjdk.java.net/~jdv/8183349/webrev.01/ > > Regards, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, July 12, 2017 12:08 AM > To: Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net; Jayathirth D V > Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > I guess the only change which is needed is to wrap the test() method > in the try catch and add "Files.delete(file.toPath());fos.close();" to > the finally block. It seems will have less code. It is unclear why the > test was changed to the manual? > > > ----- prahalad.kumar.narayanan at oracle.com wrote: > > > Hello Jay > > > > I looked into the changes. Please find my suggestions herewith. > > > > . Refer to the javadocs of File class. It mentions that a directory > > > could be deleted only if it's empty. > > Hence, invoking directory.delete() will not work because a temp > file > > would already exist in it. > > Besides why should we delete a directory that is created by the > test > > suite. > > 66 final File file = File.createTempFile("temp", > ".img", > > directory); > > 67 directory.delete(); > > > > . Assuming the call to prepareWriteSequence fails, the subsequent > call > > to Files.delete(...) at Line 78 will throw an exception. > > FileOutputStream should be closed here as well. Similar to changes > > > in Line 86. > > 78 Files.delete(file.toPath()); > > > > Thank you > > Have a good day > > > > Prahalad N. > > > > -------------------- > > From: Jayathirth D V > > Sent: Monday, July 10, 2017 4:12 PM > > To: 2d-dev at openjdk.java.net > > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > > WriteAfterAbort.java > > > > Hello All, > > > > Please review the following fix in JDK10 : > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 > > Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ > > > > Issue : Temporary image files created in test case are not getting > > deleted after test execution is finished. > > Root cause : ImageOutputStream related to the file was closed > > previously and not FileOutputStream which was its parent. > > Solution : Closing the FileOutputStream allows us to delete > temporary > > file. Also replaced file.deleteOnExit() with Files.delete(). > > > > Thanks, > > Jay From shashidhara.veerabhadraiah at oracle.com Wed Jul 12 09:19:53 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Wed, 12 Jul 2017 02:19:53 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> Message-ID: Thanks for that suggestion Jay. I have modified with some changes so that we don?t run into a null pointer exception!! And here is the new Webrev for the same: ? http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:53 AM To: Shashidhara Veerabhadraiah Cc: 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jul 12 09:44:13 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 12 Jul 2017 02:44:13 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> Message-ID: <87e062e6-1e79-4237-87e9-0425aa467da0@default> Hello Shashi, ? Changes are fine. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 2:50 PM To: Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Thanks for that suggestion Jay. I have modified with some changes so that we don?t run into a null pointer exception!! And here is the new Webrev for the same: ? http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:53 AM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jul 12 10:34:58 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 12 Jul 2017 03:34:58 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: <0bf1b847-7ddc-46a9-9b48-b06aaab49adb@default> References: <0bf1b847-7ddc-46a9-9b48-b06aaab49adb@default> Message-ID: <6483ea19-50a5-442e-b7b1-dee8b9cf4c61@default> Hello All, I added null check in finally block of test case after getting inputs from similar change in JDK-8183341. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8183349/webrev.02/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:50 PM To: Prahalad Kumar Narayanan Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java +1 ----- prahalad.kumar.narayanan at oracle.com wrote: > Hello Jay > > The changes look good and contains lesser code than the earlier > revision. > > Thanks > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, July 12, 2017 11:46 AM > To: Sergey Bylokhov; Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > Hi Sergey & Prahalad, > > Thanks for your suggestions. > I have updated the test case to use finally block to delete the > resources. Some of the changes previously present in test case are > because of typo mistakes picked from another test case. > Please find the updated webrev: > http://cr.openjdk.java.net/~jdv/8183349/webrev.01/ > > Regards, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, July 12, 2017 12:08 AM > To: Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net; Jayathirth D V > Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > I guess the only change which is needed is to wrap the test() method > in the try catch and add "Files.delete(file.toPath());fos.close();" to > the finally block. It seems will have less code. It is unclear why the > test was changed to the manual? > > > ----- prahalad.kumar.narayanan at oracle.com wrote: > > > Hello Jay > > > > I looked into the changes. Please find my suggestions herewith. > > > > . Refer to the javadocs of File class. It mentions that a directory > > > could be deleted only if it's empty. > > Hence, invoking directory.delete() will not work because a temp > file > > would already exist in it. > > Besides why should we delete a directory that is created by the > test > > suite. > > 66 final File file = File.createTempFile("temp", > ".img", > > directory); > > 67 directory.delete(); > > > > . Assuming the call to prepareWriteSequence fails, the subsequent > call > > to Files.delete(...) at Line 78 will throw an exception. > > FileOutputStream should be closed here as well. Similar to changes > > > in Line 86. > > 78 Files.delete(file.toPath()); > > > > Thank you > > Have a good day > > > > Prahalad N. > > > > -------------------- > > From: Jayathirth D V > > Sent: Monday, July 10, 2017 4:12 PM > > To: 2d-dev at openjdk.java.net > > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > > WriteAfterAbort.java > > > > Hello All, > > > > Please review the following fix in JDK10 : > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 > > Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ > > > > Issue : Temporary image files created in test case are not getting > > deleted after test execution is finished. > > Root cause : ImageOutputStream related to the file was closed > > previously and not FileOutputStream which was its parent. > > Solution : Closing the FileOutputStream allows us to delete > temporary > > file. Also replaced file.deleteOnExit() with Files.delete(). > > > > Thanks, > > Jay From prahalad.kumar.narayanan at oracle.com Thu Jul 13 05:27:57 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 12 Jul 2017 22:27:57 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: <6483ea19-50a5-442e-b7b1-dee8b9cf4c61@default> References: <0bf1b847-7ddc-46a9-9b48-b06aaab49adb@default> <6483ea19-50a5-442e-b7b1-dee8b9cf4c61@default> Message-ID: <05044828-47fb-4bb2-a898-b52b9006419e@default> Hello Jay Minor changes have been added. Looks good. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Wednesday, July 12, 2017 4:05 PM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Hello All, I added null check in finally block of test case after getting inputs from similar change in JDK-8183341. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8183349/webrev.02/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:50 PM To: Prahalad Kumar Narayanan Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java +1 ----- prahalad.kumar.narayanan at oracle.com wrote: > Hello Jay > > The changes look good and contains lesser code than the earlier > revision. > > Thanks > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, July 12, 2017 11:46 AM > To: Sergey Bylokhov; Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > Hi Sergey & Prahalad, > > Thanks for your suggestions. > I have updated the test case to use finally block to delete the > resources. Some of the changes previously present in test case are > because of typo mistakes picked from another test case. > Please find the updated webrev: > http://cr.openjdk.java.net/~jdv/8183349/webrev.01/ > > Regards, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, July 12, 2017 12:08 AM > To: Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net; Jayathirth D V > Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > I guess the only change which is needed is to wrap the test() method > in the try catch and add "Files.delete(file.toPath());fos.close();" to > the finally block. It seems will have less code. It is unclear why the > test was changed to the manual? > > > ----- prahalad.kumar.narayanan at oracle.com wrote: > > > Hello Jay > > > > I looked into the changes. Please find my suggestions herewith. > > > > . Refer to the javadocs of File class. It mentions that a directory > > > could be deleted only if it's empty. > > Hence, invoking directory.delete() will not work because a temp > file > > would already exist in it. > > Besides why should we delete a directory that is created by the > test > > suite. > > 66 final File file = File.createTempFile("temp", > ".img", > > directory); > > 67 directory.delete(); > > > > . Assuming the call to prepareWriteSequence fails, the subsequent > call > > to Files.delete(...) at Line 78 will throw an exception. > > FileOutputStream should be closed here as well. Similar to changes > > > in Line 86. > > 78 Files.delete(file.toPath()); > > > > Thank you > > Have a good day > > > > Prahalad N. > > > > -------------------- > > From: Jayathirth D V > > Sent: Monday, July 10, 2017 4:12 PM > > To: 2d-dev at openjdk.java.net > > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > > WriteAfterAbort.java > > > > Hello All, > > > > Please review the following fix in JDK10 : > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 > > Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ > > > > Issue : Temporary image files created in test case are not getting > > deleted after test execution is finished. > > Root cause : ImageOutputStream related to the file was closed > > previously and not FileOutputStream which was its parent. > > Solution : Closing the FileOutputStream allows us to delete > temporary > > file. Also replaced file.deleteOnExit() with Files.delete(). > > > > Thanks, > > Jay From bourges.laurent at gmail.com Thu Jul 13 07:36:01 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 13 Jul 2017 09:36:01 +0200 Subject: [OpenJDK 2D-Dev] [10] RFR 8078192: Path2D storage trimming In-Reply-To: References: <4a1d1917-dad7-6139-937a-39170c07b196@oracle.com> <58F92273.6080403@oracle.com> <58F93390.3060302@oracle.com> <81bf576a-ddfe-9174-b234-7d070e163d26@oracle.com> <59386886.8050309@oracle.com> <6402b5d2-1179-3d6a-3c9d-34be974637a1@oracle.com> Message-ID: Jim or Phil, Could you handle the CSR process on that patch and then push it in jdk10 ? I consider that bug finished on my side. Laurent Le 8 juil. 2017 10:02, "Laurent Bourg?s" a ?crit : > Phil, > > Here are my comments on this CSR to be fixed in openjdk 10; I already > submitted a patch and the review process happened in may. > > Le 3 juil. 2017 7:41 PM, "Phil Race" a ?crit : > > Laurent, > > Investigation has determined that since this was ported over in the "CCC > migration project", > due to the way that is set up it can't be assigned to non-Oracle employees. > > > Ok, no problem. > > > It won't affect any new CSRs that are created. > > Since the likelihood of any other similar case is extremely low, the > simplest answer is > that either Jim or myself will need to own and edit this one on your > behalf. > > Send Jim or myself the changes you would like to make off-line and we'll > take care of it. > > > Just change the fix version to 10 and the @since javadoc tag as below: > > /** > * Trims the capacity of this Path2D instance to its current > * size. An application can use this operation to minimize the > * storage of a path. > * > * @since 10 > */ + public abstract void trimToSize(); > > It will match the proposed patch. > > Thanks, > Laurent > > > >>>> 2017-04-20 23:04 GMT+02:00 Philip Race : >>>> >>>>> You have a capital letter here and I think it must be lower case .. >>>>> >>>>> >>>>> 2499 * @Since 10 >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 4/20/17, 1:58 PM, Laurent Bourg?s wrote: >>>>> >>>>> Hi Phil & Jim, >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.2/ >>>>> >>>>> Changes: >>>>> - trimToSize() return void >>>>> - fixed test + jtreg passed >>>>> >>>>> Bye, >>>>> Laurent >>>>> >>>>> 2017-04-20 21:30 GMT+02:00 Jim Graham : >>>>> >>>>>> Hi Laurent, >>>>>> >>>>>> The implementation looks good, except that the method chaining-style >>>>>> return value seems out of place here. Similar trimToSize() methods in >>>>>> Collections return void and none of the other methods in this area use the >>>>>> method chaining paradigm. In the interest of maintaining a common design >>>>>> theme throughout 2D this method should just return void. >>>>>> >>>>>> ...jim >>>>>> >>>>>> >>>>>> On 4/18/17 11:49 PM, Laurent Bourg?s wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Here is a first attempt to propose a Path2D patch (based on JDK10): >>>>>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.0/ >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078192 >>>>>>> >>>>>>> Please review the Path2D changes, notably the javadoc (english) and >>>>>>> the modified Path2DCopyConstructor >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.abeles at gmail.com Thu Jul 13 19:13:07 2017 From: peter.abeles at gmail.com (Peter A) Date: Thu, 13 Jul 2017 12:13:07 -0700 Subject: [OpenJDK 2D-Dev] Provide access to data offset in WritableRaster in Java 9 Message-ID: Apologies since this probably not the correct list, but I was referenced here from another Java list. I've actually been getting bounced around to a few mailing lists. I'm hopeful that this is the right now! Background: The high level API in a BufferedImage is very very very slow. To get around that problem, in previous versions of Java, the internal rasters which were defined in sun.awt.image were accessed. Doing so enabled real-time computer vision in Java. Problem: Accessing the low level Rasters is no longer practical in Java 9. After this problem was reported by one of my users I looked into it and *almost* found a work around Unfortunately the higher level WritableRaster does not provide access to the offset inside its internal data array. This makes processing of subimages impossible. My suspicion is that it is most likely an oversight because it provides access to every other piece of information needed and the raw data. It would be great if getDataOffset() could be moved into WritableRaster or one of its parents instead of being hidden in children of WritableRaster which are no longer accessible. Just to clarify the raw arrays are stored inside of a DataBuffer and that data structure contains an offset. This offset is always set to zero and the offset inside of WritableRaster is what is needed, e.g. IntegerInterleavedRaster.getDataOffsets(). Thanks, - Peter -- "Now, now my good man, this is no time for making enemies." ? Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 13 19:18:14 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Jul 2017 12:18:14 -0700 Subject: [OpenJDK 2D-Dev] Provide access to data offset in WritableRaster in Java 9 In-Reply-To: References: Message-ID: Hello, Yes this is the right list, and my reply on jigsaw-dev stands :- Sounds like you were accessing jdk internals and found that you mostly can do away with that except for sub-images. What you should really do is file an issue at bugs.java.com as client-libs/2d for cat/subcat. If this had been raised earlier in JDK 9 development - we could have looked into it in time. Now it will have to wait for a follow on release. -phil. On 7/13/2017 12:13 PM, Peter A wrote: > Apologies since this probably not the correct list, but I was > referenced here from another Java list. I've actually been getting > bounced around to a few mailing lists. I'm hopeful that this is the > right now! > > Background: > The high level API in a BufferedImage is very very very slow. To get > around that problem, in previous versions of Java, the internal > rasters which were defined in sun.awt.image were accessed. Doing so > enabled real-time computer vision in Java. > > Problem: > Accessing the low level Rasters is no longer practical in Java 9. > After this problem was reported by one of my users I looked into it > and *almost* found a work around Unfortunately the higher level > WritableRaster does not provide access to the offset inside its > internal data array. This makes processing of subimages impossible. > My suspicion is that it is most likely an oversight because it > provides access to every other piece of information needed and the raw > data. It would be great if getDataOffset() could be moved into > WritableRaster or one of its parents instead of being hidden in > children of WritableRaster which are no longer accessible. > > Just to clarify the raw arrays are stored inside of a DataBuffer and > that data structure contains an offset. This offset is always set to > zero and the offset inside of WritableRaster is what is needed, > e.g. IntegerInterleavedRaster.getDataOffsets(). > > Thanks, > - Peter > > -- > "Now, now my good man, this is no time for making enemies." ? > Voltaire (1694-1778), on his deathbed in response to a priest asking > that he renounce Satan. From philip.race at oracle.com Thu Jul 13 19:32:47 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Jul 2017 12:32:47 -0700 Subject: [OpenJDK 2D-Dev] Provide access to data offset in WritableRaster in Java 9 In-Reply-To: References: Message-ID: PS when filing the bug a self-contained (fully compilable) code example showing what you would are trying to do will help. Yes .. I guess you will need to use the internal API in that case but it is a lot easier to unambigiously convey reqiurements with code if possible. -phil. On 07/13/2017 12:18 PM, Phil Race wrote: > Hello, > > Yes this is the right list, and my reply on jigsaw-dev stands :- > > Sounds like you were accessing jdk internals and found that you > mostly can do away with that except for sub-images. > > What you should really do is file an issue at bugs.java.com as > client-libs/2d for cat/subcat. > > If this had been raised earlier in JDK 9 development - we could have > looked into > it in time. Now it will have to wait for a follow on release. > > -phil. > > On 7/13/2017 12:13 PM, Peter A wrote: >> Apologies since this probably not the correct list, but I was >> referenced here from another Java list. I've actually been getting >> bounced around to a few mailing lists. I'm hopeful that this is the >> right now! >> >> Background: >> The high level API in a BufferedImage is very very very slow. To get >> around that problem, in previous versions of Java, the internal >> rasters which were defined in sun.awt.image were accessed. Doing so >> enabled real-time computer vision in Java. >> >> Problem: >> Accessing the low level Rasters is no longer practical in Java 9. >> After this problem was reported by one of my users I looked into it >> and *almost* found a work around Unfortunately the higher level >> WritableRaster does not provide access to the offset inside its >> internal data array. This makes processing of subimages >> impossible. My suspicion is that it is most likely an oversight >> because it provides access to every other piece of information needed >> and the raw data. It would be great if getDataOffset() could be >> moved into WritableRaster or one of its parents instead of being >> hidden in children of WritableRaster which are no longer accessible. >> >> Just to clarify the raw arrays are stored inside of a DataBuffer and >> that data structure contains an offset. This offset is always set to >> zero and the offset inside of WritableRaster is what is needed, e.g. >> IntegerInterleavedRaster.getDataOffsets(). >> >> Thanks, >> - Peter >> >> -- >> "Now, now my good man, this is no time for making enemies." ? >> Voltaire (1694-1778), on his deathbed in response to a priest asking >> that he renounce Satan. > > From shashidhara.veerabhadraiah at oracle.com Fri Jul 14 04:30:44 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 13 Jul 2017 21:30:44 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: <87e062e6-1e79-4237-87e9-0425aa467da0@default> References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> Message-ID: Hi All, Anything more comments on this? Can I close this now? ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 3:14 PM To: Shashidhara Veerabhadraiah Cc: 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? Changes are fine. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 2:50 PM To: Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Thanks for that suggestion Jay. I have modified with some changes so that we don?t run into a null pointer exception!! And here is the new Webrev for the same: ? http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:53 AM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Fri Jul 14 12:01:53 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 14 Jul 2017 05:01:53 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> Message-ID: <8354d17b-67f5-40df-b647-2111e1c466e5@default> A nit? There should be a space between if and ( -- on lines 65 and 70. You can make this change before pushing. No need to have a new webrev just for this. ? Regards, Ajit ? From: Shashidhara Veerabhadraiah Sent: Friday, July 14, 2017 10:01 AM To: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi All, Anything more comments on this? Can I close this now? ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 3:14 PM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? Changes are fine. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 2:50 PM To: Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Thanks for that suggestion Jay. I have modified with some changes so that we don?t run into a null pointer exception!! And here is the new Webrev for the same: ? http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:53 AM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Fri Jul 14 12:10:36 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Fri, 14 Jul 2017 05:10:36 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: <8354d17b-67f5-40df-b647-2111e1c466e5@default> References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> <8354d17b-67f5-40df-b647-2111e1c466e5@default> Message-ID: <15db8c02-e878-4402-8b6c-768f495d9874@default> Sure Ajit. Will take care of that before pushing the change. ? Thanks and regards, Shashi ? From: Ajit Ghaisas Sent: Friday, July 14, 2017 5:32 PM To: Shashidhara Veerabhadraiah ; 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? A nit? There should be a space between if and ( -- on lines 65 and 70. You can make this change before pushing. No need to have a new webrev just for this. ? Regards, Ajit ? From: Shashidhara Veerabhadraiah Sent: Friday, July 14, 2017 10:01 AM To: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi All, Anything more comments on this? Can I close this now? ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 3:14 PM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? Changes are fine. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 2:50 PM To: Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Thanks for that suggestion Jay. I have modified with some changes so that we don?t run into a null pointer exception!! And here is the new Webrev for the same: ? http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:53 AM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Jul 14 12:17:27 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Jul 2017 05:17:27 -0700 Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: <8354d17b-67f5-40df-b647-2111e1c466e5@default> References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> <8354d17b-67f5-40df-b647-2111e1c466e5@default> Message-ID: <5968B657.6040805@oracle.com> As long as you are fixing the 'if(' ... can you add curly braces around the body of the target statement? The following pattern: if (condition) statement; is not in keeping with our coding style and can be a source of bugs later if a statement should be added. Thanks. -- Kevin Ajit Ghaisas wrote: > > A nit? > > There should be a space between if and ( -- on lines 65 and 70. > > You can make this change before pushing. No need to have a new webrev > just for this. > > > > Regards, > > Ajit > > > > *From:* Shashidhara Veerabhadraiah > *Sent:* Friday, July 14, 2017 10:01 AM > *To:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > > > Hi All, Anything more comments on this? Can I close this now? > > > > Thanks and regards, > > Shashi > > > > *From:* Jayathirth D V > *Sent:* Wednesday, July 12, 2017 3:14 PM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > > > Hello Shashi, > > > > Changes are fine. > > > > Thanks, > > Jay > > > > *From:* Shashidhara Veerabhadraiah > *Sent:* Wednesday, July 12, 2017 2:50 PM > *To:* Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan > *Cc:* 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > > > Thanks for that suggestion Jay. I have modified with some changes so > that we don?t run into a null pointer exception!! And here is the new > Webrev for the same: > > > > http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ > > > > > Thanks and regards, > > Shashi > > > > *From:* Jayathirth D V > *Sent:* Wednesday, July 12, 2017 11:53 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > > > Hello Shashi, > > > > The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. > In that case we will not reach finally block and temporary file will not be deleted. > Including complete code of test() function in try{} and deleting resources in finally block will be a better option. > > > Thanks, > > Jay > > > > *From:* Shashidhara Veerabhadraiah > *Sent:* Wednesday, July 12, 2017 11:03 AM > *To:* Sergey Bylokhov; Prahalad Kumar Narayanan > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > > > Sergey, Thank you for the excellent suggestion. I have updated the > Webrev accordingly. > > > > Prahalad, With the use of Sergey?s suggestion of adding an finally > block solves the problem of not deleting files on a fail case. > > . Was the bug reproducible at your end ? > > Yes, it was reproducible. We can see the temp files hanging at %temp% > folder. > > . If yes, was it reproducible when the test succeeded /or when > the test failed ? > > Yes, it was reproducible on success for sure. The fail case was not > tested as that would require me to do an undo of an earlier changeset > change. But I think the output would remain the same as the pass case. > > . Is there a difference in the VM's termination based on the > outcome of the test case. > > Not sure since the fail case was not tested. But per the code, it is > sure that it will have differences. The finally block should fix this > problem. > > . How many such test cases exist that need similar clean up ? > > . grep on 'deleteOnExit' within jdk/test/javax/imageio/ > gives me atleast 10 instances. > > . grep on 'File.createTempFile' within same directory > gives me 29 instances. > > Am not sure what to do with respect to them. Should I raise new bugs > if there is problem with them(if not on the bug db) and fix it? > > > > Updated Webrev: > > http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ > > > > > Thanks and regards, > > Shashi > > > > *From:* Sergey Bylokhov > *Sent:* Wednesday, July 12, 2017 12:13 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Prasanta Sadhukhan >; 2d-dev at openjdk.java.net > ; Philip Race > > *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > > > Hi Shashi. > I suggest to add a finally to the try block in the test() method and > delete the file, close the stream and close the reader there. > > ----- shashidhara.veerabhadraiah at oracle.com > wrote: > > > > Hi All, > > Please review a fix for a test bug which was not cleaning up the > temporary test files that it used to create. > > The issue with this test was that the test used to create temporary > files but not deleting them. > > The updated test file does the deletion of the temporary files that > the test is creating. > > Bug: > > > > Webrev: > > > > > Note: The user had requested to create the temporary files in > user.dir. But I think it is good to create the temporary files in the > system temp directory and use it for testing and later delete the > same. Besides if required the user has the choice to change the temp > directory to the directory they wish for. > > Thanks and regards, > > Shashi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 14 14:15:31 2017 From: philip.race at oracle.com (Philip Race) Date: Fri, 14 Jul 2017 07:15:31 -0700 Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: <5968B657.6040805@oracle.com> References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> <8354d17b-67f5-40df-b647-2111e1c466e5@default> <5968B657.6040805@oracle.com> Message-ID: <5968D203.1090203@oracle.com> I think it best to send an updated webrev since I'd like to make sure the changes are made everywhere as requested. -phil. On 7/14/17, 5:17 AM, Kevin Rushforth wrote: > As long as you are fixing the 'if(' ... can you add curly braces > around the body of the target statement? > > The following pattern: > > if (condition) > statement; > > is not in keeping with our coding style and can be a source of bugs > later if a statement should be added. > > Thanks. > > -- Kevin > > > Ajit Ghaisas wrote: >> >> A nit? >> >> There should be a space between if and ( -- on lines 65 and 70. >> >> You can make this change before pushing. No need to have a new webrev >> just for this. >> >> Regards, >> >> Ajit >> >> *From:*Shashidhara Veerabhadraiah >> *Sent:* Friday, July 14, 2017 10:01 AM >> *To:* 2d-dev at openjdk.java.net >> *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for >> javax/imageio/AllowSearch.java >> >> Hi All, Anything more comments on this? Can I close this now? >> >> Thanks and regards, >> >> Shashi >> >> *From:*Jayathirth D V >> *Sent:* Wednesday, July 12, 2017 3:14 PM >> *To:* Shashidhara Veerabhadraiah >> > > >> *Cc:* 2d-dev at openjdk.java.net >> *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for >> javax/imageio/AllowSearch.java >> >> Hello Shashi, >> >> Changes are fine. >> >> Thanks, >> >> Jay >> >> *From:*Shashidhara Veerabhadraiah >> *Sent:* Wednesday, July 12, 2017 2:50 PM >> *To:* Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan >> *Cc:* 2d-dev at openjdk.java.net >> *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for >> javax/imageio/AllowSearch.java >> >> Thanks for that suggestion Jay. I have modified with some changes so >> that we don?t run into a null pointer exception!! And here is the new >> Webrev for the same: >> >> http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ >> >> >> Thanks and regards, >> >> Shashi >> >> *From:*Jayathirth D V >> *Sent:* Wednesday, July 12, 2017 11:53 AM >> *To:* Shashidhara Veerabhadraiah >> > > >> *Cc:* 2d-dev at openjdk.java.net >> *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for >> javax/imageio/AllowSearch.java >> >> Hello Shashi, >> >> The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. >> In that case we will not reach finally block and temporary file will not be deleted. >> Including complete code of test() function in try{} and deleting resources in finally block will be a better option. >> >> >> Thanks, >> >> Jay >> >> *From:*Shashidhara Veerabhadraiah >> *Sent:* Wednesday, July 12, 2017 11:03 AM >> *To:* Sergey Bylokhov; Prahalad Kumar Narayanan >> *Cc:* 2d-dev at openjdk.java.net >> *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for >> javax/imageio/AllowSearch.java >> >> Sergey, Thank you for the excellent suggestion. I have updated the >> Webrev accordingly. >> >> Prahalad, With the use of Sergey?s suggestion of adding an finally >> block solves the problem of not deleting files on a fail case. >> >> . Was the bug reproducible at your end ? >> >> Yes, it was reproducible. We can see the temp files hanging at %temp% >> folder. >> >> . If yes, was it reproducible when the test succeeded /or when >> the test failed ? >> >> Yes, it was reproducible on success for sure. The fail case was not >> tested as that would require me to do an undo of an earlier changeset >> change. But I think the output would remain the same as the pass case. >> >> . Is there a difference in the VM's termination based on the >> outcome of the test case. >> >> Not sure since the fail case was not tested. But per the code, it is >> sure that it will have differences. The finally block should fix this >> problem. >> >> . How many such test cases exist that need similar clean up ? >> >> . grep on 'deleteOnExit' within jdk/test/javax/imageio/ >> gives me atleast 10 instances. >> >> . grep on 'File.createTempFile' within same directory >> gives me 29 instances. >> >> Am not sure what to do with respect to them. Should I raise new bugs >> if there is problem with them(if not on the bug db) and fix it? >> >> Updated Webrev: >> >> http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ >> >> >> Thanks and regards, >> >> Shashi >> >> *From:*Sergey Bylokhov >> *Sent:* Wednesday, July 12, 2017 12:13 AM >> *To:* Shashidhara Veerabhadraiah >> > > >> *Cc:* Prasanta Sadhukhan > >; 2d-dev at openjdk.java.net >> ; Philip Race > > >> *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for >> javax/imageio/AllowSearch.java >> >> Hi Shashi. >> I suggest to add a finally to the try block in the test() method and >> delete the file, close the stream and close the reader there. >> >> ----- shashidhara.veerabhadraiah at oracle.com >> wrote: >> > >> >> Hi All, >> >> Please review a fix for a test bug whichwas not cleaning up >> thetemporary test files that it used to create. >> >> The issue with this test was that the test used to createtemporary >> files but not deleting them. >> >> The updated test filedoes the deletion of the temporary files that >> the test is creating. >> >> Bug: >> >> >> >> Webrev: >> >> > > >> >> Note: The user had requested to create the temporary files >> inuser.dir. ButIthink it is good to createthe temporary filesinthe >> system temp directory anduse it for testing and later delete the >> same. Besides if required the user has the choice to change the temp >> directory to the directory they wish for. >> >> Thanks and regards, >> >> Shashi >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 14 20:50:58 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 14 Jul 2017 13:50:58 -0700 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: <05044828-47fb-4bb2-a898-b52b9006419e@default> References: <0bf1b847-7ddc-46a9-9b48-b06aaab49adb@default> <6483ea19-50a5-442e-b7b1-dee8b9cf4c61@default> <05044828-47fb-4bb2-a898-b52b9006419e@default> Message-ID: <485d456f-7581-e072-f64f-dba5d8be2dc0@oracle.com> +1 On 12.07.2017 22:27, Prahalad Kumar Narayanan wrote: > Hello Jay > > Minor changes have been added. > Looks good. > > Thank you > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, July 12, 2017 4:05 PM > To: Sergey Bylokhov; Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java > > Hello All, > > I added null check in finally block of test case after getting inputs from similar change in JDK-8183341. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8183349/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, July 12, 2017 12:50 PM > To: Prahalad Kumar Narayanan > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java > > +1 > > ----- prahalad.kumar.narayanan at oracle.com wrote: > >> Hello Jay >> >> The changes look good and contains lesser code than the earlier >> revision. >> >> Thanks >> Have a good day >> >> Prahalad N. >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Wednesday, July 12, 2017 11:46 AM >> To: Sergey Bylokhov; Prahalad Kumar Narayanan >> Cc: 2d-dev at openjdk.java.net >> Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for >> jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and >> WriteAfterAbort.java >> >> Hi Sergey & Prahalad, >> >> Thanks for your suggestions. >> I have updated the test case to use finally block to delete the >> resources. Some of the changes previously present in test case are >> because of typo mistakes picked from another test case. >> Please find the updated webrev: >> http://cr.openjdk.java.net/~jdv/8183349/webrev.01/ >> >> Regards, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, July 12, 2017 12:08 AM >> To: Prahalad Kumar Narayanan >> Cc: 2d-dev at openjdk.java.net; Jayathirth D V >> Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for >> jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and >> WriteAfterAbort.java >> >> I guess the only change which is needed is to wrap the test() method >> in the try catch and add "Files.delete(file.toPath());fos.close();" to >> the finally block. It seems will have less code. It is unclear why the >> test was changed to the manual? >> >> >> ----- prahalad.kumar.narayanan at oracle.com wrote: >> >>> Hello Jay >>> >>> I looked into the changes. Please find my suggestions herewith. >>> >>> . Refer to the javadocs of File class. It mentions that a directory >> >>> could be deleted only if it's empty. >>> Hence, invoking directory.delete() will not work because a temp >> file >>> would already exist in it. >>> Besides why should we delete a directory that is created by the >> test >>> suite. >>> 66 final File file = File.createTempFile("temp", >> ".img", >>> directory); >>> 67 directory.delete(); >>> >>> . Assuming the call to prepareWriteSequence fails, the subsequent >> call >>> to Files.delete(...) at Line 78 will throw an exception. >>> FileOutputStream should be closed here as well. Similar to changes >> >>> in Line 86. >>> 78 Files.delete(file.toPath()); >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> -------------------- >>> From: Jayathirth D V >>> Sent: Monday, July 10, 2017 4:12 PM >>> To: 2d-dev at openjdk.java.net >>> Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for >>> jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and >>> WriteAfterAbort.java >>> >>> Hello All, >>> >>> Please review the following fix in JDK10 : >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 >>> Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ >>> >>> Issue : Temporary image files created in test case are not getting >>> deleted after test execution is finished. >>> Root cause : ImageOutputStream related to the file was closed >>> previously and not FileOutputStream which was its parent. >>> Solution : Closing the FileOutputStream allows us to delete >> temporary >>> file. Also replaced file.deleteOnExit() with Files.delete(). >>> >>> Thanks, >>> Jay -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sun Jul 16 23:42:47 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 16 Jul 2017 16:42:47 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8184435 Cleanup of javadoc in javax.print package Message-ID: <1ac217d8-6764-b9b0-c942-ccfc7ffc6290@oracle.com> Hello, Please review the fix for jdk10. The cleanup was done in the same way as for datatransfer, sound and accessibility packages(see links in the CR). I suggest to check the specdiff first, because for some methods the specification was reworked. CSR will be filed after technical review. Bug: https://bugs.openjdk.java.net/browse/JDK-8184435 Webrev can be found at: http://cr.openjdk.java.net/~serb/8184435/webrev.07 Specdiff: http://cr.openjdk.java.net/~serb/8184435/specdiff.07/overview-summary.html In this fix the javadoc is updated and the next rules were applied: - should be replaced by {@tag } - 80 column limit - description of the class/method/field should be followed by dot - @param, @return should not end with a dot, except a case when more than one sentences are used - empty line after description/before the first tag was added - unnecessary empty lines were removed - sets of spaces in the middle of text were deleted - @param, @throws, @return should be aligned, to be more readable - unnecessary imports should be removed - the "null"/"true"/"false"/"this"/"ClassName" should be wrapped in {@code } when necessary - the order of different tags were unified across the package ... etc There are also some mixing of different "reference usage", for example "InputStream" vs "input stream", "String" vs "string", etc. I tried to fix some of them. -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Mon Jul 17 05:58:21 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Sun, 16 Jul 2017 22:58:21 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: <5968D203.1090203@oracle.com> References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> <8354d17b-67f5-40df-b647-2111e1c466e5@default> <5968B657.6040805@oracle.com> <5968D203.1090203@oracle.com> Message-ID: Hi All, Here is the new webrev with the fixes for the comments: ? ? Thanks and regards, Shashi ? From: Philip Race Sent: Friday, July 14, 2017 7:46 PM To: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? I think it best to send an updated webrev since I'd like to make sure the changes are made everywhere as requested. -phil. On 7/14/17, 5:17 AM, Kevin Rushforth wrote: As long as you are fixing the 'if(' ... can you add curly braces around the body of the target statement? The following pattern: ??? if (condition) ??????? statement; is not in keeping with our coding style and can be a source of bugs later if a statement should be added. Thanks. -- Kevin Ajit Ghaisas wrote: A nit? There should be a space between if and ( -- on lines 65 and 70. You can make this change before pushing. No need to have a new webrev just for this. ? Regards, Ajit ? From: Shashidhara Veerabhadraiah Sent: Friday, July 14, 2017 10:01 AM To: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi All, Anything more comments on this? Can I close this now? ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 3:14 PM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? Changes are fine. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 2:50 PM To: Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Thanks for that suggestion Jay. I have modified with some changes so that we don?t run into a null pointer exception!! And here is the new Webrev for the same: ? HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/8183341/webrev_02/"http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:53 AM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/8183341/webrev_01/"http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Jul 17 08:50:45 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 17 Jul 2017 01:50:45 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: <485d456f-7581-e072-f64f-dba5d8be2dc0@oracle.com> References: <0bf1b847-7ddc-46a9-9b48-b06aaab49adb@default> <6483ea19-50a5-442e-b7b1-dee8b9cf4c61@default> <05044828-47fb-4bb2-a898-b52b9006419e@default> <485d456f-7581-e072-f64f-dba5d8be2dc0@oracle.com> Message-ID: Hello Sergey & Prahalad, Thanks for your reviews. I will check-in the changes. Regards, Jay -----Original Message----- From: Sergey Bylokhov Sent: Saturday, July 15, 2017 2:21 AM To: Prahalad Kumar Narayanan; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java +1 On 12.07.2017 22:27, Prahalad Kumar Narayanan wrote: > Hello Jay > > Minor changes have been added. > Looks good. > > Thank you > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Wednesday, July 12, 2017 4:05 PM > To: Sergey Bylokhov; Prahalad Kumar Narayanan > Cc: 2d-dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > Hello All, > > I added null check in finally block of test case after getting inputs from similar change in JDK-8183341. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8183349/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, July 12, 2017 12:50 PM > To: Prahalad Kumar Narayanan > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for > jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and > WriteAfterAbort.java > > +1 > > ----- prahalad.kumar.narayanan at oracle.com wrote: > >> Hello Jay >> >> The changes look good and contains lesser code than the earlier >> revision. >> >> Thanks >> Have a good day >> >> Prahalad N. >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Wednesday, July 12, 2017 11:46 AM >> To: Sergey Bylokhov; Prahalad Kumar Narayanan >> Cc: 2d-dev at openjdk.java.net >> Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup >> for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and >> WriteAfterAbort.java >> >> Hi Sergey & Prahalad, >> >> Thanks for your suggestions. >> I have updated the test case to use finally block to delete the >> resources. Some of the changes previously present in test case are >> because of typo mistakes picked from another test case. >> Please find the updated webrev: >> http://cr.openjdk.java.net/~jdv/8183349/webrev.01/ >> >> Regards, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, July 12, 2017 12:08 AM >> To: Prahalad Kumar Narayanan >> Cc: 2d-dev at openjdk.java.net; Jayathirth D V >> Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup >> for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and >> WriteAfterAbort.java >> >> I guess the only change which is needed is to wrap the test() method >> in the try catch and add "Files.delete(file.toPath());fos.close();" >> to the finally block. It seems will have less code. It is unclear why >> the test was changed to the manual? >> >> >> ----- prahalad.kumar.narayanan at oracle.com wrote: >> >>> Hello Jay >>> >>> I looked into the changes. Please find my suggestions herewith. >>> >>> . Refer to the javadocs of File class. It mentions that a directory >> >>> could be deleted only if it's empty. >>> Hence, invoking directory.delete() will not work because a temp >> file >>> would already exist in it. >>> Besides why should we delete a directory that is created by the >> test >>> suite. >>> 66 final File file = File.createTempFile("temp", >> ".img", >>> directory); >>> 67 directory.delete(); >>> >>> . Assuming the call to prepareWriteSequence fails, the subsequent >> call >>> to Files.delete(...) at Line 78 will throw an exception. >>> FileOutputStream should be closed here as well. Similar to >>> changes >> >>> in Line 86. >>> 78 Files.delete(file.toPath()); >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> -------------------- >>> From: Jayathirth D V >>> Sent: Monday, July 10, 2017 4:12 PM >>> To: 2d-dev at openjdk.java.net >>> Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8183349: Better cleanup for >>> jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and >>> WriteAfterAbort.java >>> >>> Hello All, >>> >>> Please review the following fix in JDK10 : >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8183349 >>> Webrev : http://cr.openjdk.java.net/~jdv/8183349/webrev.00/ >>> >>> Issue : Temporary image files created in test case are not getting >>> deleted after test execution is finished. >>> Root cause : ImageOutputStream related to the file was closed >>> previously and not FileOutputStream which was its parent. >>> Solution : Closing the FileOutputStream allows us to delete >> temporary >>> file. Also replaced file.deleteOnExit() with Files.delete(). >>> >>> Thanks, >>> Jay -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Tue Jul 18 09:55:21 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 18 Jul 2017 02:55:21 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop In-Reply-To: <596275BF.50009@oracle.com> References: <3633d215-ec1a-4c16-a74b-a80627e45cb5@default> <1db4e0a1-63a2-2d15-b6b6-16dba6c1c3b5@oracle.com> <3267ec4c-45ab-4a39-a620-bc987e1e2064@default> <4a9b07a8-5fc9-0ed2-3622-790a9f8f4ac6@oracle.com> <868ecb9f-8ce3-48dd-a347-c487223874f0@default> <3bf67087-64b4-0b50-f09c-abc680c562b9@oracle.com> <0142127f-a994-6f20-8a28-8afe64f8921e@oracle.com> <593877C8.3090708@oracle.com> <32a345ef-9dae-4f98-a6e7-b5dd72d4fc70@default> <9967f1d9-d062-0148-7526-f359e854c89a@oracle.com> <9dcb0639-f1da-6988-2611-b52ca305b876@oracle.com> <58620d3c-70cc-4355-8057-81cf9fc3c322@default> <58a532bd-7c07-fe08-b42c-b9145ead718c@oracle.com> <596275BF.50009@oracle.com> Message-ID: <9e0e9fa1-6db7-49b2-aa28-5b5a15b7bafb@default> Hi Phil, Please see below for my responses: ? New Webrev with fixes @ ? Thanks and regards, Shashi ? From: Philip Race Sent: Sunday, July 9, 2017 11:58 PM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; 2d-dev at openjdk.java.net Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? displays is misspelt as diplsays in at least two cases.[Shashi] Fixed imageable is misspelt as imagable in at least one case.[Shashi] Fixed "imageable area retains even after closing in the" ? Are you trying to say "is retained" ? [Shashi] Paper size ? margin values = new imageable area. So by setting new margin values and closing dialog and when reopened we have the same margin values. But the problem is that we don?t have any api?s to set the margin values but instead we have api for setting a new imageable area. Since we are calling setImageableArea(), the same is mentioned in the instructions box, to indicate that we have called that api and would be expecting the same to be retained back when we open up the printer dialog. Please let me know if this needs any changes. I am still not happy that you are hard-coding values "2" and "3" in the instructions If the printer's default paper is < 6 inches wide this will fail. The whole thing should be adaptive to what it actually sees. [Shashi] The test calls setSize() for the paper object to have a standard size. This function takes the input in parts of 1/72 of an ?inch?. Since a standard size has been set, the undersize fail won?t happen. But without calling setSize() and if we try to make it adaptive then the instructions would need to be dynamic and in which case we may fail in certain cases like the one you mentioned earlier, being ending up with negative values for the imageable area. But this problem won?t be there if we set the values explicitly to a proper size and continue the testing from there. By doing this the intent of the test is not breached I believe. Please let me know if you think otherwise. I am also unclear how you are so sure it'll be inches ? [Shashi] Paper class has setSize() which takes the input as parts of 1/72th of an ?inch?. So the backend is always in this ?parts? unit of an ?inch?. But the printer dialog adapts per the respective locale and changes the values per the selected unit appropriately and proportionately on the dialog. I'd expect most locales to use centimetres, but what you see depends on the platform .. which I expect is why you excluded Mac ? But why are you excluding Solaris too ? [Shashi] Modified test to include Solaris target too. Tested on Solaris 11.3 VM. java.awt.print.PrinterJob.getPrinterJob() ? You are importing all the other classes from java.awt.print, so why not this one too ? [Shashi] Modified test to include this static method import. Whilst I don't have any objection to throwing a runtime exception if the tester presses your FAIL button, you could have just used the "yes/no" support in the jtreg test harness. -phil. On 6/21/17, 1:33 AM, Shashidhara Veerabhadraiah wrote: Hi, Here is the updated Webrev with comment fixes: ? HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/6949753/webrev_06/"http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_06/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, June 12, 2017 11:19 PM To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com" Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? Ok Phil. I shall update the test and send it for re-review tomorrow. ? Thanks and regards, Shashi ? From: Phil Race Sent: Monday, June 12, 2017 11:15 PM To: Shashidhara Veerabhadraiah ; Prasanta Sadhukhan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? The dialog does not show "Letter" because you said so. It shows it because the printer reports it supports letter. -phil. On 06/12/2017 10:44 AM, Shashidhara Veerabhadraiah wrote: Just to clarify Phil for the part of cross platform print dialog, here is that dialog representation: ? ? Since this dialog can appear on any platform, the Paper class would represent the backend object for the front end dialog properties(of a generic printer) as shown in the pic above. Hence the use of the raw Paper object than obtaining it from the page format. At the same time, as you pointed out, the test is not reliable with the actual conditions. The only problem I see is that the moment we change the test case to stay close to the actual scenario we may have certain failures because the settings are different for different locales and it may be difficult to adapt to every possible locales. ? Thanks and regards, Shashi ? ? From: Phil Race Sent: Monday, June 12, 2017 10:01 PM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com" Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? >[Shashi] Yes. I intend to use the default paper object as this is a test related to the cross platform default printer dialog. > In the modified test file, I have set the size of the physical paper instead of relying it on the default setting which may > vary as you pointed out, depending on the locale. >Now that we have our own paper object(with a constant paper size) and based on the margin setting(which are const > it won?t cause an undesirable behavior like going into negative space. ? ? Sorry, that is not a valid thing to do. The print dialog is free to ignore this or workaround the incompatibility of that paper with the supported media so your test is not reliable. And I don't see what the cross platform print dialog has to do with it. It is, or should be, just as aware of the printer sizes as the native one. ? -phil. ? On 06/12/2017 03:34 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, Please see below for the comments: ? The updated Webrev is at: HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/shashi/6949753/webrev_05/"http://cr.openjdk.java.net/~aghaisas/shashi/6949753/webrev_05/ Modified in what way from the previous version ? -phil. ? Thanks and regards, Shashi ? From: Phil Race Sent: Saturday, June 10, 2017 3:07 AM To: Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"; Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? private static void setValuesForPrintPageSetup(PageFormat pageFormat,? int 118??? ?????????marginValue) throws PrinterException { 119???????? Paper paper = new Paper(); double paperHeight = paper.getHeight(); 122???????? double paperWidth = paper.getWidth(); 123???????? double paperX = paper.getImageableX(); 124???????? double paperY = paper.getImageableY(); 125???????? paper.setImageableArea(paperX * marginValue, paperY * marginValue, 126???????????????? paperWidth - (paperX * 2 * marginValue), 127???????????????? paperHeight - (paperY * 2 * marginValue)); ? ? 105???????? setValuesForPrintPageSetup(pageFormat, 3); ? ? I see you call new Paper() above https://docs.oracle.com/javase/8/docs/api/java/awt/print/Paper.html#Paper-- ? Did you really intend to use a default paper instead of getting the one from the pageFormat ? On some label printer your Letter Paper may not even be supported. US (aka NA) Letter is 8.5" wide. ? Also although it probably will work out OK the maths isn't checking for boundary problems. ? default margin will be 1" so that's what you'll get for paperX and paperY ? Using your value of 3 we set the imagable area such that imageable X = 1 * 3 = 3 imageableWidth = 8.5 - (1 * 2 *3) = 8.5 - 6 = 2.5; ? Fortunately that worked out positive .. but it does not seem to be enforced. ? If we'd used 5 it would be a different story : ? ix = 5, iw = 8.5 - ( 1 * 2 * 5) = -1.5 ? The implementation will (should) clamp it to non-negative but it might still be better to have some defensive logic of your own. [Shashi] Yes. I intend to use the default paper object as this is a test related to the cross platform default printer dialog. In the modified test file, I have set the size of the physical paper instead of relying it on the default setting which may vary as you pointed out, depending on the locale. Now that we have our own paper object(with a constant paper size) and based on the margin setting(which are constants), it won?t cause an undesirable behavior like going into negative space. ? nit: there's a missing space here ? 75???????????????? } catch(PrinterException e) { [Shashi] This is fixed now. ? -phil. ? On 06/09/2017 03:27 AM, Prasanta Sadhukhan wrote: looks good to me. Regards Prasanta On 6/9/2017 3:49 PM, Shashidhara Veerabhadraiah wrote: Hi All, Please find the updated Webrev with fixes for the comments @ HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/6949753/webrev_04/"http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_04/ ? Thanks and regards, Shashi ? From: Philip Race Sent: Thursday, June 8, 2017 3:32 AM To: Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com" Cc: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? .. and please make sure all lines are <= 80 chars as per the coding standards. -phil. On 6/6/17, 11:59 PM, Prasanta Sadhukhan wrote: do_test() does not need to be under EDT as it invokes printer pagedialog and not swing components. Actually, createUI() needs to be under EDT which has not been done. Also, 79???????? SwingUtilities.invokeAndWait(() -> { ? 80???????????? test.disposeUI(); ? 81???????? }); ? 82???? } should be called before you throw RuntimeException when test times out . There is no need of calling this after 75???????? if (test.testResult == false) { ? 76???????????? throw new RuntimeException("Test Failed."); ? 77???????? } as it has already been called in pass/fail actionlistener. ? Also, put a sleep after T1.start() and do_test() otherwise since they are in separate thread, in mycase, pagedialog is displayed before test instructions dialog. ? Regards Prasanta On 6/7/2017 11:50 AM, Shashidhara Veerabhadraiah wrote: Hi All, ? I have altered the manual test template per the comments. ? 1.? Have moved the test instructions window under newly created thread. 2.? Have moved the print dialog(main test module) under EDT. 3.? Timer management shall be done on the main thread. ? I have placed the updated Webrev @ HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/6949753/webrev_03/"http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_03/ Please let me know if any comments on it. ? Thanks and regards, Shashi ? From: Prasanta Sadhukhan Sent: Tuesday, June 6, 2017 11:52 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race HYPERLINK "mailto:philip.race at oracle.com" Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? As I told, pageDialog is modal so latch.await() will not be called if user does not close the page dialog or do any interaction. The actual test 59???????? PageFormat pageFormat = new PageFormat(); ? 60 ??61???????? createNewPrintPageSetup(pageFormat); ?62 ??63???????? setValuesForPrintPageSetup(pageFormat, 2); ? 64 ??65???????? createNewPrintPageSetup(pageFormat); ? 66 ??67???????? setValuesForPrintPageSetup(pageFormat, 3); ? 68 ??69???????? createNewPrintPageSetup(pageFormat); should be done in other thread. Regards Prasanta On 6/6/2017 11:24 AM, Shashidhara Veerabhadraiah wrote: The manual test template that I received from the team seems buggy and an older version it seems. I have modified the same per your inputs and now placed the updated Webrev at HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/6949753/webrev_02/"http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_02/. ? Thanks and regards, Shashi ? From: Prasanta Sadhukhan Sent: Monday, June 5, 2017 12:35 PM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race HYPERLINK "mailto:philip.race at oracle.com" Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? I guess there is one more problem in usage of CountDown latch. Have you seen this test fail with timeout even if you wait for 5 minutes as per your timeout period? latch.await() needs to be wait on main thread while the test needs to be executed in another thread otherwise, pageDialog being modal the control will not come to latch.await() Iguess you need to do this. TestUI test = new TestUI(latch); ??????? Thread T1 = new Thread(test); ??????? T1.start(); class TestUI implements Runnable { ... @Override ??? public void run() { ??????? try { ??????????? createUI(); Regards Prasanta On 6/2/2017 4:00 PM, Shashidhara Veerabhadraiah wrote: Hi, I have fixed the comments below and updated the webrev @ HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/6949753/webrev_01/"http://cr.openjdk.java.net/~pkbalakr/shashi/6949753/webrev_01/ ? Thanks and regards, Shashi ? From: Prasanta Sadhukhan Sent: Friday, June 2, 2017 12:36 PM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race HYPERLINK "mailto:philip.race at oracle.com" Subject: Re: [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop ? Test fix look ok. Only thing is, you can call getPrinterJob() once and reutilise instead of calling 3 times and probably there is no need of creating a function createNewPrintPageSetup() for it (as it calls 1 method) but it is upto you. Few comments: Copyright should have "," after 2017. I guess createUI() does not have any call that throws exception so no need to have try-catch block for createUI(). Also, there is no need to catch PrinterException and rethrow RuntimeException, so you can do away with that try-catch. Also, you can call disposeUI() in passButton and failButton actionlistener instead of in main().? Also, there is no need to do setVisible(false) in disposeUI(), dispose() will take care of that. You can throw RuntimeException when test timed out (instead of just println and later getting test fail exception) which is different from Test Failed RuntimeException. Regards Prasanta On 6/1/2017 5:10 PM, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for a test bug which contained an infinite loop to test the printer setup dialog's margin attributes retention without the manual step procedure. ? The issue with PDialogTest.java which tests the printer setup dialog's margin attributes retention by having as infinite loop to keep popping up the dialog without a proper exit. The test does not cover the instruction steps necessary to properly test dialog's margin attributes retention. ? The updated test file includes the standard manual test template along with test cases to cover the printer dialog's margin attributes retention feature. ? Bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-6949753" ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/6949753/webrev_00/" ? Note : PrintDialog on Mac does not show page margins and hence this test does not run on Mac. ? Thanks and regards, Shashi ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 31100 bytes Desc: not available URL: From shashidhara.veerabhadraiah at oracle.com Wed Jul 19 09:51:26 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Wed, 19 Jul 2017 02:51:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> <8354d17b-67f5-40df-b647-2111e1c466e5@default> <5968B657.6040805@oracle.com> <5968D203.1090203@oracle.com> Message-ID: Hi All, Anything more needs to be done with respect this? Can I push this? ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, July 17, 2017 11:28 AM To: Philip Race ; 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi All, Here is the new webrev with the fixes for the comments: ? ? Thanks and regards, Shashi ? From: Philip Race Sent: Friday, July 14, 2017 7:46 PM To: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? I think it best to send an updated webrev since I'd like to make sure the changes are made everywhere as requested. -phil. On 7/14/17, 5:17 AM, Kevin Rushforth wrote: As long as you are fixing the 'if(' ... can you add curly braces around the body of the target statement? The following pattern: ??? if (condition) ??????? statement; is not in keeping with our coding style and can be a source of bugs later if a statement should be added. Thanks. -- Kevin Ajit Ghaisas wrote: A nit? There should be a space between if and ( -- on lines 65 and 70. You can make this change before pushing. No need to have a new webrev just for this. ? Regards, Ajit ? From: Shashidhara Veerabhadraiah Sent: Friday, July 14, 2017 10:01 AM To: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi All, Anything more comments on this? Can I close this now? ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 3:14 PM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? Changes are fine. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 2:50 PM To: Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Thanks for that suggestion Jay. I have modified with some changes so that we don?t run into a null pointer exception!! And here is the new Webrev for the same: ? HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/8183341/webrev_02/"http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ ? Thanks and regards, Shashi ? From: Jayathirth D V Sent: Wednesday, July 12, 2017 11:53 AM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hello Shashi, ? The lines before the try{} block in test() function in the test case can throw IOException, like createImageInputStream() call present at line no 50. In that case we will not reach finally block and temporary file will not be deleted. Including complete code of test() function in try{} and deleting resources in finally block will be a better option. ? Thanks, Jay ? From: Shashidhara Veerabhadraiah Sent: Wednesday, July 12, 2017 11:03 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Sergey, Thank you for the excellent suggestion. I have updated the Webrev accordingly. ? Prahalad, With the use of Sergey?s suggestion of adding an finally block solves the problem of not deleting files on a fail case. ??????. Was the bug reproducible at your end ? Yes, it was reproducible. We can see the temp files hanging at %temp% folder. ????? . If yes, was it reproducible when the test succeeded /or when the test failed ? Yes, it was reproducible on success for sure. The fail case was not tested as that would require me to do an undo of an earlier changeset change. But I think the output would remain the same as the pass case. ????? . Is there a difference in the VM's termination based on the outcome of the test case. Not sure since the fail case was not tested. But per the code, it is sure that it will have differences. The finally block should fix this problem. ????? . How many such test cases exist that need similar clean up ? ??????????? . grep on 'deleteOnExit' within jdk/test/javax/imageio/ gives me atleast 10 instances. ??????????? . grep on 'File.createTempFile' within same directory gives me 29 instances. Am not sure what to do with respect to them. Should I raise new bugs if there is problem with them(if not on the bug db) and fix it? ? Updated Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/shashi/8183341/webrev_01/"http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ ? Thanks and regards, Shashi ? From: Sergey Bylokhov Sent: Wednesday, July 12, 2017 12:13 AM To: Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java ? Hi Shashi. I suggest to add a finally to the try block in the test() method and delete the file, close the stream and close the reader there. ----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for a test bug which was not cleaning up the temporary test files that it used to create. The issue with this test was that the test used to create temporary files but not deleting them. The updated test file does the deletion of the temporary files that the test is creating. Bug: Webrev: Note: The user had requested to create the temporary files in user.dir. But I think it is good to create the temporary files in the system temp directory and use it for testing and later delete the same. Besides if required the user has the choice to change the temp directory to the directory they wish for. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jul 19 17:38:31 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 19 Jul 2017 10:38:31 -0700 Subject: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java In-Reply-To: References: <4c60a5e4-e5c2-4b37-9f35-40fe9149b331@default> <87e062e6-1e79-4237-87e9-0425aa467da0@default> <8354d17b-67f5-40df-b647-2111e1c466e5@default> <5968B657.6040805@oracle.com> <5968D203.1090203@oracle.com> Message-ID: +1 -phil. On 07/19/2017 02:51 AM, Shashidhara Veerabhadraiah wrote: > [10]JDK-8183341:Better cleanup for javax/imageio/AllowSearch.java > > Hi All, Anything more needs to be done with respect this? Can I push this? > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, July 17, 2017 11:28 AM > *To:* Philip Race ; 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > Hi All, Here is the new webrev with the fixes for the comments: > > > > > Thanks and regards, > > Shashi > > *From:*Philip Race > *Sent:* Friday, July 14, 2017 7:46 PM > *To:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup for > javax/imageio/AllowSearch.java > > I think it best to send an updated webrev since I'd like to make sure the > changes are made everywhere as requested. > > -phil. > > On 7/14/17, 5:17 AM, Kevin Rushforth wrote: > > As long as you are fixing the 'if(' ... can you add curly braces > around the body of the target statement? > > The following pattern: > > if (condition) > statement; > > is not in keeping with our coding style and can be a source of > bugs later if a statement should be added. > > Thanks. > > -- Kevin > > > Ajit Ghaisas wrote: > > A nit? > > There should be a space between if and ( -- on lines 65 and 70. > > You can make this change before pushing. No need to have a new > webrev just for this. > > Regards, > > Ajit > > *From:*Shashidhara Veerabhadraiah > *Sent:* Friday, July 14, 2017 10:01 AM > *To:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup > for javax/imageio/AllowSearch.java > > Hi All, Anything more comments on this? Can I close this now? > > Thanks and regards, > > Shashi > > *From:*Jayathirth D V > *Sent:* Wednesday, July 12, 2017 3:14 PM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup > for javax/imageio/AllowSearch.java > > Hello Shashi, > > Changes are fine. > > Thanks, > > Jay > > *From:*Shashidhara Veerabhadraiah > *Sent:* Wednesday, July 12, 2017 2:50 PM > *To:* Jayathirth D V; Sergey Bylokhov; Prahalad Kumar Narayanan > *Cc:* 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup > for javax/imageio/AllowSearch.java > > Thanks for that suggestion Jay. I have modified with some > changes so that we don?t run into a null pointer exception!! > And here is the new Webrev for the same: > > http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_02/ > > > Thanks and regards, > > Shashi > > *From:*Jayathirth D V > *Sent:* Wednesday, July 12, 2017 11:53 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup > for javax/imageio/AllowSearch.java > > Hello Shashi, > > The lines before the try{} block in test() function in the > test case can throw IOException, like createImageInputStream() > call present at line no 50. > > In that case we will not reach finally block and temporary > file will not be deleted. > > Including complete code of test() function in try{} and > deleting resources in finally block will be a better option. > > > > Thanks, > > Jay > > *From:*Shashidhara Veerabhadraiah > *Sent:* Wednesday, July 12, 2017 11:03 AM > *To:* Sergey Bylokhov; Prahalad Kumar Narayanan > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup > for javax/imageio/AllowSearch.java > > Sergey, Thank you for the excellent suggestion. I have updated > the Webrev accordingly. > > Prahalad, With the use of Sergey?s suggestion of adding an > finally block solves the problem of not deleting files on a > fail case. > > . Was the bug reproducible at your end ? > > Yes, it was reproducible. We can see the temp files hanging at > %temp% folder. > > . If yes, was it reproducible when the test succeeded > /or when the test failed ? > > Yes, it was reproducible on success for sure. The fail case > was not tested as that would require me to do an undo of an > earlier changeset change. But I think the output would remain > the same as the pass case. > > . Is there a difference in the VM's termination based on > the outcome of the test case. > > Not sure since the fail case was not tested. But per the code, > it is sure that it will have differences. The finally block > should fix this problem. > > . How many such test cases exist that need similar clean > up ? > > . grep on 'deleteOnExit' within > jdk/test/javax/imageio/ gives me atleast 10 instances. > > . grep on 'File.createTempFile' within same > directory gives me 29 instances. > > Am not sure what to do with respect to them. Should I raise > new bugs if there is problem with them(if not on the bug db) > and fix it? > > Updated Webrev: > > http://cr.openjdk.java.net/~pkbalakr/shashi/8183341/webrev_01/ > > > Thanks and regards, > > Shashi > > *From:*Sergey Bylokhov > *Sent:* Wednesday, July 12, 2017 12:13 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Prasanta Sadhukhan >; > 2d-dev at openjdk.java.net ; > Philip Race > > *Subject:* Re: [OpenJDK 2D-Dev] [10]JDK-8183341:Better cleanup > for javax/imageio/AllowSearch.java > > Hi Shashi. > I suggest to add a finally to the try block in the test() > method and delete the file, close the stream and close the > reader there. > > ----- shashidhara.veerabhadraiah at oracle.com > wrote: > > > > Hi All, > > Please review a fix for a test bug which was not cleaning up > the temporary test files that it used to create. > > The issue with this test was that the test used to create > temporary files but not deleting them. > > The updated test file does the deletion of the temporary files > that the test is creating. > > Bug: > > > > Webrev: > > > > > Note: The user had requested to create the temporary files in > user.dir. But I think it is good to create the temporary files > in the system temp directory and use it for testing and later > delete the same. Besides if required the user has the choice > to change the temp directory to the directory they wish for. > > Thanks and regards, > > Shashi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Thu Jul 20 14:27:05 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 20 Jul 2017 07:27:05 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime In-Reply-To: <7db9e300-ee3c-4ff3-8794-13f4e36eab16@default> References: <89230e11-6102-4468-9356-ca6cc7ba536a@default> <753ef90c-4539-430b-9059-46cfeb89c5a0@default> <2F938EB2-AE69-4431-A52C-5BD5E3F1AB1F@oracle.com> <7db9e300-ee3c-4ff3-8794-13f4e36eab16@default> Message-ID: <6775871e-e09c-4000-b82b-133d79751076@default> Hello Everyone Good day to you. This is a follow-up to the bug fix for [JDK-8164971] PNG Metadata does not handle image creation time. First, Thanks to Brian and Jay for their time in review & feedback. . I 've addressed the review suggestions and the updated code is available for review. . Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.01/ Description on changes are as follows: Brian's Suggestions: > Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. > What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"? . Update: . The logic supports decoding combined Date Time based on RFC1123 and ISO Formats. . This has been realized with JDK's inbuilt DateTimeFormatter objects. > If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. > One could for example use the value of the first one, the value of the last one, the oldest one, etc. . Update: . The logic uses the time retrieved from the last decoded text chunk (tEXt, iTXt, or zTXt) with Creation Time to initialize Standard/Document/ImageCreationTime. . Similarly, when metadata is updated with Standard/Document/ImageCreationTime, the same is encoded within the last decoded text chunk. > What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] . Update: . I checked the PNG files of the test suite. Unfortunately none contain ancillary text chunk with 'Creation Time' . Hence, I manually created a PNG file with tEXt chunk containing Creation Time to test the changes. Jay's Suggestions: > In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123 . Update: . This has been corrected. . Please Note: The method name in the internal PNGMetadata class has been changed to decodedImageCreationTimeFromTextChunk > I see that, if there are multiple text chunks following RFC1123 text we update our standard metadata node with last parsed chunk. This information should be covered properly in comments as it is specific to our implementation and it is not part of PNG specification. . Update: . This has been addressed. The logic is substantiated with comments. > In the present iteration of code in PNGMetadata.encodeCreationTimeToText() we are updating the first available text chunk with the new information provided in stanrdardmetadata node. . Update: . Yes. This is a very good find. Thank you. . The logic has been corrected to update the encoded time in the last decoded text chunk. > It's better to maintain /* */ format for multiple line comments then using multiple //. . Update: . I had initially used // to keep my changes in synch with the existing code that uses // for multiline comments. . I 've reverted to /* */ to comply with guidelines. Other Information: . The code changes have been run through Jtreg and JCK test suites. No new regressions were seen. . Besides, the test case available with the webrev is comprehensive and tests the following scenarios- . Proper decoding of text chunks with 'Creation Time' from the test image. . Proper decoding of time in RFC1123 and ISO format. (Test provides incorrect values as well and code doesn't crash) . Proper values in Native tree's text chunks after updating metadata with Standard/Document/ImageCreationTime. . Proper values in Standard/Document/ImageCreationTime after updating metadata with text chunks using Native tree. Kindly review the changes when your time permits and provide your feedback. Thank you Have a good day Prahalad N. --------------------------------------- From: Brian Burkhalter Sent: Thursday, June 08, 2017 4:20 AM To: Jayathirth D V Cc: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime Hi Jay, On Jun 7, 2017, at 3:42 AM, Jayathirth D V wrote: As per PNG Specification for text chunks?http://libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text?. There can be multiple chunks with same keyword. Yep: "Any number of text chunks can appear, and more than one with the same keyword is permissible." 1) In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123. So if there are multiple text chunks and if the latest chunk doesn't follow RFC1123 while decoding it will result in "creation_time_present" to be false. In case where we are not able to decode the provided text, we should not update "creation_time_present" to false. I have not looked at the code but what I am wondering about is how it handles this part of the specification from the same section: "For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword." ? Specifically the date format is *recommended* as opposed to be *required* to conform to RFC 1123. What happens if for example there is only one tEXt chunk which has a Creation Time in ISO 8601 format [1], e.g., "2017-06-07 15:50"? If multiple Creation Time keywords are present the algorithm to decide which one to use as the ImageCreationTime in standard image metadata is somewhat arbitrary. One could for example use the value of the first one, the value of the last one, the oldest one, etc. What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] or those produced by typical user applications such as Apple's "Preview" or the Windows program "IrfanView" [3] or other common image viewers? Thanks, Brian [1]?https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations [2]?http://www.schaik.com/pngsuite/pngsuite.html [3]?https://en.wikipedia.org/wiki/IrfanView From Sergey.Bylokhov at oracle.com Tue Jul 25 00:09:15 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 24 Jul 2017 17:09:15 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created Message-ID: Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8185093 Webrev can be found at: http://cr.openjdk.java.net/~serb/8185093/webrev.00 jmh test: http://cr.openjdk.java.net/~serb/8185093/LocalGEproblem.java While working on some other bug I found a performance issue in our java2d pipeline in multi-threaded environment. We have a "hot spot" in the "GraphicsEnvironment.getLocalGraphicsEnvironment()". This method is executed every time the graphics object is created, for example BufferedImage.java: public Graphics2D createGraphics() { GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment(); return env.createGraphics(this); } So even if the application will draw to a different Images it will be blocked for some time in this method. I created a jmh test case which shows that implementing this method via holder will speedup the next code: Graphics2D graphics = bi.createGraphics(); graphics.drawLine(0, 0, 100, 100); 4 Threads: - Before the fix: 8922 ops/ms - After the fix : 9442 ops/ms 8 Threads: - Before the fix: 4511 ops/ms - After the fix : 11899 ops/ms The main issue which I would like to clarify is it possible to remove synchronize keyword from the getLocalGraphicsEnvironment(), possibly with updating a specification? We have similar issues in other parts of code which I would like to update later after this one. -- Best regards, Sergey. From bourges.laurent at gmail.com Tue Jul 25 07:10:34 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 25 Jul 2017 09:10:34 +0200 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: References: Message-ID: Sergey, That's very interesting: I optimized the renderer to be perfectly scalable (thread local), but I agree there are still several places with static fields (single thread optimization) or synchronized methods... The main issue which I would like to clarify is it possible to remove synchronize keyword from the getLocalGraphicsEnvironment(), possibly with updating a specification? We have similar issues in other parts of code which I would like to update later after this one. Could you give more details on your findings ? I recently figured out that TexturePaint suffers such a problem... Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Jul 25 09:48:43 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 25 Jul 2017 02:48:43 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: References: Message-ID: This same thing is done in other places in a simpler way without creating an inner class simply by having createGE() do the assignment and test for null, as in: before: public static synchronized GraphicsEnvironment getLocalGraphicsEnvironment() { if (localEnv == null) { localEnv = createGE(); } return localEnv; } private static GraphicsEnvironment createGE() { ... return ge; } => after: public static GraphicsEnvironment getLocalGraphicsEnvironment() { if (localEnv == null) { createGE(); } return localEnv; } private static synchronized GraphicsEnvironment createGE() { if (localEnv != null) return; ... localEnv = ge; } OR => alternate after: public static synchronized GraphicsEnvironment getLocalGraphicsEnvironment() { if (localEnv == null) { synchronized (GraphicsEnvironment.class) { if (localEnv == null) { localEnv = createGE(); } } } return localEnv; } // And no changes to createGE() Note that there is a test for null both in getLGE() and also again in createGE() because the second one is inside a synchronized block and required to prevent multiple instances. The first one in getLGE() avoids having to synchronize in the first place for the common case. ...jim On 7/24/17 5:09 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185093 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8185093/webrev.00 > jmh test: http://cr.openjdk.java.net/~serb/8185093/LocalGEproblem.java > > While working on some other bug I found a performance issue in our java2d pipeline in multi-threaded environment. We > have a "hot spot" in the "GraphicsEnvironment.getLocalGraphicsEnvironment()". This method is executed every time the > graphics object is created, for example BufferedImage.java: > > public Graphics2D createGraphics() { > GraphicsEnvironment env = > GraphicsEnvironment.getLocalGraphicsEnvironment(); > return env.createGraphics(this); > } > > So even if the application will draw to a different Images it will be blocked for some time in this method. > I created a jmh test case which shows that implementing this method via holder will speedup the next code: > Graphics2D graphics = bi.createGraphics(); > graphics.drawLine(0, 0, 100, 100); > > 4 Threads: > - Before the fix: 8922 ops/ms > - After the fix : 9442 ops/ms > 8 Threads: > - Before the fix: 4511 ops/ms > - After the fix : 11899 ops/ms > > The main issue which I would like to clarify is it possible to remove synchronize keyword from the > getLocalGraphicsEnvironment(), possibly with updating a specification? We have similar issues in other parts of code > which I would like to update later after this one. > From Sergey.Bylokhov at oracle.com Tue Jul 25 19:53:22 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Jul 2017 12:53:22 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: References: Message-ID: On 25.07.2017 2:48, Jim Graham wrote: > This same thing is done in other places in a simpler way without > creating an inner class simply by having createGE() do the assignment > and test for null, as in: I guess a solution which you mentions is a variant of "Double-checked locking". > => after: > > public static GraphicsEnvironment getLocalGraphicsEnvironment() { > if (c== null) { > createGE(); > } > > return localEnv; > } > > private static synchronized GraphicsEnvironment createGE() { > if (localEnv != null) return; > ... > localEnv = ge; > } > In this variant the field should be volatile, and this will introduce some synchronization. Otherwise it will be possible to read non-null value in localEnv while the constructor of GraphicsEnvironment was not completed on some other thread(but the field was assigned already). > OR => alternate after: > > public static synchronized GraphicsEnvironment > getLocalGraphicsEnvironment() { > if (localEnv == null) { > synchronized (GraphicsEnvironment.class) { > if (localEnv == null) { > localEnv = createGE(); > } > } > } > > return localEnv; > } > > // And no changes to createGE() > In this variant the field also should be volatile. I guess it was a typo that the getLocalGraphicsEnvironment still "synchronized". > Note that there is a test for null both in getLGE() and also again in > createGE() because the second one is inside a synchronized block and > required to prevent multiple instances. The first one in getLGE() > avoids having to synchronize in the first place for the common case. Note that in case of holder - after the first call there was not any synchronization(like in case of "synchronized" and "volatile"). Here some additional information which I used: https://shipilev.net/blog/2014/safe-public-construction/ > > ...jim > > On 7/24/17 5:09 PM, Sergey Bylokhov wrote: >> Hello, >> Please review the fix for jdk10. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185093 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8185093/webrev.00 >> jmh test: http://cr.openjdk.java.net/~serb/8185093/LocalGEproblem.java >> >> While working on some other bug I found a performance issue in our >> java2d pipeline in multi-threaded environment. We have a "hot spot" in >> the "GraphicsEnvironment.getLocalGraphicsEnvironment()". This method >> is executed every time the graphics object is created, for example >> BufferedImage.java: >> >> public Graphics2D createGraphics() { >> GraphicsEnvironment env = >> GraphicsEnvironment.getLocalGraphicsEnvironment(); >> return env.createGraphics(this); >> } >> >> So even if the application will draw to a different Images it will be >> blocked for some time in this method. >> I created a jmh test case which shows that implementing this method >> via holder will speedup the next code: >> Graphics2D graphics = bi.createGraphics(); >> graphics.drawLine(0, 0, 100, 100); >> >> 4 Threads: >> - Before the fix: 8922 ops/ms >> - After the fix : 9442 ops/ms >> 8 Threads: >> - Before the fix: 4511 ops/ms >> - After the fix : 11899 ops/ms >> >> The main issue which I would like to clarify is it possible to remove >> synchronize keyword from the getLocalGraphicsEnvironment(), possibly >> with updating a specification? We have similar issues in other parts >> of code which I would like to update later after this one. >> -- Best regards, Sergey. From james.graham at oracle.com Tue Jul 25 22:03:25 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 25 Jul 2017 15:03:25 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: References: Message-ID: <8af9d52f-5754-a135-2f03-8dbf1c841ba4@oracle.com> Hi Sergey, On 7/25/17 12:53 PM, Sergey Bylokhov wrote: > In this variant the field should be volatile, and this will introduce some synchronization. Otherwise it will be > possible to read non-null value in localEnv while the constructor of GraphicsEnvironment was not completed on some other > thread(but the field was assigned already). Even though the assignment is the last statement in the method? In looking through the article that you sent out (only briefly) it looks like the consideration is that the initialization method run in one thread could reorder the instructions at run time so that the field is assigned before the initialization steps are done, even if the code is written with a different specific ordering. I'm guessing that the Java Memory Model ensures that membars are placed to protect static field initialization from similar dangers? If that is the case then I think we have a few places where we do this "manual conditional synchronization" that should probably be investigated. If I remember correctly, though, they may use the following paradigm which might not suffer from that issue: Does it help if a local variable is used, as in: GE env = this.localEnv if (env == null) { synchronized (class) { if (this.localEnv == null) { localEnv = createGE(); } env = this.localEnv; } } return env; This ensures that the second read from the field is done in the synchronized block for the case that it was originally found to be null, though this might not help if the line "localEnv = createGE()" can reorder code from inside the call to createGE() to code outside of it. However those dangling reordered stores should be resolved before it leaves the synchronized block, no? In any case, I can see that the code used in the webrev will eventually have no dead code at all in the final compiled version of the method whereas this version would minimally at least have a null check that must be executed even though it would be vestigial once the initialization was done... +1 for the inner class version - it's the most straightforward way to do this optimally... ...jim From Sergey.Bylokhov at oracle.com Tue Jul 25 22:37:30 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Jul 2017 15:37:30 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: <8af9d52f-5754-a135-2f03-8dbf1c841ba4@oracle.com> References: <8af9d52f-5754-a135-2f03-8dbf1c841ba4@oracle.com> Message-ID: On 25.07.2017 15:03, Jim Graham wrote: > On 7/25/17 12:53 PM, Sergey Bylokhov wrote: >> In this variant the field should be volatile, and this will introduce >> some synchronization. Otherwise it will be possible to read non-null >> value in localEnv while the constructor of GraphicsEnvironment was not >> completed on some other thread(but the field was assigned already > > Even though the assignment is the last statement in the method? The assignment include these operations: - Allocate memory - Initialize the object - Assign the object to the field. These operation may be reordered, so some other thread can see non-null reference in the field while initialization was not complete. > > In looking through the article that you sent out (only briefly) it looks > like the consideration is that the initialization method run in one > thread could reorder the instructions at run time so that the field is > assigned before the initialization steps are done, even if the code is > written with a different specific ordering. > > I'm guessing that the Java Memory Model ensures that membars are placed > to protect static field initialization from similar dangers? The key feature here is initialization of the class. The next line will be blocked while the LocalGE class will not be initialized: return LocalGE.INSTANCE; And initialization will start only when this code will run for the first time. > > If that is the case then I think we have a few places where we do this > "manual conditional synchronization" that should probably be > investigated. If I remember correctly, though, they may use the > following paradigm which might not suffer from that issue: > > Does it help if a local variable is used, as in: > > GE env = this.localEnv > if (env == null) { > synchronized (class) { > if (this.localEnv == null) { > localEnv = createGE(); > } > env = this.localEnv; > } > } > return env; > > This ensures that the second read from the field is done in the > synchronized block for the case that it was originally found to be null, > though this might not help if the line "localEnv = createGE()" can > reorder code from inside the call to createGE() to code outside of it. > However those dangling reordered stores should be resolved before it > leaves the synchronized block, no? I think that it is possible that one thread will do: - create an object - assign the object to the localEnv. - Initialize the object. And the second thread will do: - Read non-null value from the this.localEnv to the env - Check env to null - Return non-initialized object. > In any case, I can see that the code used in the webrev will eventually > have no dead code at all in the final compiled version of the method > whereas this version would minimally at least have a null check that > must be executed even though it would be vestigial once the > initialization was done... > > +1 for the inner class version - it's the most straightforward way to do > this optimally... -- Best regards, Sergey. From james.graham at oracle.com Wed Jul 26 19:34:35 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 26 Jul 2017 12:34:35 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: References: <8af9d52f-5754-a135-2f03-8dbf1c841ba4@oracle.com> Message-ID: <1592d32d-017a-44c5-a8c7-ca8df304c52c@oracle.com> On 7/25/17 3:37 PM, Sergey Bylokhov wrote: >> If that is the case then I think we have a few places where we do this "manual conditional synchronization" that >> should probably be investigated. If I remember correctly, though, they may use the following paradigm which might not >> suffer from that issue: >> >> Does it help if a local variable is used, as in: >> >> GE env = this.localEnv >> if (env == null) { >> synchronized (class) { >> if (this.localEnv == null) { >> localEnv = createGE(); >> } >> env = this.localEnv; >> } >> } >> return env; >> >> This ensures that the second read from the field is done in the synchronized block for the case that it was originally >> found to be null, though this might not help if the line "localEnv = createGE()" can reorder code from inside the call >> to createGE() to code outside of it. However those dangling reordered stores should be resolved before it leaves the >> synchronized block, no? > > I think that it is possible that one thread will do: > - create an object > - assign the object to the localEnv. > - Initialize the object. > And the second thread will do: > - Read non-null value from the this.localEnv to the env > - Check env to null > - Return non-initialized object. I can see that. I suppose one thing that keeps this from causing problems in AWT is that we tend to be single-threaded for most applications. I suppose that one could get even more sophisticated to prevent that case, but in the end, as I said, I can see the simplicity of using the inner class now in getting all of this right. I'll do a search and see if there are any cases of the above paradigm left... ...jim From james.graham at oracle.com Thu Jul 27 00:08:19 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 26 Jul 2017 17:08:19 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: <1592d32d-017a-44c5-a8c7-ca8df304c52c@oracle.com> References: <8af9d52f-5754-a135-2f03-8dbf1c841ba4@oracle.com> <1592d32d-017a-44c5-a8c7-ca8df304c52c@oracle.com> Message-ID: <566eb2a8-c8de-917b-0672-66c8ac95ce5c@oracle.com> On 7/26/17 12:34 PM, Jim Graham wrote: > I'll do a search and see if there are any cases of the above paradigm left... I did a basic grep over the Java sources in java.desktop looking primarily for synchronizations on a class, ignoring synchronized methods (both instance and static) and synchronizations on an object other than a class (such as "this" or "getTreeLock()"). I didn't find any cases of initializing a singleton without all of the tests inside the synch block (such as Toolkit which does do the lazy initialization, but it has all of the lazy tests inside the synch block so it can't have unordered initialization, but it might benefit from an inner class treatment for performance). Either I was imagining it, or we've gradually cleaned up a lot of those in the past. I did find the following related issues: TrayIcon.setPopupMenu() - synchronizes on TrayIcon.class, but then relies on tests from outside the synch block for correctness I believe - the "already set" test should probably be duplicated inside the synchronization I found a number of cases of "synchronized (Foo.class)" inside Foo.java, and some of them were the first statement in the method - which begs the question of why the method wasn't just made synchronized in the first place. Window.getWindows() and Window.removeWindowFromList() for examples... ...jim From philip.race at oracle.com Thu Jul 27 21:38:25 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 27 Jul 2017 14:38:25 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: <8af9d52f-5754-a135-2f03-8dbf1c841ba4@oracle.com> References: <8af9d52f-5754-a135-2f03-8dbf1c841ba4@oracle.com> Message-ID: <5b90b28a-d7d1-238f-80c8-f487f09a128a@oracle.com> On 07/24/2017 05:09 PM, Sergey Bylokhov wrote: > > > The main issue which I would like to clarify is it possible to remove > synchronize keyword from the getLocalGraphicsEnvironment(), possibly > with updating a specification? We have similar issues in other parts > of code which I would like to update later after this one. Yes, I do think we can remove synchronized but we should do a CSR (CCC) On 07/25/2017 03:03 PM, Jim Graham wrote: > > +1 for the inner class version - it's the most straightforward way to > do this optimally... Same from me. -phil. From sergey.bylokhov at oracle.com Sat Jul 29 00:07:47 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 28 Jul 2017 17:07:47 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created Message-ID: DRAFT version of CSR: https://bugs.openjdk.java.net/browse/JDK-8185542 ----- philip.race at oracle.com wrote: > On 07/24/2017 05:09 PM, Sergey Bylokhov wrote: > > > > > > The main issue which I would like to clarify is it possible to > remove > > synchronize keyword from the getLocalGraphicsEnvironment(), possibly > > > with updating a specification? We have similar issues in other parts > > > of code which I would like to update later after this one. > > > Yes, I do think we can remove synchronized but we should do a CSR > (CCC) > > On 07/25/2017 03:03 PM, Jim Graham wrote: > > > > +1 for the inner class version - it's the most straightforward way > to > > do this optimally... > > Same from me. > > -phil. From shashidhara.veerabhadraiah at oracle.com Mon Jul 31 06:59:33 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Sun, 30 Jul 2017 23:59:33 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is not green Message-ID: <37f1e6ba-6d3d-4f11-a4b8-15be341a7d35@default> Hi, Kindly review a fix for JDK-8169044 where the non hi dpi icon was picked among the icon set of hi dpi and a non hi dpi icons for a hi dpi display screen. Issue: The non hi dpi icon is red in color (and hi dpi icon is green in color) and was getting picked up among the set for a hi dpi display screen as shown below in the picture: Solution and fix: The icon's buffered images are not subjected to the scaling because of the hi dpi screen. Hence, the default non hi dpi icon was getting picked up for rendering the tray icon. Now the source code modified to apply necessary transformations to the bufferedimages to get the default icon based on the default display screen. Below is the output after the fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8169044 Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8169044/webrev.00/ Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 26360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 3285 bytes Desc: not available URL: From james.graham at oracle.com Mon Jul 31 20:32:24 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 31 Jul 2017 13:32:24 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: References: Message-ID: <13234d77-3332-c5fe-ead8-9163a4625a71@oracle.com> I adjusted one of the statements to be a little more straightforward and set the compatibility risk to minimal. If Phil thinks the risk can be set to "None", that was my alternate, but I stuck with "minimal" to be safe... ...jim On 7/28/17 5:07 PM, Sergey Bylokhov wrote: > DRAFT version of CSR: > https://bugs.openjdk.java.net/browse/JDK-8185542 > > ----- philip.race at oracle.com wrote: > >> On 07/24/2017 05:09 PM, Sergey Bylokhov wrote: >>> >>> >>> The main issue which I would like to clarify is it possible to >> remove >>> synchronize keyword from the getLocalGraphicsEnvironment(), possibly >> >>> with updating a specification? We have similar issues in other parts >> >>> of code which I would like to update later after this one. >> >> >> Yes, I do think we can remove synchronized but we should do a CSR >> (CCC) >> >> On 07/25/2017 03:03 PM, Jim Graham wrote: >>> >>> +1 for the inner class version - it's the most straightforward way >> to >>> do this optimally... >> >> Same from me. >> >> -phil. From james.graham at oracle.com Mon Jul 31 20:43:52 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 31 Jul 2017 13:43:52 -0700 Subject: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is not green In-Reply-To: <37f1e6ba-6d3d-4f11-a4b8-15be341a7d35@default> References: <37f1e6ba-6d3d-4f11-a4b8-15be341a7d35@default> Message-ID: <77d63925-9ab8-1c78-f586-20d7e171c254@oracle.com> Will the tray icon canvas always be on the default screen? I believe the latest MacOS and Win10 both allow menu bars and task bars on all monitors. Linux may not be far behind... ...jim On 7/30/17 11:59 PM, Shashidhara Veerabhadraiah wrote: > Hi, Kindly review a fix for JDK-8169044 where the non hi dpi icon was picked among the icon set of hi dpi and a non hi > dpi icons for a hi dpi display screen. > > Issue: The non hi dpi icon is red in color (and hi dpi icon is green in color) and was getting picked up among the set > for a hi dpi display screen as shown below in the picture: > > Solution and fix: The icon?s buffered images are not subjected to the scaling because of the hi dpi screen. Hence, the > default non hi dpi icon was getting picked up for rendering the tray icon. Now the source code modified to apply > necessary transformations to the bufferedimages to get the default icon based on the default display screen. Below is > the output after the fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169044 > > Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8169044/webrev.00/ > > Thanks and regards, > > Shashi > From james.graham at oracle.com Mon Jul 31 20:45:16 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 31 Jul 2017 13:45:16 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: <13234d77-3332-c5fe-ead8-9163a4625a71@oracle.com> References: <13234d77-3332-c5fe-ead8-9163a4625a71@oracle.com> Message-ID: <5db58559-ab6e-e484-9e9e-4ee10bec0151@oracle.com> To be clear, I couldn't think of any way in which removing a synchronized keyword would create a compatibility risk, though I suppose it potentially could cause a program to proceed faster and thus tickle a race condition - that seems rather remote and the race condition would be a "pre-existing condition"... ...jim On 7/31/17 1:32 PM, Jim Graham wrote: > I adjusted one of the statements to be a little more straightforward and set the compatibility risk to minimal. If Phil > thinks the risk can be set to "None", that was my alternate, but I stuck with "minimal" to be safe... > > ...jim > > On 7/28/17 5:07 PM, Sergey Bylokhov wrote: >> DRAFT version of CSR: >> https://bugs.openjdk.java.net/browse/JDK-8185542 >> >> ----- philip.race at oracle.com wrote: >> >>> On 07/24/2017 05:09 PM, Sergey Bylokhov wrote: >>>> >>>> >>>> The main issue which I would like to clarify is it possible to >>> remove >>>> synchronize keyword from the getLocalGraphicsEnvironment(), possibly >>> >>>> with updating a specification? We have similar issues in other parts >>> >>>> of code which I would like to update later after this one. >>> >>> >>> Yes, I do think we can remove synchronized but we should do a CSR >>> (CCC) >>> >>> On 07/25/2017 03:03 PM, Jim Graham wrote: >>>> >>>> +1 for the inner class version - it's the most straightforward way >>> to >>>> do this optimally... >>> >>> Same from me. >>> >>> -phil. From philip.race at oracle.com Mon Jul 31 21:13:05 2017 From: philip.race at oracle.com (Philip Race) Date: Mon, 31 Jul 2017 14:13:05 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created In-Reply-To: <13234d77-3332-c5fe-ead8-9163a4625a71@oracle.com> References: <13234d77-3332-c5fe-ead8-9163a4625a71@oracle.com> Message-ID: <597F9D61.1090005@oracle.com> I think minimal or low .. I could never say "none". I've added my "review" as well. -phil On 7/31/17, 1:32 PM, Jim Graham wrote: > I adjusted one of the statements to be a little more straightforward > and set the compatibility risk to minimal. If Phil thinks the risk > can be set to "None", that was my alternate, but I stuck with > "minimal" to be safe... > > ...jim > > On 7/28/17 5:07 PM, Sergey Bylokhov wrote: >> DRAFT version of CSR: >> https://bugs.openjdk.java.net/browse/JDK-8185542 >> >> ----- philip.race at oracle.com wrote: >> >>> On 07/24/2017 05:09 PM, Sergey Bylokhov wrote: >>>> >>>> >>>> The main issue which I would like to clarify is it possible to >>> remove >>>> synchronize keyword from the getLocalGraphicsEnvironment(), possibly >>> >>>> with updating a specification? We have similar issues in other parts >>> >>>> of code which I would like to update later after this one. >>> >>> >>> Yes, I do think we can remove synchronized but we should do a CSR >>> (CCC) >>> >>> On 07/25/2017 03:03 PM, Jim Graham wrote: >>>> >>>> +1 for the inner class version - it's the most straightforward way >>> to >>>> do this optimally... >>> >>> Same from me. >>> >>> -phil.