From shashidhara.veerabhadraiah at oracle.com Thu Jun 1 11:40:37 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 1 Jun 2017 04:40:37 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9]JDK-6949753:[TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop Message-ID: <3633d215-ec1a-4c16-a74b-a80627e45cb5@default> 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 From sreilly at infinitekind.com Thu Jun 1 15:09:07 2017 From: sreilly at infinitekind.com (Sean Reilly) Date: Thu, 1 Jun 2017 16:09:07 +0100 Subject: [OpenJDK 2D-Dev] printing from the mac sandbox References: <2457AAE3-CB15-472F-85C0-BC1C68CD255A@seanreilly.com> Message-ID: There is a printing problem using recent JDKs when running within the macOS sandbox as of 10.12.4. Looking at the jdk8 sources, CUPSfuncs.c seems to ignore the cupsServer by the system CUPS libraries if it returns a reference to a unix domain socket address: // Is this a local domain socket? if (strncmp(server, "/", 1) == 0) { cServer = JNU_NewStringPlatform(env, "localhost"); } else { cServer = JNU_NewStringPlatform(env, server); } This causes the CUPSPrinter.java and CUPSfunc code to connect to localhost via TCP port 631 instead of the advertised unix domain socket. MacOS Sierra 10.12.4 had some security related changes to the sandbox which explicitly blocks connections from a sandboxed app to TCP localhost:631. This blockage (or at least a very long delay) applies even if the sandboxed app has network-client, network-server, and print entitlements, which means there's no way around the problem. I've talked to Apple DTS and they aren't inclined to allow the connection to localhost:631, even if the network-client and print entitlements are enabled. It seems a bit stubborn of them but to be fair java is ignoring the advertised CUPS server string and assuming that a TCP/localhost:631 interface is available. As you can imagine, not being able to print from a desktop app is pretty bad for business. My questions are: 1) Is anyone at Oracle aware of and working on this? 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` 3) Is a patch that uses the unix domain socket likely to be accepted, and if so, where should it be sent? 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 Thu Jun 1 15:55:53 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 1 Jun 2017 08:55:53 -0700 (PDT) Subject: [OpenJDK 2D-Dev] printing from the mac sandbox Message-ID: <0a1039f3-7f6e-4bbb-81fb-af287cad593d@default> Hi, Sean. The correct mailing list for discussion of such issues is: 2d-dev (cc). ----- sreilly at seanreilly.com wrote: > There seems to be a big printing problem using recent JDKs when > running within the macOS sandbox as of 10.12.4. > > Looking at the jdk8 sources, CUPSfuncs.c seems to ignore the > connection point provided by the system CUPS libraries if it returns a > reference to a unix domain socket address: > > // Is this a local domain socket? > if (strncmp(server, "/", 1) == 0) { > cServer = JNU_NewStringPlatform(env, "localhost"); > } else { > cServer = JNU_NewStringPlatform(env, server); > } > > This causes the CUPSPrinter.java and CUPSfunc code to connect to > localhost via TCP port 631 instead of the unix domain socket which > should be where it connects. > > MacOS Sierra 10.12.4 had some security related changes to the sandbox > which explicitly blocks connections from a sandboxed app to TCP > localhost:631. This blockage (or at least a very long delay) applies > even if network-client, network-server, and print entitlements are set > for the app, which means there's no way around the problem. > > I've talked to Apple DTS and they aren't inclined to allow the > connection to localhost:631, even if the network-client and print > entitlements are enabled. > > As you can imagine, not being able to print from a desktop app is > pretty bad for business. > > My questions are: > 1) Is anyone at Oracle aware of and working on this? > > 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` > > 3) Is a patch that uses the unix domain socket likely to be accepted, > and if so, where should it be sent? > > 4) Is there a better mailing list for this discussion? > > Thanks, > Sean From anton.litvinov at oracle.com Thu Jun 1 18:19:40 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 1 Jun 2017 21:19:40 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS Message-ID: Hello, Could you please review the following fix for the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8181192 Webrev: http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.00 The bug is a showstopper bug consisting in hanging during the call to "javafx.print.PrinterJob.showPrintDialog(Windows)" method in JavaFX application. The bug is a regression of the fix for the bug JDK-8167102. The solution is a direct back out of the fix JDK-8167102, so it is a reversed version of the patch for JDK-8167102. Thank you, Anton From philip.race at oracle.com Thu Jun 1 18:57:36 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 01 Jun 2017 11:57:36 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS In-Reply-To: References: Message-ID: <593063A0.7040009@oracle.com> The fix is fine but rather than deleting the test just mark it @ignore .. it can be then updated with a new version of the fix. -phil. On 6/1/17, 11:19 AM, Anton Litvinov wrote: > Hello, > > Could you please review the following fix for the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181192 > Webrev: http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.00 > > The bug is a showstopper bug consisting in hanging during the call to > "javafx.print.PrinterJob.showPrintDialog(Windows)" method in JavaFX > application. The bug is a regression of the fix for the bug JDK-8167102. > > The solution is a direct back out of the fix JDK-8167102, so it is a > reversed version of the patch for JDK-8167102. > > Thank you, > Anton From sergey.bylokhov at oracle.com Thu Jun 1 19:09:08 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 1 Jun 2017 12:09:08 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review request for 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS Message-ID: <8f7c7e99-7670-4b04-a172-871471d10892@default> > The fix is fine but rather than deleting the test just mark it @ignore > > .. it can be then updated > with a new version of the fix. +1 > > > -phil. > > On 6/1/17, 11:19 AM, Anton Litvinov wrote: > > Hello, > > > > Could you please review the following fix for the bug. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181192 > > Webrev: > http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.00 > > > > The bug is a showstopper bug consisting in hanging during the call > to > > "javafx.print.PrinterJob.showPrintDialog(Windows)" method in JavaFX > > > application. The bug is a regression of the fix for the bug > JDK-8167102. > > > > The solution is a direct back out of the fix JDK-8167102, so it is a > > > reversed version of the patch for JDK-8167102. > > > > Thank you, > > Anton From prasanta.sadhukhan at oracle.com Fri Jun 2 07:05:31 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 2 Jun 2017 12:35:31 +0530 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: <3633d215-ec1a-4c16-a74b-a80627e45cb5@default> References: <3633d215-ec1a-4c16-a74b-a80627e45cb5@default> Message-ID: <1db4e0a1-63a2-2d15-b6b6-16dba6c1c3b5@oracle.com> 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: From shashidhara.veerabhadraiah at oracle.com Fri Jun 2 10:30:49 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Fri, 2 Jun 2017 03:30:49 -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: <1db4e0a1-63a2-2d15-b6b6-16dba6c1c3b5@oracle.com> References: <3633d215-ec1a-4c16-a74b-a80627e45cb5@default> <1db4e0a1-63a2-2d15-b6b6-16dba6c1c3b5@oracle.com> Message-ID: <3267ec4c-45ab-4a39-a620-bc987e1e2064@default> 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 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/~pkbalakr/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: From anton.litvinov at oracle.com Fri Jun 2 12:40:41 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 2 Jun 2017 15:40:41 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS In-Reply-To: <8f7c7e99-7670-4b04-a172-871471d10892@default> References: <8f7c7e99-7670-4b04-a172-871471d10892@default> Message-ID: <96d6439c-9ff2-9750-8e7b-a0d94962ca74@oracle.com> Hello Phil and Sergey, The new version of the back out fix, which does not remove the regression test and adds "@ignore" jtreg tag, is following. Webrev (the 2nd version): http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.01 Thank you, Anton On 6/1/2017 10:09 PM, Sergey Bylokhov wrote: >> The fix is fine but rather than deleting the test just mark it @ignore >> >> .. it can be then updated >> with a new version of the fix. > +1 > >> >> -phil. >> >> On 6/1/17, 11:19 AM, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181192 >>> Webrev: >> http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.00 >>> The bug is a showstopper bug consisting in hanging during the call >> to >>> "javafx.print.PrinterJob.showPrintDialog(Windows)" method in JavaFX >>> application. The bug is a regression of the fix for the bug >> JDK-8167102. >>> The solution is a direct back out of the fix JDK-8167102, so it is a >>> reversed version of the patch for JDK-8167102. >>> >>> Thank you, >>> Anton From philip.race at oracle.com Fri Jun 2 12:57:21 2017 From: philip.race at oracle.com (Philip Race) Date: Fri, 02 Jun 2017 05:57:21 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS In-Reply-To: <96d6439c-9ff2-9750-8e7b-a0d94962ca74@oracle.com> References: <8f7c7e99-7670-4b04-a172-871471d10892@default> <96d6439c-9ff2-9750-8e7b-a0d94962ca74@oracle.com> Message-ID: <593160B1.2000709@oracle.com> +1 Please add the required RDP2 process label + comment to request this fix be pushed -phil. On 6/2/17, 5:40 AM, Anton Litvinov wrote: > Hello Phil and Sergey, > > The new version of the back out fix, which does not remove the > regression test and adds "@ignore" jtreg tag, is following. > > Webrev (the 2nd version): > http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.01 > > Thank you, > Anton > > On 6/1/2017 10:09 PM, Sergey Bylokhov wrote: >>> The fix is fine but rather than deleting the test just mark it @ignore >>> >>> .. it can be then updated >>> with a new version of the fix. >> +1 >> >>> >>> -phil. >>> >>> On 6/1/17, 11:19 AM, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix for the bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181192 >>>> Webrev: >>> http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.00 >>>> The bug is a showstopper bug consisting in hanging during the call >>> to >>>> "javafx.print.PrinterJob.showPrintDialog(Windows)" method in JavaFX >>>> application. The bug is a regression of the fix for the bug >>> JDK-8167102. >>>> The solution is a direct back out of the fix JDK-8167102, so it is a >>>> reversed version of the patch for JDK-8167102. >>>> >>>> Thank you, >>>> Anton > From philip.race at oracle.com Fri Jun 2 17:06:33 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 2 Jun 2017 10:06:33 -0700 Subject: [OpenJDK 2D-Dev] printing from the mac sandbox In-Reply-To: References: <2457AAE3-CB15-472F-85C0-BC1C68CD255A@seanreilly.com> Message-ID: <8e78cc64-17d5-d3fd-a6af-c48ede6268eb@oracle.com> see in-line. On 06/01/2017 08:09 AM, Sean Reilly wrote: > There is a printing problem using recent JDKs when running within the macOS sandbox as of 10.12.4. > > Looking at the jdk8 sources, CUPSfuncs.c seems to ignore the cupsServer by the system CUPS libraries if it returns a reference to a unix domain socket address: > > // Is this a local domain socket? > if (strncmp(server, "/", 1) == 0) { > cServer = JNU_NewStringPlatform(env, "localhost"); > } else { > cServer = JNU_NewStringPlatform(env, server); > } > > This causes the CUPSPrinter.java and CUPSfunc code to connect to localhost via TCP port 631 instead of the advertised unix domain socket. > > MacOS Sierra 10.12.4 had some security related changes to the sandbox which explicitly blocks connections from a sandboxed app to TCP localhost:631. This blockage (or at least a very long delay) applies even if the sandboxed app has network-client, network-server, and print entitlements, which means there's no way around the problem. > > I've talked to Apple DTS and they aren't inclined to allow the connection to localhost:631, even if the network-client and print entitlements are enabled. It seems a bit stubborn of them but to be fair java is ignoring the advertised CUPS server string and assuming that a TCP/localhost:631 interface is available. > > As you can imagine, not being able to print from a desktop app is pretty bad for business. > > My questions are: > 1) Is anyone at Oracle aware of and working on this? Not so far as I know. > > 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. 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 ? import javax.print.*; public class GAP { public static void main(String[] args) { System.out.println("get printers"); long t0 = System.currentTimeMillis(); PrintService[] printers = PrintServiceLookup.lookupPrintServices(null, null); long t1 = System.currentTimeMillis(); System.out.println("got printers in " + (t1-t0) + "ms."); for (int p=0; p > 3) Is a patch that uses the unix domain socket likely to be accepted, and if so, where should it be sent? This list. -phil. > > Thanks, > Sean > > From sergey.bylokhov at oracle.com Mon Jun 5 00:53:35 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 4 Jun 2017 17:53:35 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly Message-ID: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default> If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes. ----- sergey.bylokhov at oracle.com wrote: > Hello. > Here is an updated version where most of the caption are visible. > Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8180326/webrev.02/ > Specdiff: > http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html > > You can use search to check the changes in some specific class: > Old docs: > http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html > New docs: > http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html > > > ----- jonathan.gibbons at oracle.com wrote: > > > Phil, > > > > I have no evidence one way or the other whether screen readers pay > > attention > > to undisplayed or invisible captions. It seemed safest to assume > that > > > > they would > > read a visible caption, and that we should head in that general > > direction. > > > > -- Jon > > > > > > On 05/17/2017 11:58 AM, Phil Race wrote: > > > And PS I was not saying anything to contradict > > > > tables should not have a summary attribute and should have a > > caption. > > > > > > However that the docs I read on the web did seem to imply that > > > summary was very much intended for ATs but it was not at all > clear > > this > > > is the point of caption. I'm sure they can read it, but I don't > get > > > > > how making > > > it visible matters to them so how it making it visible relates to > > > > accessibility > > > requirements is not an obvious connection to me. So why do we > have > > > to make it visible for ATs ? > > > > > > -phil. > > > > > > On 05/17/2017 11:54 AM, Phil Race wrote: > > >> I will leave the decision on whether to do that now up to Sergey > > > >> although > > >> it seems all he has to do here is remove "invisible". > > >> Many of the "summary" ones had wrong or misleading text but they > > >> seem to have been all fixed. > > >> > > >> I'd want to see what the new HTML looks like with a visible > title > > of > > >> course .. > > >> > > >> -phil. > > >> > > >> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote: > > >>> Phil, > > >>> > > >>> The bottom line is that in the JDK docs, tables should not have > a > > > > >>> summary attribute and should have a caption. This comes down to > > > >>> accessibility requirements, where we are slowly raising the bar > on > > > > >>> our docs, to be in accordance with Oracle's guidelines. > > >>> > > >>> Hiding the caption (style="display:none") is an interim measure > we > > > > >>> have been using during the HTML 5 updates, especially in cases > > where > > >>> the person doing the markup changes did not know enough to > create > > an > > >>> appropriate caption that should be displayed. In time, we should > > > >>> locate and update all table captions (in our standard docs > bundle) > > > > >>> that are not being displayed such that the text is both > > appropriate > > >>> and visible. If you guys want to do that as part of this > update, > > go > > >>> ahead. FWIW, that is what we did for the java.xml module in the > > jaxp > > >>> repo ... pretty much all tables there now have a reasonable, > > visible > > >>> caption. > > >>> > > >>> -- Jon > > >>> > > >>> > > >>> > > >>> On 05/17/2017 11:19 AM, Phil Race wrote: > > >>>> I am not sure we are using the summary in a way that makes it > > >>>> worthwhile. > > >>>> As you noted in the other mail > > >>>> "The summary attribute was used to give a more descriptive > value > > >>>> of the contents of the table. A caption is more like a > title" > > >>>> > > >>>> The values I see are more like a title and as you say that is > not > > > > >>>> the idea. See the example here > > >>>> > > >>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html > > >>>> > > >>>> Caption sounds like a title so it might actually be more > > >>>> appropriate than summary > > >>>> for the text we have except that its not clear why we'd want > it > > to > > >>>> be visible when we were fine without. > > >>>> > > >>>> But being there and invisible may be pointless unless screen > > >>>> readers look for it even if invisible. > > >>>> > > >>>> But if its not doing any harm I guess we can leave it as > > proposed > > >>>> > > >>>> I still need to look at the rest of the changes. > > >>>> > > >>>> -phil. > > >>>> > > >>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote: > > >>>>> Sergey, > > >>>>> > > >>>>> FWIW, the invisible caption should be regarded as a temporary > > > >>>>> solution, until content authors can review/update the text of > > the > > >>>>> caption and make it visible. > > >>>>> > > >>>>> The general guideline in this conversion work has been to > avoid > > > > >>>>> changing the visible text of the specification, and captions > > fall > > >>>>> into a grey area of whether the text is significant/normative > or > > > > >>>>> not. Hence the temporary step to make them not displayed for > > now. > > >>>>> > > >>>>> -- Jon > > >>>>> > > >>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote: > > >>>>>> The "summary" is unsupported by the HTML5 and we replace it > by > > > > >>>>>> invisible caption. > > >>>>>> These new styles are located in the stylesheet.css in the > root > > of > > >>>>>> the JavaDoc api folder, so I assume these styles should be > used > > > > >>>>>> by others as well. > > >>>>>> They were added by this fix: > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479 > > >>>>>> > > >>>>>> ----- philip.race at oracle.com wrote: > > >>>>>> > > >>>>>>> Does this in any way match the rest of the docs ? Or is > > everyone > > >>>>>>> left > > >>>>>>> to > > >>>>>>> style things how they want. > > >>>>>>> I thought (?) maybe there is to be some javadoc tool > support > > for > > >>>>>>> CSS > > >>>>>>> styles. > > >>>>>>> > > >>>>>>> Also why are all the table summaries removed ? > > >>>>>>> > > >>>>>>> -phil. > > >>>>>>> > > >>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote: > > >>>>>>>> This is because I use the same style for most of the > tables > > >>>>>>> 'class="striped"', which apply the same/unified style for > > >>>>>>> all(most) of > > >>>>>>> our tables. > > >>>>>>>> Also this is because I removed 'inlined' styles, like > here: > > >>>>>>>> > > >>>>>>> > > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html > > > > >>>>>>> > > >>>>>>>> ----- philip.race at oracle.com wrote: > > >>>>>>>> > > >>>>>>>>> Adding 2d-dev because a number of the files are 2D. > > >>>>>>>>> > > >>>>>>>>> What is the general reason for changing the appearance of > > the > > >>>>>>> tables? > > >>>>>>>>> -phil. > > >>>>>>>>> > > >>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote: > > >>>>>>>>>> Hello, > > >>>>>>>>>> Please review the fix for jdk9-dev. > > >>>>>>>>>> > > >>>>>>>>>> This fix is a part of the effort to make all javadoc in > > jdk9 be > > >>>>>>>>> compatible to HTML5. > > >>>>>>>>>> It covers all errors which are reported by the javadoc > > tool > > >>>>>>> during > > >>>>>>>>> the build of jdk for java.desktop module. > > >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 > > >>>>>>>>>> Webrev can be found at: > > >>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01 > > >>>>>>>>>> Note that an appearance of some tables were changed > after > > the > > >>>>>>> fix: > > >>>>>>>>>> Before: > > >>>>>>> > > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html > > > > >>>>>>> > > >>>>>>>>>> After: > > >>>>>>> > > > http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html > > > > >>>>>>> > > >>>>>>>>>> Before: > > >>>>>>> > > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html > > > > >>>>>>> > > >>>>>>>>>> After : > > >>>>>>> > > > http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html > > > > >>>>>>> > > >>>>>>>>>> Before: > > >>>>>>> > > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html > > > > >>>>>>> > > >>>>>>>>>> After: > > >>>>>>> > > > http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html > > > > >>>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > From philip.race at oracle.com Mon Jun 5 01:12:28 2017 From: philip.race at oracle.com (Philip Race) Date: Sun, 04 Jun 2017 18:12:28 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly In-Reply-To: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default> References: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default> Message-ID: <5934AFFC.8080805@oracle.com> I don't remember anything left that I would object to .. and we'll push client changes to dev this week anyway so it all sounds fine. -phil. On 6/4/17, 5:53 PM, Sergey Bylokhov wrote: > If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes. > > ----- sergey.bylokhov at oracle.com wrote: > >> Hello. >> Here is an updated version where most of the caption are visible. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8180326/webrev.02/ >> Specdiff: >> http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html >> >> You can use search to check the changes in some specific class: >> Old docs: >> http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html >> New docs: >> http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html >> >> >> ----- jonathan.gibbons at oracle.com wrote: >> >>> Phil, >>> >>> I have no evidence one way or the other whether screen readers pay >>> attention >>> to undisplayed or invisible captions. It seemed safest to assume >> that >>> they would >>> read a visible caption, and that we should head in that general >>> direction. >>> >>> -- Jon >>> >>> >>> On 05/17/2017 11:58 AM, Phil Race wrote: >>>> And PS I was not saying anything to contradict >>>>> tables should not have a summary attribute and should have a >>> caption. >>>> However that the docs I read on the web did seem to imply that >>>> summary was very much intended for ATs but it was not at all >> clear >>> this >>>> is the point of caption. I'm sure they can read it, but I don't >> get >>>> how making >>>> it visible matters to them so how it making it visible relates to >>>> accessibility >>>> requirements is not an obvious connection to me. So why do we >> have >>>> to make it visible for ATs ? >>>> >>>> -phil. >>>> >>>> On 05/17/2017 11:54 AM, Phil Race wrote: >>>>> I will leave the decision on whether to do that now up to Sergey >>>>> although >>>>> it seems all he has to do here is remove "invisible". >>>>> Many of the "summary" ones had wrong or misleading text but they >>>>> seem to have been all fixed. >>>>> >>>>> I'd want to see what the new HTML looks like with a visible >> title >>> of >>>>> course .. >>>>> >>>>> -phil. >>>>> >>>>> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote: >>>>>> Phil, >>>>>> >>>>>> The bottom line is that in the JDK docs, tables should not have >> a >>>>>> summary attribute and should have a caption. This comes down to >>>>>> accessibility requirements, where we are slowly raising the bar >> on >>>>>> our docs, to be in accordance with Oracle's guidelines. >>>>>> >>>>>> Hiding the caption (style="display:none") is an interim measure >> we >>>>>> have been using during the HTML 5 updates, especially in cases >>> where >>>>>> the person doing the markup changes did not know enough to >> create >>> an >>>>>> appropriate caption that should be displayed. In time, we should >>>>>> locate and update all table captions (in our standard docs >> bundle) >>>>>> that are not being displayed such that the text is both >>> appropriate >>>>>> and visible. If you guys want to do that as part of this >> update, >>> go >>>>>> ahead. FWIW, that is what we did for the java.xml module in the >>> jaxp >>>>>> repo ... pretty much all tables there now have a reasonable, >>> visible >>>>>> caption. >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> >>>>>> On 05/17/2017 11:19 AM, Phil Race wrote: >>>>>>> I am not sure we are using the summary in a way that makes it >>>>>>> worthwhile. >>>>>>> As you noted in the other mail >>>>>>> "The summary attribute was used to give a more descriptive >> value >>>>>>> of the contents of the table. A caption is more like a >> title" >>>>>>> The values I see are more like a title and as you say that is >> not >>>>>>> the idea. See the example here >>>>>>> >>>>>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html >>>>>>> >>>>>>> Caption sounds like a title so it might actually be more >>>>>>> appropriate than summary >>>>>>> for the text we have except that its not clear why we'd want >> it >>> to >>>>>>> be visible when we were fine without. >>>>>>> >>>>>>> But being there and invisible may be pointless unless screen >>>>>>> readers look for it even if invisible. >>>>>>> >>>>>>> But if its not doing any harm I guess we can leave it as >>> proposed >>>>>>> I still need to look at the rest of the changes. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote: >>>>>>>> Sergey, >>>>>>>> >>>>>>>> FWIW, the invisible caption should be regarded as a temporary >>>>>>>> solution, until content authors can review/update the text of >>> the >>>>>>>> caption and make it visible. >>>>>>>> >>>>>>>> The general guideline in this conversion work has been to >> avoid >>>>>>>> changing the visible text of the specification, and captions >>> fall >>>>>>>> into a grey area of whether the text is significant/normative >> or >>>>>>>> not. Hence the temporary step to make them not displayed for >>> now. >>>>>>>> -- Jon >>>>>>>> >>>>>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote: >>>>>>>>> The "summary" is unsupported by the HTML5 and we replace it >> by >>>>>>>>> invisible caption. >>>>>>>>> These new styles are located in the stylesheet.css in the >> root >>> of >>>>>>>>> the JavaDoc api folder, so I assume these styles should be >> used >>>>>>>>> by others as well. >>>>>>>>> They were added by this fix: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479 >>>>>>>>> >>>>>>>>> ----- philip.race at oracle.com wrote: >>>>>>>>> >>>>>>>>>> Does this in any way match the rest of the docs ? Or is >>> everyone >>>>>>>>>> left >>>>>>>>>> to >>>>>>>>>> style things how they want. >>>>>>>>>> I thought (?) maybe there is to be some javadoc tool >> support >>> for >>>>>>>>>> CSS >>>>>>>>>> styles. >>>>>>>>>> >>>>>>>>>> Also why are all the table summaries removed ? >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote: >>>>>>>>>>> This is because I use the same style for most of the >> tables >>>>>>>>>> 'class="striped"', which apply the same/unified style for >>>>>>>>>> all(most) of >>>>>>>>>> our tables. >>>>>>>>>>> Also this is because I removed 'inlined' styles, like >> here: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html >>>>>>>>>>> ----- philip.race at oracle.com wrote: >>>>>>>>>>> >>>>>>>>>>>> Adding 2d-dev because a number of the files are 2D. >>>>>>>>>>>> >>>>>>>>>>>> What is the general reason for changing the appearance of >>> the >>>>>>>>>> tables? >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> Please review the fix for jdk9-dev. >>>>>>>>>>>>> >>>>>>>>>>>>> This fix is a part of the effort to make all javadoc in >>> jdk9 be >>>>>>>>>>>> compatible to HTML5. >>>>>>>>>>>>> It covers all errors which are reported by the javadoc >>> tool >>>>>>>>>> during >>>>>>>>>>>> the build of jdk for java.desktop module. >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 >>>>>>>>>>>>> Webrev can be found at: >>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01 >>>>>>>>>>>>> Note that an appearance of some tables were changed >> after >>> the >>>>>>>>>> fix: >>>>>>>>>>>>> Before: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html >>>>>>>>>>>>> After: >> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html >>>>>>>>>>>>> Before: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html >>>>>>>>>>>>> After : >> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html >>>>>>>>>>>>> Before: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html >>>>>>>>>>>>> After: >> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html From prasanta.sadhukhan at oracle.com Mon Jun 5 07:04:53 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 5 Jun 2017 12:34:53 +0530 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: <3267ec4c-45ab-4a39-a620-bc987e1e2064@default> References: <3633d215-ec1a-4c16-a74b-a80627e45cb5@default> <1db4e0a1-63a2-2d15-b6b6-16dba6c1c3b5@oracle.com> <3267ec4c-45ab-4a39-a620-bc987e1e2064@default> Message-ID: <4a9b07a8-5fc9-0ed2-3622-790a9f8f4ac6@oracle.com> 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: From shashidhara.veerabhadraiah at oracle.com Tue Jun 6 05:54:17 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 5 Jun 2017 22:54:17 -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: <4a9b07a8-5fc9-0ed2-3622-790a9f8f4ac6@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> Message-ID: <868ecb9f-8ce3-48dd-a347-c487223874f0@default> 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 @ 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: From sergey.bylokhov at oracle.com Tue Jun 6 06:17:18 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 5 Jun 2017 23:17:18 -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: <868ecb9f-8ce3-48dd-a347-c487223874f0@default> 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> Message-ID: <5A63A8AE-C67B-4DC8-BA66-91036D65224F@oracle.com> I did not check the all code, but small comment: Note that all Swing components should be always accessed on EDT. If InvokeAnDWait does not work then you can use InvokeLater(). > > 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 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: > > > 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: From prasanta.sadhukhan at oracle.com Tue Jun 6 06:22:22 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 6 Jun 2017 11:52:22 +0530 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: <868ecb9f-8ce3-48dd-a347-c487223874f0@default> 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> Message-ID: <3bf67087-64b4-0b50-f09c-abc680c562b9@oracle.com> 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: From alexander.zvegintsev at oracle.com Tue Jun 6 09:55:47 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 6 Jun 2017 15:25:47 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly In-Reply-To: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default> References: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default> Message-ID: <1e7d4767-b747-cb0f-10ec-b1bd916d911f@oracle.com> Hi Sergey, Why do we omitting closing th tag? e.g. + * Metal's system color mapping + * + * + * Key + * Value + * I know that HTML parsers are usually forgiving such things. But sometimes it may make thing worse: https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378 Thanks, Alexander. On 05/06/2017 06:23, Sergey Bylokhov wrote: > If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes. > > ----- sergey.bylokhov at oracle.com wrote: > >> Hello. >> Here is an updated version where most of the caption are visible. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8180326/webrev.02/ >> Specdiff: >> http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html >> >> You can use search to check the changes in some specific class: >> Old docs: >> http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html >> New docs: >> http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html >> >> >> ----- jonathan.gibbons at oracle.com wrote: >> >>> Phil, >>> >>> I have no evidence one way or the other whether screen readers pay >>> attention >>> to undisplayed or invisible captions. It seemed safest to assume >> that >>> they would >>> read a visible caption, and that we should head in that general >>> direction. >>> >>> -- Jon >>> >>> >>> On 05/17/2017 11:58 AM, Phil Race wrote: >>>> And PS I was not saying anything to contradict >>>>> tables should not have a summary attribute and should have a >>> caption. >>>> However that the docs I read on the web did seem to imply that >>>> summary was very much intended for ATs but it was not at all >> clear >>> this >>>> is the point of caption. I'm sure they can read it, but I don't >> get >>>> how making >>>> it visible matters to them so how it making it visible relates to >>>> accessibility >>>> requirements is not an obvious connection to me. So why do we >> have >>>> to make it visible for ATs ? >>>> >>>> -phil. >>>> >>>> On 05/17/2017 11:54 AM, Phil Race wrote: >>>>> I will leave the decision on whether to do that now up to Sergey >>>>> although >>>>> it seems all he has to do here is remove "invisible". >>>>> Many of the "summary" ones had wrong or misleading text but they >>>>> seem to have been all fixed. >>>>> >>>>> I'd want to see what the new HTML looks like with a visible >> title >>> of >>>>> course .. >>>>> >>>>> -phil. >>>>> >>>>> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote: >>>>>> Phil, >>>>>> >>>>>> The bottom line is that in the JDK docs, tables should not have >> a >>>>>> summary attribute and should have a caption. This comes down to >>>>>> accessibility requirements, where we are slowly raising the bar >> on >>>>>> our docs, to be in accordance with Oracle's guidelines. >>>>>> >>>>>> Hiding the caption (style="display:none") is an interim measure >> we >>>>>> have been using during the HTML 5 updates, especially in cases >>> where >>>>>> the person doing the markup changes did not know enough to >> create >>> an >>>>>> appropriate caption that should be displayed. In time, we should >>>>>> locate and update all table captions (in our standard docs >> bundle) >>>>>> that are not being displayed such that the text is both >>> appropriate >>>>>> and visible. If you guys want to do that as part of this >> update, >>> go >>>>>> ahead. FWIW, that is what we did for the java.xml module in the >>> jaxp >>>>>> repo ... pretty much all tables there now have a reasonable, >>> visible >>>>>> caption. >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> >>>>>> On 05/17/2017 11:19 AM, Phil Race wrote: >>>>>>> I am not sure we are using the summary in a way that makes it >>>>>>> worthwhile. >>>>>>> As you noted in the other mail >>>>>>> "The summary attribute was used to give a more descriptive >> value >>>>>>> of the contents of the table. A caption is more like a >> title" >>>>>>> The values I see are more like a title and as you say that is >> not >>>>>>> the idea. See the example here >>>>>>> >>>>>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html >>>>>>> >>>>>>> Caption sounds like a title so it might actually be more >>>>>>> appropriate than summary >>>>>>> for the text we have except that its not clear why we'd want >> it >>> to >>>>>>> be visible when we were fine without. >>>>>>> >>>>>>> But being there and invisible may be pointless unless screen >>>>>>> readers look for it even if invisible. >>>>>>> >>>>>>> But if its not doing any harm I guess we can leave it as >>> proposed >>>>>>> I still need to look at the rest of the changes. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote: >>>>>>>> Sergey, >>>>>>>> >>>>>>>> FWIW, the invisible caption should be regarded as a temporary >>>>>>>> solution, until content authors can review/update the text of >>> the >>>>>>>> caption and make it visible. >>>>>>>> >>>>>>>> The general guideline in this conversion work has been to >> avoid >>>>>>>> changing the visible text of the specification, and captions >>> fall >>>>>>>> into a grey area of whether the text is significant/normative >> or >>>>>>>> not. Hence the temporary step to make them not displayed for >>> now. >>>>>>>> -- Jon >>>>>>>> >>>>>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote: >>>>>>>>> The "summary" is unsupported by the HTML5 and we replace it >> by >>>>>>>>> invisible caption. >>>>>>>>> These new styles are located in the stylesheet.css in the >> root >>> of >>>>>>>>> the JavaDoc api folder, so I assume these styles should be >> used >>>>>>>>> by others as well. >>>>>>>>> They were added by this fix: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479 >>>>>>>>> >>>>>>>>> ----- philip.race at oracle.com wrote: >>>>>>>>> >>>>>>>>>> Does this in any way match the rest of the docs ? Or is >>> everyone >>>>>>>>>> left >>>>>>>>>> to >>>>>>>>>> style things how they want. >>>>>>>>>> I thought (?) maybe there is to be some javadoc tool >> support >>> for >>>>>>>>>> CSS >>>>>>>>>> styles. >>>>>>>>>> >>>>>>>>>> Also why are all the table summaries removed ? >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote: >>>>>>>>>>> This is because I use the same style for most of the >> tables >>>>>>>>>> 'class="striped"', which apply the same/unified style for >>>>>>>>>> all(most) of >>>>>>>>>> our tables. >>>>>>>>>>> Also this is because I removed 'inlined' styles, like >> here: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html >>>>>>>>>>> ----- philip.race at oracle.com wrote: >>>>>>>>>>> >>>>>>>>>>>> Adding 2d-dev because a number of the files are 2D. >>>>>>>>>>>> >>>>>>>>>>>> What is the general reason for changing the appearance of >>> the >>>>>>>>>> tables? >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> Please review the fix for jdk9-dev. >>>>>>>>>>>>> >>>>>>>>>>>>> This fix is a part of the effort to make all javadoc in >>> jdk9 be >>>>>>>>>>>> compatible to HTML5. >>>>>>>>>>>>> It covers all errors which are reported by the javadoc >>> tool >>>>>>>>>> during >>>>>>>>>>>> the build of jdk for java.desktop module. >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 >>>>>>>>>>>>> Webrev can be found at: >>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01 >>>>>>>>>>>>> Note that an appearance of some tables were changed >> after >>> the >>>>>>>>>> fix: >>>>>>>>>>>>> Before: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html >>>>>>>>>>>>> After: >> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html >>>>>>>>>>>>> Before: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html >>>>>>>>>>>>> After : >> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html >>>>>>>>>>>>> Before: >> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html >>>>>>>>>>>>> After: >> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Wed Jun 7 06:20:56 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 6 Jun 2017 23:20:56 -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: <3bf67087-64b4-0b50-f09c-abc680c562b9@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> Message-ID: 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 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: From prasanta.sadhukhan at oracle.com Wed Jun 7 06:59:44 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 7 Jun 2017 12:29:44 +0530 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> Message-ID: <0142127f-a994-6f20-8a28-8afe64f8921e@oracle.com> 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: From jayathirth.d.v at oracle.com Wed Jun 7 10:42:54 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 7 Jun 2017 03:42:54 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime In-Reply-To: <89230e11-6102-4468-9356-ca6cc7ba536a@default> References: <89230e11-6102-4468-9356-ca6cc7ba536a@default> Message-ID: <753ef90c-4539-430b-9059-46cfeb89c5a0@default> Hello Prahalad, Please find my inputs. 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. 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. 2) From the PNGMetadata. extractCreationTimeFromText() implementation 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. 3) Since we are maintaining standard metadata "ImageCreationTime" info from the last RFC1123 compliant text chunk while decoding. When an user adds new "ImageCreationTime" standard node which follows RFC1123 text to already present metadata, we should update the last text chunk from which we have captured creation time information while decoding. 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. 4) Also when user adds new native metadata creation time node with RFC1123 compliance to already present list of creation time nodes. We should make sure that the newly added native time chunk is the one that should be updated when one more addition of standard metadata "ImageCreationTime" node happens. Basically for 3 & 4 points we have to maintain what is the active native text chunk and what should be its corresponding creation time information in standard metadata. 5) One more question is about how are we planning to maintain IIOMetadata consistency between multiple decoding & encoding sequences. We decode the metadata of PNG file as text chunks appear but we encode multiple same text chunks collectively. So when an user gets IIOMetadata of an image and updates it with multiple native and standard creation time chunks and later encode it. How we will maintain that what is the primary native text chunk from where we have to update standard metadata creation time. 6) It's better to maintain /* */ format for multiple line comments then using multiple //. Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Saturday, April 22, 2017 4:33 PM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime Hello Everyone Good day to you. Request your time in reviewing a fix for the bug . JDK-8164971 PNG metadata does not handle ImageCreationTime Root Cause: . First, the PNGImageReader 's logic skips parsing of 'any' chunk once IDAT is found. . Hence, if the ancilliary text chunks appear after IDAT chunk, they are not processed at all. . Second, the parsing of text chunks does not check for 'Creation Time' keyword. . As a result the image creation time is never retrieved from .png image. . The converse is true as well- While writing a png image, the creation time is not written to text chunk Details on the Fix: . PNGImageReader . Logic has been fixed to continue parsing chunks until IEND chunk is found . Methods that process text chunks now check for the presence of 'Creation Time' and retrieve the time information. . PNGMetadata: . New methods and variables to support image creation time in metadata. . Proper use of DateTimeFormatter.RFC_1123_DATE_TIME to decode time from text chunk and encode time to text as well. . Changes to existing methods (that allow node retrieval & merge) for reading and updating creation time. . Test Case & Test Image . The test case- PngCreationTimeTest, checks the following use-cases . Decoding creation time from duke.png 's text chunk. . I created the image using gimp and added text chunk programmatically with Creation Time in it . Updating the image creation time using- mergeTree (nativeTree) and inspecting same value in standard Document node . Updating the image creation time using- mergeTree (standardTree) and inspecting same value in native tree's text entry. Other Details: . The changes were tested with Jtreg and JCK suites . No regressions were seen. Kindly review the changes at your convenience and provide your suggestions. Review Link: http://cr.openjdk.java.net/~pnarayanan/8164971/webrev.00/ Thank you for your time in review Have a good day From sergey.bylokhov at oracle.com Wed Jun 7 17:52:57 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 7 Jun 2017 10:52:57 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly Message-ID: <975b438a-ad3e-4e1d-bb41-518ba4f9017b@default> Hi, Alexander. These closing tags are optional in html5 standard [1]. On the link to the SO there are three the example which work differently but according standards[2][3][4]. [1] https://www.w3.org/TR/html5/syntax.html#syntax-tag-omission [2] http://jsfiddle.net/robertc/rNv93/1/ [3] http://jsfiddle.net/UqzEp/2/ [4] http://jsfiddle.net/UqzEp/3/ ----- alexander.zvegintsev at oracle.com wrote: > Hi Sergey, > Why do we omitting closing th tag? > e.g. > + * Metal's system color mapping + * + * + * Key + * Value + * I know that HTML parsers are usually forgiving such things. But sometimes it may make thing worse: > https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378 Thanks, Alexander. > On 05/06/2017 06:23, Sergey Bylokhov wrote: > If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes. ----- sergey.bylokhov at oracle.com wrote: Hello. Here is an updated version where most of the caption are visible. Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.02/ Specdiff: http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html You can use search to check the changes in some specific class: Old docs: http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html New docs: http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html ----- jonathan.gibbons at oracle.com wrote: Phil, I have no evidence one way or the other whether screen readers pay attention to undisplayed or invisible captions. It seemed safest to assume that they would read a visible caption, and that we should head in that general direction. -- Jon On 05/17/2017 11:58 AM, Phil Race wrote: And PS I was not saying anything to contradict tables should not have a summary attribute and should have a caption. However that the docs I read on the web did seem to imply that summary was very much intended for ATs but it was not at all clear this is the point of caption. I'm sure they can read it, but I don't get how making it visible matters to them so how it making it visible relates to accessibility requirements is not an obvious connection to me. So why do we have to make it visible for ATs ? -phil. On 05/17/2017 11:54 AM, Phil Race wrote: I will leave the decision on whether to do that now up to Sergey although it seems all he has to do here is remove "invisible". Many of the "summary" ones had wrong or misleading text but they seem to have been all fixed. I'd want to see what the new HTML looks like with a visible title of course .. -phil. On 05/17/2017 11:52 AM, Jonathan Gibbons wrote: Phil, The bottom line is that in the JDK docs, tables should not have a summary attribute and should have a caption. This comes down to accessibility requirements, where we are slowly raising the bar on our docs, to be in accordance with Oracle's guidelines. Hiding the caption (style="display:none") is an interim measure we have been using during the HTML 5 updates, especially in cases where the person doing the markup changes did not know enough to create an appropriate caption that should be displayed. In time, we should locate and update all table captions (in our standard docs bundle) that are not being displayed such that the text is both appropriate and visible. If you guys want to do that as part of this update, go ahead. FWIW, that is what we did for the java.xml module in the jaxp repo ... pretty much all tables there now have a reasonable, visible caption. -- Jon On 05/17/2017 11:19 AM, Phil Race wrote: I am not sure we are using the summary in a way that makes it worthwhile. As you noted in the other mail "The summary attribute was used to give a more descriptive value of the contents of the table. A caption is more like a title" The values I see are more like a title and as you say that is not the idea. See the example here https://www.w3.org/TR/WCAG20-TECHS/H73.html Caption sounds like a title so it might actually be more appropriate than summary for the text we have except that its not clear why we'd want it to be visible when we were fine without. But being there and invisible may be pointless unless screen readers look for it even if invisible. But if its not doing any harm I guess we can leave it as proposed I still need to look at the rest of the changes. -phil. On 05/12/2017 05:11 PM, Jonathan Gibbons wrote: Sergey, FWIW, the invisible caption should be regarded as a temporary solution, until content authors can review/update the text of the caption and make it visible. The general guideline in this conversion work has been to avoid changing the visible text of the specification, and captions fall into a grey area of whether the text is significant/normative or not. Hence the temporary step to make them not displayed for now. -- Jon On 05/12/2017 05:00 PM, Sergey Bylokhov wrote: The "summary" is unsupported by the HTML5 and we replace it by invisible caption. These new styles are located in the stylesheet.css in the root of the JavaDoc api folder, so I assume these styles should be used by others as well. They were added by this fix: https://bugs.openjdk.java.net/browse/JDK-8179479 ----- philip.race at oracle.com wrote: Does this in any way match the rest of the docs ? Or is everyone left to style things how they want. I thought (?) maybe there is to be some javadoc tool support for CSS styles. Also why are all the table summaries removed ? -phil. On 5/12/17, 4:52 PM, Sergey Bylokhov wrote: This is because I use the same style for most of the tables 'class="striped"', which apply the same/unified style for all(most) of our tables. Also this is because I removed 'inlined' styles, like here: http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html ----- philip.race at oracle.com wrote: Adding 2d-dev because a number of the files are 2D. What is the general reason for changing the appearance of the tables? -phil. On 5/12/17, 4:25 PM, Sergey Bylokhov wrote: Hello, Please review the fix for jdk9-dev. This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5. It covers all errors which are reported by the javadoc tool during the build of jdk for java.desktop module. Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.01 Note that an appearance of some tables were changed after the fix: Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html After: http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html After : http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html After: http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Jun 7 20:35:43 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 7 Jun 2017 22:35:43 +0200 Subject: [OpenJDK 2D-Dev] [10] RFR 8078192: Path2D storage trimming In-Reply-To: <81bf576a-ddfe-9174-b234-7d070e163d26@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> Message-ID: 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 philip.race at oracle.com Wed Jun 7 20:56:38 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 07 Jun 2017 13:56:38 -0700 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> Message-ID: <59386886.8050309@oracle.com> 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 philip.race at oracle.com Wed Jun 7 22:01:44 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 07 Jun 2017 15:01:44 -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: <0142127f-a994-6f20-8a28-8afe64f8921e@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> Message-ID: <593877C8.3090708@oracle.com> .. 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: From brian.burkhalter at oracle.com Wed Jun 7 22:50:03 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Jun 2017 15:50:03 -0700 Subject: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime In-Reply-To: <753ef90c-4539-430b-9059-46cfeb89c5a0@default> References: <89230e11-6102-4468-9356-ca6cc7ba536a@default> <753ef90c-4539-430b-9059-46cfeb89c5a0@default> Message-ID: <2F938EB2-AE69-4431-A52C-5BD5E3F1AB1F@oracle.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Thu Jun 8 03:10:13 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 7 Jun 2017 20:10:13 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [10] RFR: JDK-8164971: PNG metadata does not handle ImageCreationTime In-Reply-To: <2F938EB2-AE69-4431-A52C-5BD5E3F1AB1F@oracle.com> References: <89230e11-6102-4468-9356-ca6cc7ba536a@default> <753ef90c-4539-430b-9059-46cfeb89c5a0@default> <2F938EB2-AE69-4431-A52C-5BD5E3F1AB1F@oracle.com> Message-ID: <7db9e300-ee3c-4ff3-8794-13f4e36eab16@default> Hello Brian and Jay Good day to you. Thank you for your time and review suggestions. Let me answer to each of your review suggestions here: Brian: > 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"? . I understand the suggestion that ISO 8601 is also a valid representation for the 'time' data. . Since there is no mention of using the ISO standard for time in the PNG Specification, I 'm not checking for this format in the encoded time data. . If required, we can attempt to check if our DateTimeFormatter.ISO_* decode time from the String. . But this only adds more complexity to the logic because tEXt chunks could contain date without the zone information Or date without time information etc., . I 'm not sure how our JDK's DateTimeFormatter.ISO_* work. I will check and get back. > 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. . Yes. There is no mention about the logic to deploy in the PNG specification. . In the code changes, I 've used the last successfully decoded text chunk's information to set the value of Standard/ Document/ ImageCreationTime. . However, the reverse isn't true. Once decoding of image is complete, any update to metadata using Standard/ Document/ ImageCreationTime node updates the first available text chunk and not the last successfully decoded text chunk. (A bug in code change that Jay has pointed out.) > What examples of actual PNG "real world" files have been used for testing? For example ones from PngSuite [2] . I manually created a PNG file with our Java logo in it and ImageCreationTime in the tEXt chunk. . But this is a good suggestion to use a test suite. I will check with images in the test suite and update. Jay: > In PNGMetadata. extractCreationTimeFromText() you are updating the "creation_time_present" to false when it doesn't follow RFC1123 . Yes. This will be corrected. > From the PNGMetadata. extractCreationTimeFromText() implementation 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. . I generally substantiate the logic with enough comments. Looks like I 've missed this one. . Since API documentations are implementation-independent, I will not update comments as part of APIs but only internal implementation within the PNGMetadata. . When I post the new webrev, this will be corrected. > When an user adds new "ImageCreationTime" standard node which follows RFC1123 text to already present metadata, we should update the last text chunk from which we have captured creation time information while decoding . A correction. The Standard/ Document/ ImageCreationTime does not need to follow RFC1123. . The attributes are integers with year, month, day, hour, minutes, seconds. . It's the text chunks in the native metadata tree that 'may' conform to RFC1123 standard. > 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. . Yes. This is a very good find. Thank you. . I will be correct this in the next webrev. > One more question is about how are we planning to maintain IIOMetadata consistency between multiple decoding & encoding sequences. . Well, We discussed on this in-detail. For the benefit of others in community, let me put the findings here- . Our PNG image writer writes all similar text chunks together. For Example: all tEXt chunks together, all iTXt chunks together etc., . So if user adds multiple text chunks with Creation Time, the ordering is not ensured at the time of encoding. . Thus, we cannot guarantee consistency across the lifetime of decoder. (between multiple decode & encode sequences) . Any attempt to provide consistency will resemble a HACK and a messy code, which I don't wish to do now. . Besides, the PNG spec does not lay any logic to choose the creation time in these circumstances. Hence, I would prefer to leave the code as is. > It's better to maintain /* */ format for multiple line comments then using multiple //. . In this regard, I 've used the file's existing code-comment style so that changes are consistent and ensures code readability. . Refer to Line 254 (existing code) 254 // tRNS chunk 255 // If external (non-PNG sourced) data has red = green = blue, 256 // always store it as gray and promote when writing . In my view, code readability gets affected if the existing code // multi-line comments were preceded by comments like 237 /* 238 * creation_time_present- Indicates that the native metadata contains 239 * the image creation time initialized in its variables. The flag is set 240 * true after successfully decoding the time represented as string in the 241 * text chunks or when user explicitly provides the creation time by 242 * manipulating the node tree. 243 */ . I would like to receive the suggestion from others as well on this before I continue to modify the comment style in my code changes. Thank you once again for your time in review and detailed suggestions. I will get back with changes soon. 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 alexander.zvegintsev at oracle.com Thu Jun 8 04:22:25 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 8 Jun 2017 09:52:25 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly In-Reply-To: <975b438a-ad3e-4e1d-bb41-518ba4f9017b@default> References: <975b438a-ad3e-4e1d-bb41-518ba4f9017b@default> Message-ID: Thanks for clarification, looks good to me. Thanks, Alexander. On 07/06/2017 23:22, Sergey Bylokhov wrote: > Hi, Alexander. > These closing tags are optional in html5 standard [1]. On the link to > the SO there are three the example which work differently but > according standards[2][3][4]. > > [1] https://www.w3.org/TR/html5/syntax.html#syntax-tag-omission > > [2] http://jsfiddle.net/robertc/rNv93/1/ > [3] http://jsfiddle.net/UqzEp/2/ > [4] http://jsfiddle.net/UqzEp/3/ > > ----- alexander.zvegintsev at oracle.com wrote: > > > > Hi Sergey, > > > > Why do we omitting closing th tag? > > > > e.g. > > > > + * Metal's system color mapping > + * > + * > + * Key > + * Value > + * > > I know that HTML parsers are usually forgiving such things. But > sometimes it may make thing worse: > > > > https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378 > > Thanks, > Alexander. > > On 05/06/2017 06:23, Sergey Bylokhov wrote: > > > > If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes. > > -----sergey.bylokhov at oracle.com wrote: > > Hello. > Here is an updated version where most of the caption are visible. > Bug:https://bugs.openjdk.java.net/browse/JDK-8180326 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8180326/webrev.02/ > Specdiff: > http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html > > You can use search to check the changes in some specific class: > Old docs: > http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html > New docs: > http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html > > > -----jonathan.gibbons at oracle.com wrote: > > Phil, > > I have no evidence one way or the other whether screen readers pay > attention > to undisplayed or invisible captions. It seemed safest to assume > > that > > they would > read a visible caption, and that we should head in that general > direction. > > -- Jon > > > On 05/17/2017 11:58 AM, Phil Race wrote: > > And PS I was not saying anything to contradict > > tables should not have a summary attribute and should have a > > caption. > > However that the docs I read on the web did seem to imply that > summary was very much intended for ATs but it was not at all > > clear > > this > > is the point of caption. I'm sure they can read it, but I don't > > get > > how making > it visible matters to them so how it making it visible relates to > > accessibility > requirements is not an obvious connection to me. So why do we > > have > > to make it visible for ATs ? > > -phil. > > On 05/17/2017 11:54 AM, Phil Race wrote: > > I will leave the decision on whether to do that now up to Sergey > > although > it seems all he has to do here is remove "invisible". > Many of the "summary" ones had wrong or misleading text but they > seem to have been all fixed. > > I'd want to see what the new HTML looks like with a visible > > title > > of > > course .. > > -phil. > > On 05/17/2017 11:52 AM, Jonathan Gibbons wrote: > > Phil, > > The bottom line is that in the JDK docs, tables should not have > > a > > summary attribute and should have a caption. This comes down to > > accessibility requirements, where we are slowly raising the bar > > on > > our docs, to be in accordance with Oracle's guidelines. > > Hiding the caption (style="display:none") is an interim measure > > we > > have been using during the HTML 5 updates, especially in cases > > where > > the person doing the markup changes did not know enough to > > create > > an > > appropriate caption that should be displayed. In time, we should > > locate and update all table captions (in our standard docs > > bundle) > > that are not being displayed such that the text is both > > appropriate > > and visible. If you guys want to do that as part of this > > update, > > go > > ahead. FWIW, that is what we did for the java.xml module in the > > jaxp > > repo ... pretty much all tables there now have a reasonable, > > visible > > caption. > > -- Jon > > > > On 05/17/2017 11:19 AM, Phil Race wrote: > > I am not sure we are using the summary in a way that makes it > worthwhile. > As you noted in the other mail > "The summary attribute was used to give a more descriptive > > value > > of the contents of the table. A caption is more like a > > title" > > The values I see are more like a title and as you say that is > > not > > the idea. See the example here > > https://www.w3.org/TR/WCAG20-TECHS/H73.html > > Caption sounds like a title so it might actually be more > appropriate than summary > for the text we have except that its not clear why we'd want > > it > > to > > be visible when we were fine without. > > But being there and invisible may be pointless unless screen > readers look for it even if invisible. > > But if its not doing any harm I guess we can leave it as > > proposed > > I still need to look at the rest of the changes. > > -phil. > > On 05/12/2017 05:11 PM, Jonathan Gibbons wrote: > > Sergey, > > FWIW, the invisible caption should be regarded as a temporary > > solution, until content authors can review/update the text of > > the > > caption and make it visible. > > The general guideline in this conversion work has been to > > avoid > > changing the visible text of the specification, and captions > > fall > > into a grey area of whether the text is significant/normative > > or > > not. Hence the temporary step to make them not displayed for > > now. > > -- Jon > > On 05/12/2017 05:00 PM, Sergey Bylokhov wrote: > > The "summary" is unsupported by the HTML5 and we replace it > > by > > invisible caption. > These new styles are located in the stylesheet.css in the > > root > > of > > the JavaDoc api folder, so I assume these styles should be > > used > > by others as well. > They were added by this fix: > https://bugs.openjdk.java.net/browse/JDK-8179479 > > -----philip.race at oracle.com wrote: > > Does this in any way match the rest of the docs ? Or is > > everyone > > left > to > style things how they want. > I thought (?) maybe there is to be some javadoc tool > > support > > for > > CSS > styles. > > Also why are all the table summaries removed ? > > -phil. > > On 5/12/17, 4:52 PM, Sergey Bylokhov wrote: > > This is because I use the same style for most of the > > tables > > 'class="striped"', which apply the same/unified style for > all(most) of > our tables. > > Also this is because I removed 'inlined' styles, like > > here: > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html > > -----philip.race at oracle.com wrote: > > Adding 2d-dev because a number of the files are 2D. > > What is the general reason for changing the appearance of > > the > > tables? > > -phil. > > On 5/12/17, 4:25 PM, Sergey Bylokhov wrote: > > Hello, > Please review the fix for jdk9-dev. > > This fix is a part of the effort to make all javadoc in > > jdk9 be > > compatible to HTML5. > > It covers all errors which are reported by the javadoc > > tool > > during > > the build of jdk for java.desktop module. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8180326 > Webrev can be found at: > > http://cr.openjdk.java.net/~serb/8180326/webrev.01 > > Note that an appearance of some tables were changed > > after > > the > > fix: > > Before: > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html > > After: > > http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html > > Before: > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html > > After : > > http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html > > Before: > > http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html > > After: > > http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Fri Jun 9 10:19:37 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Fri, 9 Jun 2017 03:19:37 -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: <593877C8.3090708@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> Message-ID: <32a345ef-9dae-4f98-a6e7-b5dd72d4fc70@default> 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 @ 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: From prasanta.sadhukhan at oracle.com Fri Jun 9 10:27:39 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 9 Jun 2017 15:57:39 +0530 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: <32a345ef-9dae-4f98-a6e7-b5dd72d4fc70@default> 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> Message-ID: <9967f1d9-d062-0148-7526-f359e854c89a@oracle.com> 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: From philip.race at oracle.com Fri Jun 9 21:37:26 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 9 Jun 2017 14:37:26 -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: <9967f1d9-d062-0148-7526-f359e854c89a@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> Message-ID: <9dcb0639-f1da-6988-2611-b52ca305b876@oracle.com> 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. nit: there's a missing space here 75 } catch(PrinterException e) { -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: From shashidhara.veerabhadraiah at oracle.com Mon Jun 12 10:34:20 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 12 Jun 2017 03:34:20 -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: <9dcb0639-f1da-6988-2611-b52ca305b876@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> Message-ID: <58620d3c-70cc-4355-8057-81cf9fc3c322@default> Hi Phil, Please see below for the comments: ? The updated Webrev is at: http://cr.openjdk.java.net/~aghaisas/shashi/6949753/webrev_05/ ? 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 @ 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: From philip.race at oracle.com Mon Jun 12 16:30:31 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 12 Jun 2017 09:30:31 -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: <58620d3c-70cc-4355-8057-81cf9fc3c322@default> 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> Message-ID: */>[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: From shashidhara.veerabhadraiah at oracle.com Mon Jun 12 17:44:24 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 12 Jun 2017 10:44:24 -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: 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> Message-ID: 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: 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: 31683 bytes Desc: not available URL: From philip.race at oracle.com Mon Jun 12 17:44:42 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 12 Jun 2017 10:44:42 -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> Message-ID: <58a532bd-7c07-fe08-b42c-b9145ead718c@oracle.com> 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: image002.jpg Type: image/jpeg Size: 31683 bytes Desc: not available URL: From shashidhara.veerabhadraiah at oracle.com Mon Jun 12 17:49:00 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 12 Jun 2017 10:49:00 -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: <58a532bd-7c07-fe08-b42c-b9145ead718c@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> Message-ID: 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 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: image001.jpg Type: image/jpeg Size: 31367 bytes Desc: not available URL: From sergey.bylokhov at oracle.com Fri Jun 16 16:49:25 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 16 Jun 2017 19:49:25 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8181894 java.desktop module documentation has links to technotes Message-ID: Hello, Please review the fix for jdk9-dev. A few types of links were fixed: - The fix for JDK-8178412 missed some links to IMF. - The links to jar.html#service_provider were changed to {@link ServiceLoader} - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681 Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Jun 16 23:31:17 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Jun 2017 16:31:17 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8181894 java.desktop module documentation has links to technotes In-Reply-To: References: Message-ID: > On Jun 16, 2017, at 9:49 AM, Sergey Bylokhov wrote: > > Hello, > Please review the fix for jdk9-dev. > > A few types of links were fixed: > - The fix for JDK-8178412 missed some links to IMF. > - The links to jar.html#service_provider were changed to {@link ServiceLoader} > - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 > + * JAR File Specification. This should be You should do a build to verify. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Sat Jun 17 03:11:52 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 17 Jun 2017 06:11:52 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8181894 java.desktop module documentation has links to technotes In-Reply-To: References: Message-ID: Hi, Mandy. I rechecked this fix on top of JDK-8150681, and found that the jar/jar.html was not copied to the "/images/docs/specs/? but for example ?serialization? is copied. >> - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 >> > > + * JAR File Specification. > This should be > > > > You should do a build to verify. > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Sat Jun 17 06:11:27 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Jun 2017 23:11:27 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8181894 java.desktop module documentation has links to technotes In-Reply-To: References: Message-ID: <8C67D508-9FB7-49BC-8339-CD1DDE0DDBE4@oracle.com> It?s in my build: docs/specs/jar/jar.html Do you pull in the up-to-date changeset? Mandy > On Jun 16, 2017, at 8:11 PM, Sergey Bylokhov wrote: > > Hi, Mandy. > I rechecked this fix on top of JDK-8150681, and found that the jar/jar.html was not copied to the "/images/docs/specs/? but for example ?serialization? is copied. > > >>> - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 >>> >> >> + * JAR File Specification. >> This should be >> >> >> >> You should do a build to verify. >> Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Sun Jun 18 20:33:55 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 18 Jun 2017 23:33:55 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8181894 java.desktop module documentation has links to technotes In-Reply-To: References: Message-ID: <5DB90ED0-D962-4AF1-BD1C-684A11C27F51@oracle.com> It seems that there is an issue in generation of html files from .md. But I have verified the new links by creating specs/jar/jar.html manually: http://cr.openjdk.java.net/~serb/8181894/webrev.01 > > Hi, Mandy. > I rechecked this fix on top of JDK-8150681, and found that the jar/jar.html was not copied to the "/images/docs/specs/? but for example ?serialization? is copied. > > >>> - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 >>> >> >> + * JAR File Specification. >> This should be >> >> >> >> You should do a build to verify. >> Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Jun 19 03:53:46 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 18 Jun 2017 20:53:46 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8181894 java.desktop module documentation has links to technotes In-Reply-To: <5DB90ED0-D962-4AF1-BD1C-684A11C27F51@oracle.com> References: <5DB90ED0-D962-4AF1-BD1C-684A11C27F51@oracle.com> Message-ID: > On Jun 18, 2017, at 1:33 PM, Sergey Bylokhov wrote: > > It seems that there is an issue in generation of html files from .md. But I have verified the new links by creating specs/jar/jar.html manually: > http://cr.openjdk.java.net/~serb/8181894/webrev.01 Looks fine to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Wed Jun 21 08:33:30 2017 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Wed, 21 Jun 2017 01:33:30 -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: 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: 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: 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: 31205 bytes Desc: not available URL: