From prem.balakrishnan at oracle.com Mon Apr 2 05:08:08 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Sun, 1 Apr 2018 22:08:08 -0700 (PDT) Subject: [11]JDK-8200343: Minor JViewport documentation typo In-Reply-To: <6f503563-fbc0-6838-e61f-8bef0ce5b8df@oracle.com> References: <75a13efd-9ed9-4483-94bf-88f8824b64e4@default> <6f503563-fbc0-6838-e61f-8bef0ce5b8df@oracle.com> Message-ID: +1 Regards, Prem -----Original Message----- From: Sergey Bylokhov Sent: Saturday, March 31, 2018 2:20 AM To: Krishna Addepalli ; swing-dev at openjdk.java.net Subject: Re: [11]JDK-8200343: Minor JViewport documentation typo +1 On 30/03/2018 05:30, Krishna Addepalli wrote: > Hi All, > > Please review a simple correction for the documentation of JViewport. > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8200343/webrev00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200343 > > Thanks, > > Krishna > -- Best regards, Sergey. From vikrant.v.agarwal at oracle.com Tue Apr 3 10:10:51 2018 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Tue, 3 Apr 2018 03:10:51 -0700 (PDT) Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo Message-ID: <23614819-0fda-4df8-a538-61931fcec4d8@default> Hi All, Please review this new test for SwingSet GridBagLayoutDemo: Webrev: http://cr.openjdk.java.net/~vagarwal/8200605/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8200605 Summary: This adds an automated test for SwingSet GridBagLayoutDemo for all the available look and feels. We have set up Same Binaries Run to check for stability and this test is consistently passing for Linux, Mac and Windows for all the look and feels. Best Regards, Vikrant -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Thu Apr 5 15:38:47 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 5 Apr 2018 08:38:47 -0700 (PDT) Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Message-ID: Hi All, Please review a fix for JDK-8201173: https://bugs.openjdk.java.net/browse/JDK-8201173 Webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev00/ There is the duplication of code in fireContentsChanged, fireIntervalAdded, fireIntervalRemoved functions, barring an int parameter and a function call. Moved the common code into a function called fireUpdates, and defined a functional interface, so that each function can pass its own lambda that does the requisite function call. I have run the tests for JList and JComboBox and observed no new failures. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Thu Apr 5 22:39:17 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 5 Apr 2018 23:39:17 +0100 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 Message-ID: Hello, Could you please review the fix for jdk11? bug: https://bugs.openjdk.java.net/browse/JDK-8199627 webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] Java already supports "Per-Monitor v1" mode. This change extends High DPI support in Java: in addition to element [2], a new element [3] is added to Java launcher manifest. The element is recognized by Windows 10 v1607 and above, PerMonitorV2 value is supported by Windows 10 v1703 and above. The most notable change for Java applications is that window title bar is scaled correctly when application window moves from one monitor to another or the scaling changes. When building, manifest tool generates warning for unknown element in manifest. It is because an older Windows SDK is used to build JDK which does not know about an element that was added later. The build succeeds despite the warning. Thank you in advance. Regards, Alexey [1] https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness From Sergey.Bylokhov at oracle.com Thu Apr 5 22:56:51 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 5 Apr 2018 15:56:51 -0700 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: References: Message-ID: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> Looks fine. On 05/04/2018 15:39, Alexey Ivanov wrote: > Hello, > > Could you please review the fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8199627 > webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ > > > Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] > > Java already supports "Per-Monitor v1" mode. This change extends High > DPI support in Java: in addition to element [2], a new > element [3] is added to Java launcher manifest. The > element is recognized by Windows 10 v1607 and above, > PerMonitorV2 value is supported by Windows 10 v1703 and above. > > The most notable change for Java applications is that window title bar > is scaled correctly when application window moves from one monitor to > another or the scaling changes. > > > When building, manifest tool generates warning for unknown > element in manifest. It is because an older Windows SDK > is used to build JDK which does not know about an element that was added > later. The build succeeds despite the warning. > > > Thank you in advance. > > Regards, > Alexey > > [1] > https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ > > > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware > > > [3] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness > > -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Fri Apr 6 09:33:30 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 6 Apr 2018 02:33:30 -0700 (PDT) Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class In-Reply-To: References: Message-ID: <1a46bc86-2d27-4cfc-b50a-1f4fc43750d0@default> Hi Krishna, The code changes look fine to me. Just one suggestion. I think you don't need to create custom UpdateFunction functional Interface here. Java has BiConsumer functional interface, which does what you are trying to do here. Regards, Pankaj Bansal From: Krishna Addepalli Sent: Thursday, April 5, 2018 9:09 PM To: swing-dev at openjdk.java.net Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Hi All, Please review a fix for JDK-8201173: https://bugs.openjdk.java.net/browse/JDK-8201173 Webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev00/ There is the duplication of code in fireContentsChanged, fireIntervalAdded, fireIntervalRemoved functions, barring an int parameter and a function call. Moved the common code into a function called fireUpdates, and defined a functional interface, so that each function can pass its own lambda that does the requisite function call. I have run the tests for JList and JComboBox and observed no new failures. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Fri Apr 6 09:59:14 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 6 Apr 2018 02:59:14 -0700 (PDT) Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class In-Reply-To: <1a46bc86-2d27-4cfc-b50a-1f4fc43750d0@default> References: <1a46bc86-2d27-4cfc-b50a-1f4fc43750d0@default> Message-ID: <4adba652-748b-4c4a-9653-5d536f76f556@default> Hi Pankaj, Thanks for your review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev01/ Krishna From: Pankaj Bansal Sent: Friday, April 6, 2018 3:04 PM To: Krishna Addepalli ; swing-dev at openjdk.java.net Subject: RE: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Hi Krishna, The code changes look fine to me. Just one suggestion. I think you don't need to create custom UpdateFunction functional Interface here. Java has BiConsumer functional interface, which does what you are trying to do here. Regards, Pankaj Bansal From: Krishna Addepalli Sent: Thursday, April 5, 2018 9:09 PM To: swing-dev at openjdk.java.net Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Hi All, Please review a fix for JDK-8201173: https://bugs.openjdk.java.net/browse/JDK-8201173 Webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev00/ There is the duplication of code in fireContentsChanged, fireIntervalAdded, fireIntervalRemoved functions, barring an int parameter and a function call. Moved the common code into a function called fireUpdates, and defined a functional interface, so that each function can pass its own lambda that does the requisite function call. I have run the tests for JList and JComboBox and observed no new failures. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Fri Apr 6 10:27:52 2018 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 6 Apr 2018 12:27:52 +0200 Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class In-Reply-To: <4adba652-748b-4c4a-9653-5d536f76f556@default> References: <1a46bc86-2d27-4cfc-b50a-1f4fc43750d0@default> <4adba652-748b-4c4a-9653-5d536f76f556@default> Message-ID: Hi all, as a long time user of Swing and as a person who maintains a very huge ( > 3M lines of code) Swing-based application I would like vote against this change. Could you please explain me which bug this change tries to solve? The so called duplicate code is not a bug and lambdas are not the holy grail. Just because lambdas exists it does not mean we should change every piece of code to use it. Your change will introduce a performance regression to every application that makes huge use of JLists and fires many events. Best regards, Andrej Golovnin On Fri, Apr 6, 2018 at 11:59 AM, Krishna Addepalli wrote: > Hi Pankaj, > > > > Thanks for your review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8201173/webrev01/ > > > > Krishna > > From: Pankaj Bansal > Sent: Friday, April 6, 2018 3:04 PM > To: Krishna Addepalli ; > swing-dev at openjdk.java.net > Subject: RE: [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi Krishna, > > > > The code changes look fine to me. > > Just one suggestion. I think you don?t need to create custom UpdateFunction > functional Interface here. Java has BiConsumer functional interface, which > does what you are trying to do here. > > > > Regards, > > Pankaj Bansal > > > > From: Krishna Addepalli > Sent: Thursday, April 5, 2018 9:09 PM > To: swing-dev at openjdk.java.net > Subject: [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi All, > > Please review a fix for > > JDK-8201173: https://bugs.openjdk.java.net/browse/JDK-8201173 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev00/ > > > > There is the duplication of code in fireContentsChanged, fireIntervalAdded, > fireIntervalRemoved functions, barring an int parameter and a function call. > > Moved the common code into a function called fireUpdates, and defined a > functional interface, so that each function can pass its own lambda that > does the requisite function call. > > > > I have run the tests for JList and JComboBox and observed no new failures. > > > > Thanks, > > Krishna From krishna.addepalli at oracle.com Fri Apr 6 12:45:17 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 6 Apr 2018 05:45:17 -0700 (PDT) Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class In-Reply-To: References: <1a46bc86-2d27-4cfc-b50a-1f4fc43750d0@default> <4adba652-748b-4c4a-9653-5d536f76f556@default> Message-ID: Hi Andrej, Thanks for your concerns and comments. Yes the duplicated code is not a bug, but nevertheless an overhead, when it is preventable. Also agree that lambdas cannot solve all the problems, but in this case, they lend to a nice solution to reduce the duplication of the code. As for the performance considerations, yes it is one extra function call, but with modern JVMs equipped with JIT, and method inlining, either the method is optimized away, or the JIT compiler will certainly optimize the call overhead, for large number of iterations. I havenot done extensive research, but of the little I have done, it seems to indicate that, the cost of lambdas is negligible. Here are some of the links I have read through: 1. https://stackoverflow.com/questions/6495030/java-how-expensive-is-a-method-call - The usual goto place for any questions like this and this had additional pointers, but all the people seemed to agree that the compiler/VM would most likely inline the call. 2. https://www.youtube.com/watch?v=C_QbkGU_lqY - A very good session by Brian Goetz, which explains how lambdas are implemented under the hood, and gives some great insights. Basically, the lambdas I have used in my code are captureless, and that boils down to a constant loading in VM, and invokedynamic is used to call the lambdas. Ofcourse, when we are talking about huge number of iterations, the JIT compiler will kick in and might optimize away the call altogether. 3. https://plumbr.io/blog/performance-blog/how-expensive-is-a-method-call-in-java - Another blog which is trying to assess the cost of a method call over large number of iterations, and in the case when JIT kicked in, the additional time taken was just 205 nano seconds for 1023 additional method invocations. So, for large iterations, JIT is likely to mitigate the cost of extra method calls. Let me know your thoughts on this. Thanks, Krishna. -----Original Message----- From: Andrej Golovnin Sent: Friday, April 6, 2018 3:58 PM To: Krishna Addepalli Cc: Pankaj Bansal ; swing-dev at openjdk.java.net Subject: Re: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Hi all, as a long time user of Swing and as a person who maintains a very huge ( > 3M lines of code) Swing-based application I would like vote against this change. Could you please explain me which bug this change tries to solve? The so called duplicate code is not a bug and lambdas are not the holy grail. Just because lambdas exists it does not mean we should change every piece of code to use it. Your change will introduce a performance regression to every application that makes huge use of JLists and fires many events. Best regards, Andrej Golovnin On Fri, Apr 6, 2018 at 11:59 AM, Krishna Addepalli wrote: > Hi Pankaj, > > > > Thanks for your review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8201173/webrev01/ > > > > Krishna > > From: Pankaj Bansal > Sent: Friday, April 6, 2018 3:04 PM > To: Krishna Addepalli ; > swing-dev at openjdk.java.net > Subject: RE: [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi Krishna, > > > > The code changes look fine to me. > > Just one suggestion. I think you don?t need to create custom > UpdateFunction functional Interface here. Java has BiConsumer > functional interface, which does what you are trying to do here. > > > > Regards, > > Pankaj Bansal > > > > From: Krishna Addepalli > Sent: Thursday, April 5, 2018 9:09 PM > To: swing-dev at openjdk.java.net > Subject: [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi All, > > Please review a fix for > > JDK-8201173: https://bugs.openjdk.java.net/browse/JDK-8201173 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev00/ > > > > There is the duplication of code in fireContentsChanged, > fireIntervalAdded, fireIntervalRemoved functions, barring an int parameter and a function call. > > Moved the common code into a function called fireUpdates, and defined > a functional interface, so that each function can pass its own lambda > that does the requisite function call. > > > > I have run the tests for JList and JComboBox and observed no new failures. > > > > Thanks, > > Krishna From krishna.addepalli at oracle.com Fri Apr 6 12:58:58 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 6 Apr 2018 05:58:58 -0700 (PDT) Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class In-Reply-To: References: <1a46bc86-2d27-4cfc-b50a-1f4fc43750d0@default> <4adba652-748b-4c4a-9653-5d536f76f556@default> Message-ID: Also, another link which provides some benchmark results for lambda performance: http://www.oracle.com/technetwork/java/jvmls2013kuksen-2014088.pdf Note the section where it compares the results with method inlines and lambdas, and they both are same for simple lambdas. -----Original Message----- From: Krishna Addepalli Sent: Friday, April 6, 2018 6:15 PM To: Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Hi Andrej, Thanks for your concerns and comments. Yes the duplicated code is not a bug, but nevertheless an overhead, when it is preventable. Also agree that lambdas cannot solve all the problems, but in this case, they lend to a nice solution to reduce the duplication of the code. As for the performance considerations, yes it is one extra function call, but with modern JVMs equipped with JIT, and method inlining, either the method is optimized away, or the JIT compiler will certainly optimize the call overhead, for large number of iterations. I havenot done extensive research, but of the little I have done, it seems to indicate that, the cost of lambdas is negligible. Here are some of the links I have read through: 1. https://stackoverflow.com/questions/6495030/java-how-expensive-is-a-method-call - The usual goto place for any questions like this and this had additional pointers, but all the people seemed to agree that the compiler/VM would most likely inline the call. 2. https://www.youtube.com/watch?v=C_QbkGU_lqY - A very good session by Brian Goetz, which explains how lambdas are implemented under the hood, and gives some great insights. Basically, the lambdas I have used in my code are captureless, and that boils down to a constant loading in VM, and invokedynamic is used to call the lambdas. Ofcourse, when we are talking about huge number of iterations, the JIT compiler will kick in and might optimize away the call altogether. 3. https://plumbr.io/blog/performance-blog/how-expensive-is-a-method-call-in-java - Another blog which is trying to assess the cost of a method call over large number of iterations, and in the case when JIT kicked in, the additional time taken was just 205 nano seconds for 1023 additional method invocations. So, for large iterations, JIT is likely to mitigate the cost of extra method calls. Let me know your thoughts on this. Thanks, Krishna. -----Original Message----- From: Andrej Golovnin Sent: Friday, April 6, 2018 3:58 PM To: Krishna Addepalli Cc: Pankaj Bansal ; swing-dev at openjdk.java.net Subject: Re: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Hi all, as a long time user of Swing and as a person who maintains a very huge ( > 3M lines of code) Swing-based application I would like vote against this change. Could you please explain me which bug this change tries to solve? The so called duplicate code is not a bug and lambdas are not the holy grail. Just because lambdas exists it does not mean we should change every piece of code to use it. Your change will introduce a performance regression to every application that makes huge use of JLists and fires many events. Best regards, Andrej Golovnin On Fri, Apr 6, 2018 at 11:59 AM, Krishna Addepalli wrote: > Hi Pankaj, > > > > Thanks for your review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8201173/webrev01/ > > > > Krishna > > From: Pankaj Bansal > Sent: Friday, April 6, 2018 3:04 PM > To: Krishna Addepalli ; > swing-dev at openjdk.java.net > Subject: RE: [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi Krishna, > > > > The code changes look fine to me. > > Just one suggestion. I think you don?t need to create custom > UpdateFunction functional Interface here. Java has BiConsumer > functional interface, which does what you are trying to do here. > > > > Regards, > > Pankaj Bansal > > > > From: Krishna Addepalli > Sent: Thursday, April 5, 2018 9:09 PM > To: swing-dev at openjdk.java.net > Subject: [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi All, > > Please review a fix for > > JDK-8201173: https://bugs.openjdk.java.net/browse/JDK-8201173 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev00/ > > > > There is the duplication of code in fireContentsChanged, > fireIntervalAdded, fireIntervalRemoved functions, barring an int parameter and a function call. > > Moved the common code into a function called fireUpdates, and defined > a functional interface, so that each function can pass its own lambda > that does the requisite function call. > > > > I have run the tests for JList and JComboBox and observed no new failures. > > > > Thanks, > > Krishna From Sergey.Bylokhov at oracle.com Fri Apr 6 23:08:21 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Apr 2018 16:08:21 -0700 Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo In-Reply-To: <23614819-0fda-4df8-a538-61931fcec4d8@default> References: <23614819-0fda-4df8-a538-61931fcec4d8@default> Message-ID: <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> Hi, Vikrant. I tried to run the new test but it fails on my local system(macos): =============================================== sanity/client/SwingSet/src/GridBagLayoutDemoTest.java Total tests run: 4, Failures: 1, Skips: 0 =============================================== ----------System.err:(16/1069)---------- Error: "Wait "Component reaches location between :java.awt.Point[x=0,y=0]and java.awt.Point[x=0,y=0]" state to be reached (ComponentOperator.WaitStateTimeout)" action has not been produced in 60001 milliseconds java.lang.Exception: failures: 1 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.Exception: failures: 1 JavaTest Message: shutting down test On 03/04/2018 03:10, Vikrant Agarwal wrote: > Hi All, > > Please review this new test for SwingSet GridBagLayoutDemo: > > Webrev: http://cr.openjdk.java.net/~vagarwal/8200605/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200605 > > Summary: This adds an automated test for SwingSet GridBagLayoutDemo for > all the available look and feels. > > We have set up Same Binaries Run to check for stability and this test is > consistently passing for Linux, Mac and Windows for all the look and feels. > > Best Regards, > > Vikrant > -- Best regards, Sergey. From krishna.addepalli at oracle.com Mon Apr 9 07:10:14 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 9 Apr 2018 00:10:14 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) Message-ID: Hi All, Please review a simple fix for enhancement: JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 Currently, there is no way to add a set of items directly to a DefaultListModel and DefaultComboBoxModel classes, other than looping over it and adding one by one. This results in generation of unnecessary events, which mostly are ignored and also slow. Instead, if the api was added to receive a collection of items, then one event would be generated for all the items that get added to the model, While also reducing the boilerplate code on the application side. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Mon Apr 9 07:51:26 2018 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 9 Apr 2018 09:51:26 +0200 Subject: [11] [JDK-8201173] Remove duplicated code in AbstractListModel class In-Reply-To: References: <1a46bc86-2d27-4cfc-b50a-1f4fc43750d0@default> <4adba652-748b-4c4a-9653-5d536f76f556@default> Message-ID: Hi Krishna, > Yes the duplicated code is not a bug, but nevertheless an overhead, when it is preventable. > Also agree that lambdas cannot solve all the problems, but in this case, they lend to a nice solution to reduce the duplication of the code. > > As for the performance considerations, yes it is one extra function call, but with modern JVMs equipped with JIT, and method inlining, either the method is optimized away, or the JIT compiler will certainly optimize the call overhead, for large number of iterations. About what kind of overhead are you talking? The only overhead that I see is following: - you spent time to create an issue, - you spent time to write a patch, - your college spent time to review your change and to write an email for you, - you spent time to change your patch after the review, - I spent time to review your change and to write you an email, - your patch increases the size of the generated class-file for the AbstractListModel class from 2920 to 4205 bytes, - at runtime the LambdaMetafactory will generate 3 objects for the lambdas in your patch, - you have added 3 extra function calls and not one: 1. a call to the #fireUpdates-method 2. a call to the #accept-method of the functional interface 3. a call to a synthetical method generated for a lambda. And now look at your patch and do simple math: Summary of changes: 60 lines changed: 25 ins; 27 del; 8 mod; 193 unchg 27 - 25 = 2. Your patch saves exactly 2 lines of code. All of the overhead above only for 2 lines of code, really? Even when you would leave the import statement for the Swing classes unchanged and remove the comment for the #fireUpdates-method, it would be still not worth to apply your patch to save just 10 lines of really simple code. The code in the AbstractListModel class exists in his current form for decades and does not have any bug and there is no real need to change it. Best regards, Andrej Golovnin PS: FYI, I know all lambda related articles/papers which were produced by the Core, HotSpot and Performance teams and how lambdas are implemented. From andrej.golovnin at gmail.com Mon Apr 9 09:44:34 2018 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 9 Apr 2018 11:44:34 +0200 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: Message-ID: Hi Krishna, > Please review a simple fix for enhancement: > > JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java 195 fireIntervalAdded(this, startIndex, getSize()); It should be: 195 fireIntervalAdded(this, startIndex, getSize() - 1); 221 fireIntervalAdded(this, index, index + c.size()); It should be: 221 fireIntervalAdded(this, index, index + c.size() - 1); src/java.desktop/share/classes/javax/swing/DefaultListModel.java 574 if(c.isEmpty()) { There should be a space after 'if'. Best regards, Andrej Golovnin From krishna.addepalli at oracle.com Mon Apr 9 11:29:45 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 9 Apr 2018 04:29:45 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: Message-ID: <24e2182b-8b9a-432e-9fea-e3670401c903@default> Hi Andrej, Appreciate for the quick review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ Thanks, Krishna -----Original Message----- From: Andrej Golovnin Sent: Monday, April 9, 2018 3:15 PM To: Krishna Addepalli Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) Hi Krishna, > Please review a simple fix for enhancement: > > JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java 195 fireIntervalAdded(this, startIndex, getSize()); It should be: 195 fireIntervalAdded(this, startIndex, getSize() - 1); 221 fireIntervalAdded(this, index, index + c.size()); It should be: 221 fireIntervalAdded(this, index, index + c.size() - 1); src/java.desktop/share/classes/javax/swing/DefaultListModel.java 574 if(c.isEmpty()) { There should be a space after 'if'. Best regards, Andrej Golovnin From martinrb at google.com Mon Apr 9 17:58:55 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Apr 2018 10:58:55 -0700 Subject: RFR: 8201328: SynthParser should use Boolean.parseBoolean Message-ID: Here's a little cleanup suggested by ?????? ??????? 8201328: SynthParser should use Boolean.parseBoolean http://cr.openjdk.java.net/~martin/webrevs/jdk/SynthParser/ https://bugs.openjdk.java.net/browse/JDK-8201328 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Apr 9 23:34:27 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Apr 2018 16:34:27 -0700 Subject: RFR: 8201328: SynthParser should use Boolean.parseBoolean In-Reply-To: References: Message-ID: <20188683-3ac3-4a99-eee0-fedfe307e676@oracle.com> Looks fine. BTW, I am curious can we implement equalsIgnoreCase via || and && instead of conditional operations to speedup it or not. On 09/04/2018 10:58, Martin Buchholz wrote: > Here's a little cleanup suggested by ?????? ??????? > > 8201328: SynthParser should use Boolean.parseBoolean > http://cr.openjdk.java.net/~martin/webrevs/jdk/SynthParser/ > https://bugs.openjdk.java.net/browse/JDK-8201328 > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 10 00:33:56 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Apr 2018 17:33:56 -0700 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <24e2182b-8b9a-432e-9fea-e3670401c903@default> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> Message-ID: Hi, Krishna. Please update the test to catch the difference between v00 and v01. Some comments about javadoc: - "183 *

" is unnecessary - Do not use dots at the end of @param/@return tags - Not sure that the text below is necessary(it is duplicate description of @exception tag): "202 * Throws an IllegalArgumentExceptionif the index was invalid." - It is unclear what this text means: "207 if c doesn't fall in the range of the list." - Specify that the new methods will throw NPE on null - Why in one class you use addElements/addElementsAt names and in another addAll? - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" It is also unclear what exception should be thrown, IllegalArgumentException is a good candidate but other methods in these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? On 09/04/2018 04:29, Krishna Addepalli wrote: > Hi Andrej, > > Appreciate for the quick review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ > > Thanks, > Krishna > > -----Original Message----- > From: Andrej Golovnin > Sent: Monday, April 9, 2018 3:15 PM > To: Krishna Addepalli > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > Hi Krishna, > >> Please review a simple fix for enhancement: >> >> JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 >> >> Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 > > > src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java > > 195 fireIntervalAdded(this, startIndex, getSize()); > > It should be: > > 195 fireIntervalAdded(this, startIndex, getSize() - 1); > > > 221 fireIntervalAdded(this, index, index + c.size()); > > It should be: > > 221 fireIntervalAdded(this, index, index + c.size() - 1); > > > src/java.desktop/share/classes/javax/swing/DefaultListModel.java > > 574 if(c.isEmpty()) { > > There should be a space after 'if'. > > Best regards, > Andrej Golovnin > -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Tue Apr 10 08:32:38 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 10 Apr 2018 01:32:38 -0700 (PDT) Subject: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components In-Reply-To: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com> References: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com> Message-ID: <42a16319-9b11-45b8-b429-46bc90fb0c5c@default> Hi Prasanta, <notifyAction method and needs to be set properly. I think there is nothing wrong in code changes made in awt_component as that only this particular functions treats ALTGr as ALT+CTRL and we are not handling the ALTGr as ALT+CTRL anywhere else. I have run all jtreg and jck tests on Windows for event handling and everything seems to work fine. < From andrej.golovnin at gmail.com Tue Apr 10 08:47:54 2018 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 10 Apr 2018 10:47:54 +0200 Subject: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components In-Reply-To: <42a16319-9b11-45b8-b429-46bc90fb0c5c@default> References: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com> <42a16319-9b11-45b8-b429-46bc90fb0c5c@default> Message-ID: Hi Pankaj, > Webrev: > > http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/ src/java.desktop/windows/native/libawt/windows/awt_Component.cpp 3540 BOOL altIsDown = ((modifiers & java_awt_event_InputEvent_ALT_DOWN_MASK) || 3541 (modifiers & java_awt_event_InputEvent_ALT_DOWN_MASK)); Applying '||' on the same value does not make sense. I think the line 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK': 3541 (modifiers & java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK)); Best regards, Andrej Golovnin From pankaj.b.bansal at oracle.com Tue Apr 10 09:45:05 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 10 Apr 2018 02:45:05 -0700 (PDT) Subject: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components In-Reply-To: References: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com> <42a16319-9b11-45b8-b429-46bc90fb0c5c@default> Message-ID: Hello Andrej, Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out. Webrev: http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/ Regards, Pankaj Bansal -----Original Message----- From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] Sent: Tuesday, April 10, 2018 2:18 PM To: Pankaj Bansal Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components Hi Pankaj, > Webrev: > > http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/ src/java.desktop/windows/native/libawt/windows/awt_Component.cpp 3540 BOOL altIsDown = ((modifiers & java_awt_event_InputEvent_ALT_DOWN_MASK) || 3541 (modifiers & java_awt_event_InputEvent_ALT_DOWN_MASK)); Applying '||' on the same value does not make sense. I think the line 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK': 3541 (modifiers & java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK)); Best regards, Andrej Golovnin From jamesbtobin at gmail.com Tue Apr 10 10:49:50 2018 From: jamesbtobin at gmail.com (James Tobin) Date: Tue, 10 Apr 2018 11:49:50 +0100 Subject: JOB | Permanent Java Developer (New York) Message-ID: Hello, I'm working with an employer that is looking to hire for their New York office a Java developer with an interest in the digital currency market. Consequently I had hoped some members of this mailing list may like to discuss further; off-list. I can be reached using "JamesBTobin (AT) Gmail (DOT) Com". Kind regards, James From pankaj.b.bansal at oracle.com Tue Apr 10 10:57:02 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 10 Apr 2018 03:57:02 -0700 (PDT) Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description Message-ID: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> Hi All, Please review a very simple fix for documentation change enhancement: JDK-8153532: https://bugs.openjdk.java.net/browse/JDK-8153532 Webrev: http://cr.openjdk.java.net/~pbansal/8153532/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8201363 UIManager.setLookAndFeel (String) throws NPE if the className is null. But this is not updated in the API description. Made changes for the same. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Tue Apr 10 11:07:55 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 10 Apr 2018 04:07:55 -0700 (PDT) Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> Message-ID: <27faea83-6d64-4dcf-9ef5-8847af76e13a@default> Hi Pankaj, The change looks fine to me. Thanks, Krishna From: Pankaj Bansal Sent: Tuesday, April 10, 2018 4:27 PM To: swing-dev at openjdk.java.net Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description Hi All, Please review a very simple fix for documentation change enhancement: JDK-8153532: https://bugs.openjdk.java.net/browse/JDK-8153532 Webrev: http://cr.openjdk.java.net/~pbansal/8153532/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8201363 UIManager.setLookAndFeel (String) throws NPE if the className is null. But this is not updated in the API description. Made changes for the same. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Tue Apr 10 12:43:34 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 10 Apr 2018 05:43:34 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> Message-ID: <1b751802-f0cd-44b6-b608-3850f2a37e05@default> Hi Sergey, > Please update the test to catch the difference between v00 and v01. Done. >Some comments about javadoc: > - "183 *

" is unnecessary > - Do not use dots at the end of @param/@return tags Done. > - Not sure that the text below is necessary(it is duplicate description of @exception tag): > "202 * Throws an IllegalArgumentExceptionif the index was invalid." Removed. > - It is unclear what this text means: > "207 if c doesn't fall in the range of the list." > - Specify that the new methods will throw NPE on null Done. > - Why in one class you use addElements/addElementsAt names and in another addAll? In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. To keep with that convention, I named the apis appropriately. > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i > guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" Done. > It is also unclear what exception should be thrown, IllegalArgumentException is a good candidate but other > methods in these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw > "ArrayIndexOutOfBoundsException", any thoughts/suggestions? I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ Thanks, Krishna On 09/04/2018 04:29, Krishna Addepalli wrote: > Hi Andrej, > > Appreciate for the quick review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ > > Thanks, > Krishna > > -----Original Message----- > From: Andrej Golovnin > Sent: Monday, April 9, 2018 3:15 PM > To: Krishna Addepalli > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and > DefaultComboBoxModel should support addAll (Collection c) > > Hi Krishna, > >> Please review a simple fix for enhancement: >> >> JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 >> >> Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 > > > src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java > > 195 fireIntervalAdded(this, startIndex, getSize()); > > It should be: > > 195 fireIntervalAdded(this, startIndex, getSize() - 1); > > > 221 fireIntervalAdded(this, index, index + c.size()); > > It should be: > > 221 fireIntervalAdded(this, index, index + c.size() - 1); > > > src/java.desktop/share/classes/javax/swing/DefaultListModel.java > > 574 if(c.isEmpty()) { > > There should be a space after 'if'. > > Best regards, > Andrej Golovnin > -- Best regards, Sergey. From vikrant.v.agarwal at oracle.com Tue Apr 10 13:23:44 2018 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Tue, 10 Apr 2018 06:23:44 -0700 (PDT) Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo In-Reply-To: <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> References: <23614819-0fda-4df8-a538-61931fcec4d8@default> <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> Message-ID: <4da635b1-9b5a-4cbe-b727-6f759a09bc74@default> Hi Sergey, Thanks for the feedback, this failure was due to a bug in Mac, Component.getLocation() was giving an incorrect/inconsistent initial value when the component is located at (0,0). I have filed a bug for this issue: https://bugs.openjdk.java.net/browse/JDK-8201364 . I have also updated the test to prevent JDK-8201364 from affecting the test. Updated Webrev: http://cr.openjdk.java.net/~vagarwal/8200605/webrev.1/ Why we did not see this in our SBR? I had very recently added this check and this was not sync'd with SBR code. Best Regards, Vikrant -----Original Message----- From: Sergey Bylokhov Sent: Saturday, April 07, 2018 4:38 AM To: Vikrant Agarwal ; swing-dev at openjdk.java.net Cc: Aleksandre Iline Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo Hi, Vikrant. I tried to run the new test but it fails on my local system(macos): =============================================== sanity/client/SwingSet/src/GridBagLayoutDemoTest.java Total tests run: 4, Failures: 1, Skips: 0 =============================================== ----------System.err:(16/1069)---------- Error: "Wait "Component reaches location between :java.awt.Point[x=0,y=0]and java.awt.Point[x=0,y=0]" state to be reached (ComponentOperator.WaitStateTimeout)" action has not been produced in 60001 milliseconds java.lang.Exception: failures: 1 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.Exception: failures: 1 JavaTest Message: shutting down test On 03/04/2018 03:10, Vikrant Agarwal wrote: > Hi All, > > Please review this new test for SwingSet GridBagLayoutDemo: > > Webrev: http://cr.openjdk.java.net/~vagarwal/8200605/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200605 > > Summary: This adds an automated test for SwingSet GridBagLayoutDemo > for all the available look and feels. > > We have set up Same Binaries Run to check for stability and this test > is consistently passing for Linux, Mac and Windows for all the look and feels. > > Best Regards, > > Vikrant > -- Best regards, Sergey. From martinrb at google.com Tue Apr 10 18:19:59 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Apr 2018 11:19:59 -0700 Subject: RFR: 8201328: SynthParser should use Boolean.parseBoolean In-Reply-To: <20188683-3ac3-4a99-eee0-fedfe307e676@oracle.com> References: <20188683-3ac3-4a99-eee0-fedfe307e676@oracle.com> Message-ID: On Mon, Apr 9, 2018 at 4:34 PM, Sergey Bylokhov wrote: > Looks fine. > BTW, I am curious can we implement equalsIgnoreCase via || and && instead > of conditional operations to speedup it or not. > Probably not worth too much effort optimizing. Hopefully we're not calling parseBoolean in a tight loop. > On 09/04/2018 10:58, Martin Buchholz wrote: > >> Here's a little cleanup suggested by ?????? ??????? >> >> 8201328: SynthParser should use Boolean.parseBoolean >> http://cr.openjdk.java.net/~martin/webrevs/jdk/SynthParser/ >> https://bugs.openjdk.java.net/browse/JDK-8201328 >> >> > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Apr 10 21:46:20 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Apr 2018 14:46:20 -0700 Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo In-Reply-To: <4da635b1-9b5a-4cbe-b727-6f759a09bc74@default> References: <23614819-0fda-4df8-a538-61931fcec4d8@default> <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> <4da635b1-9b5a-4cbe-b727-6f759a09bc74@default> Message-ID: Hi, Vikrant. > Thanks for the feedback, this failure was due to a bug in Mac, Component.getLocation() was giving an incorrect/inconsistent initial value when the component is located at (0,0). I have filed a bug for this issue: https://bugs.openjdk.java.net/browse/JDK-8201364 . I have added a comment to this bug, please take a look. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 10 22:03:20 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Apr 2018 15:03:20 -0700 Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> Message-ID: Hi, Pankaj. Can you please check other methods in this class since we update it anyway. For example "setInstalledLookAndFeels" has @throws NPE but "installLookAndFeel" has not. The test to prove that, is welcome as well. On 10/04/2018 03:57, Pankaj Bansal wrote: > Hi All, > > Please review a very simple fix for documentation change enhancement: > > JDK-8153532: https://bugs.openjdk.java.net/browse/JDK-8153532 > > Webrev: http://cr.openjdk.java.net/~pbansal/8153532/webrev.00/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8201363 > > UIManager.setLookAndFeel (String) throws NPE if the className is null. > But this is not updated in the API description. Made changes for the same. > > Regards, > > Pankaj Bansal > -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Wed Apr 11 09:55:22 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Wed, 11 Apr 2018 02:55:22 -0700 (PDT) Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> Message-ID: <8a3b92e1-a80f-49ff-97ca-ea0ff50a331e@default> Hi Sergey, Thanks for the review. < [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description Hi, Pankaj. Can you please check other methods in this class since we update it anyway. For example "setInstalledLookAndFeels" has @throws NPE but "installLookAndFeel" has not. The test to prove that, is welcome as well. On 10/04/2018 03:57, Pankaj Bansal wrote: > Hi All, > > Please review a very simple fix for documentation change enhancement: > > JDK-8153532: https://bugs.openjdk.java.net/browse/JDK-8153532 > > Webrev: http://cr.openjdk.java.net/~pbansal/8153532/webrev.00/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8201363 > > UIManager.setLookAndFeel (String) throws NPE if the className is null. > But this is not updated in the API description. Made changes for the same. > > Regards, > > Pankaj Bansal > -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed Apr 11 11:25:32 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 11 Apr 2018 04:25:32 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <1b751802-f0cd-44b6-b608-3850f2a37e05@default> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> Message-ID: Hi All, Here is the modified webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev03/ as per Joe Darcy's suggestion to modify the api to accept a collection object that captures objects of classes that extend type E, in line with underlying Vector API. Thanks, Krishna -----Original Message----- From: Krishna Addepalli Sent: Tuesday, April 10, 2018 6:14 PM To: Sergey Bylokhov ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) Hi Sergey, > Please update the test to catch the difference between v00 and v01. Done. >Some comments about javadoc: > - "183 *

" is unnecessary > - Do not use dots at the end of @param/@return tags Done. > - Not sure that the text below is necessary(it is duplicate description of @exception tag): > "202 * Throws an IllegalArgumentExceptionif the index was invalid." Removed. > - It is unclear what this text means: > "207 if c doesn't fall in the range of the list." > - Specify that the new methods will throw NPE on null Done. > - Why in one class you use addElements/addElementsAt names and in another addAll? In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. To keep with that convention, I named the apis appropriately. > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i > guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" Done. > It is also unclear what exception should be thrown, > IllegalArgumentException is a good candidate but other methods in > these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ Thanks, Krishna On 09/04/2018 04:29, Krishna Addepalli wrote: > Hi Andrej, > > Appreciate for the quick review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ > > Thanks, > Krishna > > -----Original Message----- > From: Andrej Golovnin > Sent: Monday, April 9, 2018 3:15 PM > To: Krishna Addepalli > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and > DefaultComboBoxModel should support addAll (Collection c) > > Hi Krishna, > >> Please review a simple fix for enhancement: >> >> JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 >> >> Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 > > > src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java > > 195 fireIntervalAdded(this, startIndex, getSize()); > > It should be: > > 195 fireIntervalAdded(this, startIndex, getSize() - 1); > > > 221 fireIntervalAdded(this, index, index + c.size()); > > It should be: > > 221 fireIntervalAdded(this, index, index + c.size() - 1); > > > src/java.desktop/share/classes/javax/swing/DefaultListModel.java > > 574 if(c.isEmpty()) { > > There should be a space after 'if'. > > Best regards, > Andrej Golovnin > -- Best regards, Sergey. From philip.race at oracle.com Wed Apr 11 18:02:54 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 11:02:54 -0700 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> Message-ID: Use the syntax {@code c} instead of c everywhere it is applicable. Use @throws instead of @exception. It is preferred these days. http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@exception doesn't -> does not (we should be formal in the docs). > 560 * from the index specified. should become "from the specified index." * @param index the index from which to start adding elements from this reads awkardly .. as we have "from" twice. Can we instead say : |* @param index the position at which to start adding elements Or, maybe even better, borrow the wording from java.util.List's docs on the same named method since they are very similar : | |index| - index at which to insert the first element from the specified collection -phil. On 04/11/2018 04:25 AM, Krishna Addepalli wrote: > Hi All, > > Here is the modified webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev03/ as per Joe Darcy's suggestion to modify the api to accept a collection object that captures objects of classes that extend type E, in line with underlying Vector API. > > Thanks, > Krishna > > -----Original Message----- > From: Krishna Addepalli > Sent: Tuesday, April 10, 2018 6:14 PM > To: Sergey Bylokhov ; Andrej Golovnin > Cc: swing-dev at openjdk.java.net > Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > Hi Sergey, > >> Please update the test to catch the difference between v00 and v01. > Done. > >> Some comments about javadoc: >> - "183 *

" is unnecessary >> - Do not use dots at the end of @param/@return tags > Done. > > > - Not sure that the text below is necessary(it is duplicate description of @exception tag): > > "202 * Throws an IllegalArgumentExceptionif the index was invalid." > Removed. > > > - It is unclear what this text means: > > "207 if c doesn't fall in the range of the list." > > > - Specify that the new methods will throw NPE on null Done. > > > - Why in one class you use addElements/addElementsAt names and in another addAll? > In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. > To keep with that convention, I named the apis appropriately. > > > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i > > guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" > Done. > >> It is also unclear what exception should be thrown, >> IllegalArgumentException is a good candidate but other methods in >> these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? > I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. > > Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ > > Thanks, > Krishna > > On 09/04/2018 04:29, Krishna Addepalli wrote: >> Hi Andrej, >> >> Appreciate for the quick review. Here is the updated webrev: >> http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Andrej Golovnin >> Sent: Monday, April 9, 2018 3:15 PM >> To: Krishna Addepalli >> Cc: swing-dev at openjdk.java.net >> Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and >> DefaultComboBoxModel should support addAll (Collection c) >> >> Hi Krishna, >> >>> Please review a simple fix for enhancement: >>> >>> JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 >>> >>> Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 >> >> src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java >> >> 195 fireIntervalAdded(this, startIndex, getSize()); >> >> It should be: >> >> 195 fireIntervalAdded(this, startIndex, getSize() - 1); >> >> >> 221 fireIntervalAdded(this, index, index + c.size()); >> >> It should be: >> >> 221 fireIntervalAdded(this, index, index + c.size() - 1); >> >> >> src/java.desktop/share/classes/javax/swing/DefaultListModel.java >> >> 574 if(c.isEmpty()) { >> >> There should be a space after 'if'. >> >> Best regards, >> Andrej Golovnin >> > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Wed Apr 11 18:06:08 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 11 Apr 2018 19:06:08 +0100 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> References: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> Message-ID: Thank you, Sergey, for your review. Any other volunteers? Thanks, Alexey On 05/04/2018 23:56, Sergey Bylokhov wrote: > Looks fine. > > On 05/04/2018 15:39, Alexey Ivanov wrote: >> Hello, >> >> Could you please review the fix for jdk11? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8199627 >> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ >> >> >> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] >> >> Java already supports "Per-Monitor v1" mode. This change extends High >> DPI support in Java: in addition to element [2], a new >> element [3] is added to Java launcher manifest. The >> element is recognized by Windows 10 v1607 and above, >> PerMonitorV2 value is supported by Windows 10 v1703 and above. >> >> The most notable change for Java applications is that window title >> bar is scaled correctly when application window moves from one >> monitor to another or the scaling changes. >> >> >> When building, manifest tool generates warning for unknown >> element in manifest. It is because an older Windows >> SDK is used to build JDK which does not know about an element that >> was added later. The build succeeds despite the warning. >> >> >> Thank you in advance. >> >> Regards, >> Alexey >> >> [1] >> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ >> >> >> [2] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware >> >> >> [3] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness >> >> > > From philip.race at oracle.com Wed Apr 11 18:32:12 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 11:32:12 -0700 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: References: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> Message-ID: <7e662873-b007-9fee-a26b-60cfb9584fc4@oracle.com> +1 -phil On 04/11/2018 11:06 AM, Alexey Ivanov wrote: > Thank you, Sergey, for your review. > > Any other volunteers? > > > Thanks, > Alexey > > On 05/04/2018 23:56, Sergey Bylokhov wrote: >> Looks fine. >> >> On 05/04/2018 15:39, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please review the fix for jdk11? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8199627 >>> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ >>> >>> >>> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] >>> >>> Java already supports "Per-Monitor v1" mode. This change extends >>> High DPI support in Java: in addition to element [2], a >>> new element [3] is added to Java launcher manifest. >>> The element is recognized by Windows 10 v1607 and >>> above, PerMonitorV2 value is supported by Windows 10 v1703 and above. >>> >>> The most notable change for Java applications is that window title >>> bar is scaled correctly when application window moves from one >>> monitor to another or the scaling changes. >>> >>> >>> When building, manifest tool generates warning for unknown >>> element in manifest. It is because an older Windows >>> SDK is used to build JDK which does not know about an element that >>> was added later. The build succeeds despite the warning. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey >>> >>> [1] >>> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ >>> >>> >>> [2] >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware >>> >>> >>> [3] >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness >>> >>> >> >> > From philip.race at oracle.com Wed Apr 11 18:38:20 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 11:38:20 -0700 Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: <27faea83-6d64-4dcf-9ef5-8847af76e13a@default> References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> <27faea83-6d64-4dcf-9ef5-8847af76e13a@default> Message-ID: Can we change all occurrences of @exception -> @throws in this method ? In fact this method appears to be the only one in this class to use @exception so it is doubly anomalous. -phil. On 04/10/2018 04:07 AM, Krishna Addepalli wrote: > > Hi Pankaj, > > The change looks fine to me. > > Thanks, > > Krishna > > *From:* Pankaj Bansal > *Sent:* Tuesday, April 10, 2018 4:27 PM > *To:* swing-dev at openjdk.java.net > *Subject:* [11][JDK-8153532] RFR: Add @throws NPE javadoc > to UIManager.setLookAndFeel(String) method description > > Hi All, > > Please review a very simple fix for documentation change enhancement: > > JDK-8153532: https://bugs.openjdk.java.net/browse/JDK-8153532 > > Webrev: http://cr.openjdk.java.net/~pbansal/8153532/webrev.00/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8201363 > > UIManager.setLookAndFeel (String) throws NPE if the className is null. > But this is not updated in the API description. Made changes for the same. > > Regards, > > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Wed Apr 11 19:06:37 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Wed, 11 Apr 2018 12:06:37 -0700 (PDT) Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> <27faea83-6d64-4dcf-9ef5-8847af76e13a@default> Message-ID: <5cd6f7ee-da7f-4564-8527-04e1efb02eab@default> Hi Phil, Thanks for the review. < @throws in this method ? < [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description Can we change all occurrences of @exception -> @throws in this method ? In fact this method appears to be the only one in this class to use @exception so it is doubly anomalous. -phil. On 04/10/2018 04:07 AM, Krishna Addepalli wrote: Hi Pankaj, The change looks fine to me. Thanks, Krishna From: Pankaj Bansal Sent: Tuesday, April 10, 2018 4:27 PM To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description Hi All, Please review a very simple fix for documentation change enhancement: JDK-8153532: https://bugs.openjdk.java.net/browse/JDK-8153532 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/8153532/webrev.00/"http://cr.openjdk.java.net/~pbansal/8153532/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8201363 UIManager.setLookAndFeel (String) throws NPE if the className is null. But this is not updated in the API description. Made changes for the same. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Apr 11 19:34:58 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 12:34:58 -0700 Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: <5cd6f7ee-da7f-4564-8527-04e1efb02eab@default> References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> <27faea83-6d64-4dcf-9ef5-8847af76e13a@default> <5cd6f7ee-da7f-4564-8527-04e1efb02eab@default> Message-ID: +1 (but don't forget to update the CSR and wait for that approval). -phil On 4/11/2018 12:06 PM, Pankaj Bansal wrote: > > Hi Phil, > > Thanks for the review. > > < @throws in this method ? > < @exception > < > Done. > > Webrev: http://cr.openjdk.java.net/~pbansal/8153532/webrev.01/ > > > Regards, > > Pankaj Bansal > > *From:*Phil Race > *Sent:* Thursday, April 12, 2018 12:08 AM > *To:* Krishna Addepalli; Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [11][JDK-8153532] RFR: Add @throws NPE > javadoc to UIManager.setLookAndFeel(String) method description > > Can we change all occurrences of @exception -> @throws in this method ? > In fact this method appears to be the only one in this class to use > @exception > so it is doubly anomalous. > > -phil. > > On 04/10/2018 04:07 AM, Krishna Addepalli wrote: > > Hi Pankaj, > > The change looks fine to me. > > Thanks, > > Krishna > > *From:* Pankaj Bansal > *Sent:* Tuesday, April 10, 2018 4:27 PM > *To:* swing-dev at openjdk.java.net > *Subject:* [11][JDK-8153532] RFR: Add @throws NPE > javadoc to UIManager.setLookAndFeel(String) method description > > Hi All, > > Please review a very simple fix for documentation change enhancement: > > JDK-8153532: https://bugs.openjdk.java.net/browse/JDK-8153532 > > Webrev: http://cr.openjdk.java.net/~pbansal/8153532/webrev.00/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8201363 > > UIManager.setLookAndFeel (String) throws NPE if the className is > null. But this is not updated in the API description. Made changes > for the same. > > Regards, > > Pankaj Bansal > From Sergey.Bylokhov at oracle.com Wed Apr 11 22:48:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Apr 2018 15:48:16 -0700 Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: <8a3b92e1-a80f-49ff-97ca-ea0ff50a331e@default> References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> <8a3b92e1-a80f-49ff-97ca-ea0ff50a331e@default> Message-ID: <9611ff2c-05e3-31d3-5b68-65bbbb2d3b3e@oracle.com> On 11/04/2018 02:55, Pankaj Bansal wrote: > I have checked all the functions and I could not find any other API with wrong description. ok > < I think I won't be able to write a test which fails before the fix and passes afterwards as it is just a documentation change. Can you please tell me what are the requirements from the test and I will try to write one? This test will check that this method works according to its specification. Previously NPE was not specified and implementation of the method could or could not throw NPE on null, so I doubt that any existing tests checks null parameter. -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Thu Apr 12 07:10:39 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 12 Apr 2018 00:10:39 -0700 (PDT) Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: <9611ff2c-05e3-31d3-5b68-65bbbb2d3b3e@oracle.com> References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> <8a3b92e1-a80f-49ff-97ca-ea0ff50a331e@default> <9611ff2c-05e3-31d3-5b68-65bbbb2d3b3e@oracle.com> Message-ID: Hi Sergey, < [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description On 11/04/2018 02:55, Pankaj Bansal wrote: > I have checked all the functions and I could not find any other API with wrong description. ok > < I think I won't be able to write a test which fails before the fix and passes afterwards as it is just a documentation change. Can you please tell me what are the requirements from the test and I will try to write one? This test will check that this method works according to its specification. Previously NPE was not specified and implementation of the method could or could not throw NPE on null, so I doubt that any existing tests checks null parameter. -- Best regards, Sergey. From krishna.addepalli at oracle.com Thu Apr 12 10:46:37 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 12 Apr 2018 03:46:37 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> Message-ID: <3fd76b89-08d5-43ab-a1f1-c28a36c1ace5@default> Hi Phil, Thank you for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev04/? ? Thanks, Krishna ? From: Phil Race Sent: Wednesday, April 11, 2018 11:33 PM To: Krishna Addepalli ; Sergey Bylokhov ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Use the syntax {@code c} instead of c everywhere it is applicable. Use @throws instead of @exception. It is preferred these days. http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@exception doesn't -> does not (we should be formal in the docs). > 560????? * from the index specified. should become "from the specified index." ?* @param index the index from which to start adding elements from this reads awkardly .. as we have "from" twice. Can we instead say : * @param index the position at which to start adding elements ? ? Or, maybe even better, borrow the wording from java.util.List's docs on the same named method since they are very similar : index - index at which to insert the first element from the specified collection -phil. On 04/11/2018 04:25 AM, Krishna Addepalli wrote: Hi All, ? Here is the modified webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev03/? as per Joe Darcy's suggestion to modify the api to accept a collection object that captures objects of classes that extend type E, in line with underlying Vector API. ? Thanks, Krishna ? -----Original Message----- From: Krishna Addepalli Sent: Tuesday, April 10, 2018 6:14 PM To: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Hi Sergey, ? Please update the test to catch the difference between v00 and v01. Done. ? Some comments about javadoc: - "183????? *

" is unnecessary - Do not use dots at the end of @param/@return tags Done. ? > - Not sure that the text below is necessary(it is duplicate description of @exception tag): >????? "202????? * Throws an IllegalArgumentExceptionif the index was invalid." Removed. ? ? > - It is unclear what this text means: ? >??? "207 if c doesn't fall in the range of the list." ? ? >? - Specify that the new methods will throw NPE on null Done. ? ? > - Why in one class you use addElements/addElementsAt names and in another addAll? In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. To keep with that convention, I named the apis appropriately. ? ? > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i?????????????? ??> guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" Done. ? It is also unclear what exception should be thrown, IllegalArgumentException is a good candidate but other methods in these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. ? Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ ? Thanks, Krishna ? On 09/04/2018 04:29, Krishna Addepalli wrote: Hi Andrej, ? Appreciate for the? quick review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ ? Thanks, Krishna ? -----Original Message----- From: Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Sent: Monday, April 9, 2018 3:15 PM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Hi Krishna, ? Please review a simple fix for enhancement: ? JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 ? Webrev: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 ? ? src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java ? 195???????? fireIntervalAdded(this, startIndex, getSize()); ? It should be: ? 195???????? fireIntervalAdded(this, startIndex, getSize() - 1); ? ? 221???????? fireIntervalAdded(this, index, index + c.size()); ? It should be: ? 221???????? fireIntervalAdded(this, index, index + c.size() - 1); ? ? src/java.desktop/share/classes/javax/swing/DefaultListModel.java ? 574???????? if(c.isEmpty()) { ? There should be a space after 'if'. ? Best regards, Andrej Golovnin ? ? ? -- Best regards, Sergey. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Apr 12 17:22:52 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 12 Apr 2018 10:22:52 -0700 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <3fd76b89-08d5-43ab-a1f1-c28a36c1ace5@default> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <3fd76b89-08d5-43ab-a1f1-c28a36c1ace5@default> Message-ID: <65ed6245-f4aa-4360-b14d-c4374c22a902@oracle.com> I was only expecting you to update your new code to use {@code .. } but since you've made the changes they are OK to keep. Just make sure you *exclude* those other changes from the CSR, as they aren't a spec. change and will clutter the CSR more than they are cluttering the webrev. +1 -phil. On 04/12/2018 03:46 AM, Krishna Addepalli wrote: > > Hi Phil, > > Thank you for the review. > > Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev04/ > > > Thanks, > > Krishna > > *From:*Phil Race > *Sent:* Wednesday, April 11, 2018 11:33 PM > *To:* Krishna Addepalli ; Sergey > Bylokhov ; Andrej Golovnin > > *Cc:* swing-dev at openjdk.java.net > *Subject:* Re: [11][JDK-4842658] RFR: DefaultListModel and > DefaultComboBoxModel should support addAll (Collection c) > > Use the syntax {@code c} instead of c everywhere > it is applicable. > > Use @throws instead of @exception. > It is preferred these days. > http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@exception > > doesn't -> does not (we should be formal in the docs). > > > 560 * from the index specified. > > should become > > "from the specified index." > > * @param index the index from which to start adding elements from > > this reads awkardly .. as we have "from" twice. Can we instead say : > > * @param index the position at which to start adding elements > Or, maybe even better, borrow the wording from java.util.List's docs > on the same named method since they are very similar : > > |index| - index at which to insert the first element from the > specified collection > > -phil. > > On 04/11/2018 04:25 AM, Krishna Addepalli wrote: > > Hi All, > > Here is the modified webrev:http://cr.openjdk.java.net/~kaddepalli/4842658/webrev03/ > as per Joe Darcy's suggestion to modify the api to accept a collection object that captures objects of classes that extend type E, in line with underlying Vector API. > > Thanks, > > Krishna > > -----Original Message----- > > From: Krishna Addepalli > > Sent: Tuesday, April 10, 2018 6:14 PM > > To: Sergey Bylokhov ; Andrej Golovnin > > Cc:swing-dev at openjdk.java.net > > Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > Hi Sergey, > > Please update the test to catch the difference between v00 and v01. > > Done. > > Some comments about javadoc: > > - "183 *

" is unnecessary > > - Do not use dots at the end of @param/@return tags > > Done. > > > - Not sure that the text below is necessary(it is duplicate description of @exception tag): > > > "202 * Throws an IllegalArgumentExceptionif the index was invalid." > > Removed. > > > - It is unclear what this text means: > > > "207 if c doesn't fall in the range of the list." > > > - Specify that the new methods will throw NPE on null Done. > > > - Why in one class you use addElements/addElementsAt names and in another addAll? > > In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. > > To keep with that convention, I named the apis appropriately. > > > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i > > > guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" > > Done. > > It is also unclear what exception should be thrown, > > IllegalArgumentException is a good candidate but other methods in > > these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? > > I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. > > Here is the updated webrev:http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ > > > Thanks, > > Krishna > > On 09/04/2018 04:29, Krishna Addepalli wrote: > > Hi Andrej, > > Appreciate for the quick review. Here is the updated webrev: > > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ > > > Thanks, > > Krishna > > -----Original Message----- > > From: Andrej Golovnin > > Sent: Monday, April 9, 2018 3:15 PM > > To: Krishna Addepalli > > > Cc:swing-dev at openjdk.java.net > > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and > > DefaultComboBoxModel should support addAll (Collection c) > > Hi Krishna, > > Please review a simple fix for enhancement: > > JDK-4842658:https://bugs.openjdk.java.net/browse/JDK-4842658 > > Webrev:http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ > > > CSR:https://bugs.openjdk.java.net/browse/JDK-8201289 > > src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java > > 195 fireIntervalAdded(this, startIndex, getSize()); > > It should be: > > 195 fireIntervalAdded(this, startIndex, getSize() - 1); > > 221 fireIntervalAdded(this, index, index + c.size()); > > It should be: > > 221 fireIntervalAdded(this, index, index + c.size() - 1); > > src/java.desktop/share/classes/javax/swing/DefaultListModel.java > > 574 if(c.isEmpty()) { > > There should be a space after 'if'. > > Best regards, > > Andrej Golovnin > > -- > > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Apr 12 21:28:56 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Apr 2018 14:28:56 -0700 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <1b751802-f0cd-44b6-b608-3850f2a37e05@default> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> Message-ID: <4041123e-9405-4e54-612c-073e316e697c@oracle.com> On 10/04/2018 05:43, Krishna Addepalli wrote: > - Why in one class you use addElements/addElementsAt names and in another addAll? > In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. > To keep with that convention, I named the apis appropriately. DefaultListModel also has getElementAt()/addElement()/removeElement() etc. I can guess this is because it is a wrapper of Vector which has the same methods. But in jdk1.2(when Collection framework was added) some additional methods were added to DefaultListModel like clear()/get()/set()/add() etc. I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? -- Best regards, Sergey. From dipak.kumar at oracle.com Fri Apr 13 05:22:03 2018 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Thu, 12 Apr 2018 22:22:03 -0700 (PDT) Subject: [8u-backport] Review request for 8195095 : Images are not scaled correctly in JEditorPane Message-ID: Hi, Please review the below patch (for JDK 8u-dev backport) - Webrev : http://cr.openjdk.java.net/~dkumar/8195095/8u_backport/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8195095 JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/8d8f74e84ff6 Patch pushed for JDK 11 doesn't apply cleanly to JDK 8, mainly because of the line differences and key 'headful' has been removed from the test file. Related Jtreg tests have been run against the proposed patch and results are fine. Thanks, Dipak -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Fri Apr 13 05:34:18 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 12 Apr 2018 22:34:18 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <4041123e-9405-4e54-612c-073e316e697c@oracle.com> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <4041123e-9405-4e54-612c-073e316e697c@oracle.com> Message-ID: <151b5e58-36d9-49c8-98b4-ec178587a840@default> Hi Sergey, Yes, I saw those methods in DefaultListModel, but it had add method, which is why I have added "addAll" method there. In the case of DefaultComboBoxModel, the add method is "addElement", which is why I chose to rename the plural methods to "addElements", and "addElementsAt". However, I'm ok to change the method names to addAll. Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Friday, April 13, 2018 2:59 AM To: Krishna Addepalli ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) On 10/04/2018 05:43, Krishna Addepalli wrote: > - Why in one class you use addElements/addElementsAt names and in another addAll? > In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. > To keep with that convention, I named the apis appropriately. DefaultListModel also has getElementAt()/addElement()/removeElement() etc. I can guess this is because it is a wrapper of Vector which has the same methods. But in jdk1.2(when Collection framework was added) some additional methods were added to DefaultListModel like clear()/get()/set()/add() etc. I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? -- Best regards, Sergey. From krishna.addepalli at oracle.com Fri Apr 13 05:36:17 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 12 Apr 2018 22:36:17 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <65ed6245-f4aa-4360-b14d-c4374c22a902@oracle.com> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <3fd76b89-08d5-43ab-a1f1-c28a36c1ace5@default> <65ed6245-f4aa-4360-b14d-c4374c22a902@oracle.com> Message-ID: <715df8aa-a17f-43ce-b571-0f9cfdd66364@default> Hi Phil, ? Thank you for the review. Yes, those changes are not updated in the CSR. It only contains information about the new APIs being added. ? @Phil, Sergey ? could you mark the CSR reviewed, so that I can finalize it? ? Thanks, Krishna ? From: Phil Race Sent: Thursday, April 12, 2018 10:53 PM To: Krishna Addepalli ; Sergey Bylokhov ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? I was only expecting you to update your new code to use {@code .. } but since you've made the changes they are OK to keep. Just make sure you *exclude* those other changes from the CSR, as they aren't a spec. change and will clutter the CSR more than they are cluttering the webrev. +1 -phil. ? On 04/12/2018 03:46 AM, Krishna Addepalli wrote: Hi Phil, Thank you for the review. Here is the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev04/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev04/? ? Thanks, Krishna ? From: Phil Race Sent: Wednesday, April 11, 2018 11:33 PM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"; Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Use the syntax {@code c} instead of c everywhere it is applicable. Use @throws instead of @exception. It is preferred these days. http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@exception doesn't -> does not (we should be formal in the docs). > 560????? * from the index specified. should become "from the specified index." ?* @param index the index from which to start adding elements from this reads awkardly .. as we have "from" twice. Can we instead say : * @param index the position at which to start adding elements ? ? Or, maybe even better, borrow the wording from java.util.List's docs on the same named method since they are very similar : index - index at which to insert the first element from the specified collection -phil. On 04/11/2018 04:25 AM, Krishna Addepalli wrote: Hi All, ? Here is the modified webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev03/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev03/? as per Joe Darcy's suggestion to modify the api to accept a collection object that captures objects of classes that extend type E, in line with underlying Vector API. ? Thanks, Krishna ? -----Original Message----- From: Krishna Addepalli Sent: Tuesday, April 10, 2018 6:14 PM To: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Hi Sergey, ? Please update the test to catch the difference between v00 and v01. Done. ? Some comments about javadoc: - "183????? *

" is unnecessary - Do not use dots at the end of @param/@return tags Done. ? > - Not sure that the text below is necessary(it is duplicate description of @exception tag): >????? "202????? * Throws an IllegalArgumentExceptionif the index was invalid." Removed. ? ? > - It is unclear what this text means: ? >??? "207 if c doesn't fall in the range of the list." ? ? >? - Specify that the new methods will throw NPE on null Done. ? ? > - Why in one class you use addElements/addElementsAt names and in another addAll? In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. To keep with that convention, I named the apis appropriately. ? ? > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i?????????????? ??> guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" Done. ? It is also unclear what exception should be thrown, IllegalArgumentException is a good candidate but other methods in these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. ? Here is the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev02/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ ? Thanks, Krishna ? On 09/04/2018 04:29, Krishna Addepalli wrote: Hi Andrej, ? Appreciate for the? quick review. Here is the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev01/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ ? Thanks, Krishna ? -----Original Message----- From: Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Sent: Monday, April 9, 2018 3:15 PM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Hi Krishna, ? Please review a simple fix for enhancement: ? JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev00/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 ? ? src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java ? 195???????? fireIntervalAdded(this, startIndex, getSize()); ? It should be: ? 195???????? fireIntervalAdded(this, startIndex, getSize() - 1); ? ? 221???????? fireIntervalAdded(this, index, index + c.size()); ? It should be: ? 221???????? fireIntervalAdded(this, index, index + c.size() - 1); ? ? src/java.desktop/share/classes/javax/swing/DefaultListModel.java ? 574???????? if(c.isEmpty()) { ? There should be a space after 'if'. ? Best regards, Andrej Golovnin ? ? ? -- Best regards, Sergey. ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Apr 13 18:06:39 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Apr 2018 11:06:39 -0700 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <715df8aa-a17f-43ce-b571-0f9cfdd66364@default> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <3fd76b89-08d5-43ab-a1f1-c28a36c1ace5@default> <65ed6245-f4aa-4360-b14d-c4374c22a902@oracle.com> <715df8aa-a17f-43ce-b571-0f9cfdd66364@default> Message-ID: <01961bf4-3d23-e72a-d1a1-2eae3c24c97a@oracle.com> On 04/12/2018 10:36 PM, Krishna Addepalli wrote: > > Hi Phil, > > Thank you for the review. Yes, those changes are not updated in the > CSR. It only contains information about the new APIs being added. > > @Phil, Sergey ? could you mark the CSR reviewed, so that I can > finalize it? > We first need to settle whether you will update the method names as proposed by Sergey. -phil. > Thanks, > > Krishna > > *From:*Phil Race > *Sent:* Thursday, April 12, 2018 10:53 PM > *To:* Krishna Addepalli ; Sergey > Bylokhov ; Andrej Golovnin > > *Cc:* swing-dev at openjdk.java.net > *Subject:* Re: [11][JDK-4842658] RFR: DefaultListModel and > DefaultComboBoxModel should support addAll (Collection c) > > > I was only expecting you to update your new code to use {@code .. } but > since you've made the changes they are OK to keep. > > Just make sure you *exclude* those other changes from the CSR, as > they aren't a spec. change and will clutter the CSR more than they are > cluttering the webrev. > > +1 > > -phil. > > On 04/12/2018 03:46 AM, Krishna Addepalli wrote: > > Hi Phil, > > Thank you for the review. > > Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev04/ > > > Thanks, > > Krishna > > *From:*Phil Race > *Sent:* Wednesday, April 11, 2018 11:33 PM > *To:* Krishna Addepalli > ; Sergey Bylokhov > ; > Andrej Golovnin > > *Cc:* swing-dev at openjdk.java.net > *Subject:* Re: [11][JDK-4842658] RFR: DefaultListModel > and DefaultComboBoxModel should support addAll (Collection c) > > Use the syntax {@code c} instead of c everywhere > it is applicable. > > Use @throws instead of @exception. > It is preferred these days. > http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@exception > > doesn't -> does not (we should be formal in the docs). > > > 560 * from the index specified. > > should become > > "from the specified index." > > > * @param index the index from which to start adding elements from > > this reads awkardly .. as we have "from" twice. Can we instead say : > > * @param index the position at which to start adding elements > > Or, maybe even better, borrow the wording from java.util.List's docs > > on the same named method since they are very similar : > > |index| - index at which to insert the first element from the > specified collection > > -phil. > > On 04/11/2018 04:25 AM, Krishna Addepalli wrote: > > Hi All, > > > > Here is the modified webrev:http://cr.openjdk.java.net/~kaddepalli/4842658/webrev03/ > as per Joe Darcy's suggestion to modify the api to accept a collection object that captures objects of classes that extend type E, in line with underlying Vector API. > > > > Thanks, > > Krishna > > > > -----Original Message----- > > From: Krishna Addepalli > > Sent: Tuesday, April 10, 2018 6:14 PM > > To: Sergey Bylokhov ; Andrej Golovnin > > Cc:swing-dev at openjdk.java.net > > Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > > > Hi Sergey, > > > > Please update the test to catch the difference between v00 and v01. > > Done. > > > > Some comments about javadoc: > > - "183 *

" is unnecessary > > - Do not use dots at the end of @param/@return tags > > Done. > > > > > - Not sure that the text below is necessary(it is duplicate description of @exception tag): > > > "202 * Throws an IllegalArgumentExceptionif the index was invalid." > > Removed. > > > > > - It is unclear what this text means: > > > "207 if c doesn't fall in the range of the list." > > > > > - Specify that the new methods will throw NPE on null Done. > > > > > - Why in one class you use addElements/addElementsAt names and in another addAll? > > In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. > > To keep with that convention, I named the apis appropriately. > > > > > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i > > > guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" > > Done. > > > > It is also unclear what exception should be thrown, > > IllegalArgumentException is a good candidate but other methods in > > these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? > > I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. > > > > Here is the updated webrev:http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ > > > > > Thanks, > > Krishna > > > > On 09/04/2018 04:29, Krishna Addepalli wrote: > > Hi Andrej, > > > > Appreciate for the quick review. Here is the updated webrev: > > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ > > > > > Thanks, > > Krishna > > > > -----Original Message----- > > From: Andrej Golovnin > > Sent: Monday, April 9, 2018 3:15 PM > > To: Krishna Addepalli > > > Cc:swing-dev at openjdk.java.net > > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and > > DefaultComboBoxModel should support addAll (Collection c) > > > > Hi Krishna, > > > > Please review a simple fix for enhancement: > > > > JDK-4842658:https://bugs.openjdk.java.net/browse/JDK-4842658 > > > > Webrev:http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ > > > > > CSR:https://bugs.openjdk.java.net/browse/JDK-8201289 > > > > > > src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java > > > > 195 fireIntervalAdded(this, startIndex, getSize()); > > > > It should be: > > > > 195 fireIntervalAdded(this, startIndex, getSize() - 1); > > > > > > 221 fireIntervalAdded(this, index, index + c.size()); > > > > It should be: > > > > 221 fireIntervalAdded(this, index, index + c.size() - 1); > > > > > > src/java.desktop/share/classes/javax/swing/DefaultListModel.java > > > > 574 if(c.isEmpty()) { > > > > There should be a space after 'if'. > > > > Best regards, > > Andrej Golovnin > > > > > > > > -- > > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Apr 13 19:59:59 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Apr 2018 12:59:59 -0700 Subject: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description In-Reply-To: References: <036c984e-5eb6-4ce7-a5e4-a5215641ad81@default> <8a3b92e1-a80f-49ff-97ca-ea0ff50a331e@default> <9611ff2c-05e3-31d3-5b68-65bbbb2d3b3e@oracle.com> Message-ID: <6ba73bb8-0867-186f-b515-5bc7357117f1@oracle.com> Looks fine. On 12/04/2018 00:10, Pankaj Bansal wrote: > Hi Sergey, > > < > Done > Webrev : http://cr.openjdk.java.net/~pbansal/8153532/webrev.02/ > > Regards, > Pankaj Bansal > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, April 12, 2018 4:18 AM > To: Pankaj Bansal; swing-dev at openjdk.java.net > Subject: Re: [11][JDK-8153532] RFR: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description > > On 11/04/2018 02:55, Pankaj Bansal wrote: >> I have checked all the functions and I could not find any other API with wrong description. > > ok > >> <> I think I won't be able to write a test which fails before the fix and passes afterwards as it is just a documentation change. Can you please tell me what are the requirements from the test and I will try to write one? > > This test will check that this method works according to its specification. Previously NPE was not specified and implementation of the method could or could not throw NPE on null, so I doubt that any existing tests checks null parameter. > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Mon Apr 16 12:26:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Apr 2018 14:26:52 +0200 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: References: Message-ID: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com> Hi Alexey, Since this patch, I'm getting lots of warnings on Windows: c:/cygwin64/home/magnusi/hg/sandbox/open/src/java.base/windows/native/launcher/java.manifest : manifest authoring warning 81010002: Unrecognized Element "dpiAwareness" in namespace "http://schemas.microsoft.com/SMI/2016/WindowsSettings". Seems this element is not universally recognized. Does it even work as intended? Do you have any suggestion on how to address this issue? /Magnus On 2018-04-06 00:39, Alexey Ivanov wrote: > Hello, > > Could you please review the fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8199627 > webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ > > > Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] > > Java already supports "Per-Monitor v1" mode. This change extends High > DPI support in Java: in addition to element [2], a new > element [3] is added to Java launcher manifest. The > element is recognized by Windows 10 v1607 and above, > PerMonitorV2 value is supported by Windows 10 v1703 and above. > > The most notable change for Java applications is that window title bar > is scaled correctly when application window moves from one monitor to > another or the scaling changes. > > > When building, manifest tool generates warning for unknown > element in manifest. It is because an older Windows SDK > is used to build JDK which does not know about an element that was > added later. The build succeeds despite the warning. > > > Thank you in advance. > > Regards, > Alexey > > [1] > https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ > > > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware > > > [3] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness > > From alexey.ivanov at oracle.com Mon Apr 16 12:49:19 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 16 Apr 2018 13:49:19 +0100 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com> References: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com> Message-ID: Hi Magnus, I haven't found a way to suppress this warning. I tried. There's no way to suppress warnings from mt.exe [1] unfortunately. We're using Visual Studio 2013 to build JDK, the element was added in 2016. Newer versions of Windows SDK should recognise the element. Yes, it works as intended. It's recognised by Windows 10 v1703 and later and changes High DPI mode. Other versions of Windows are not affected. I should've included build-dev into the review process as it affects build system. Can the output of mt.exe be redirected? If it's successful, then its output gets ignored. Regards, Alexey [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375649(v=vs.85).aspx On 16/04/2018 13:26, Magnus Ihse Bursie wrote: > Hi Alexey, > > Since this patch, I'm getting lots of warnings on Windows: > > c:/cygwin64/home/magnusi/hg/sandbox/open/src/java.base/windows/native/launcher/java.manifest > : manifest authoring warning 81010002: Unrecognized Element > "dpiAwareness" in namespace > "http://schemas.microsoft.com/SMI/2016/WindowsSettings". > > Seems this element is not universally recognized. Does it even work as > intended? > > Do you have any suggestion on how to address this issue? > > /Magnus > > On 2018-04-06 00:39, Alexey Ivanov wrote: >> Hello, >> >> Could you please review the fix for jdk11? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8199627 >> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ >> >> >> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] >> >> >> >> >> When building, manifest tool generates warning for unknown >> element in manifest. It is because an older Windows >> SDK is used to build JDK which does not know about an element that >> was added later. The build succeeds despite the warning. >> >> >> Thank you in advance. >> >> Regards, >> Alexey >> >> [1] >> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ >> [2] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware >> [3] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness > From krishna.addepalli at oracle.com Tue Apr 17 10:02:34 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 17 Apr 2018 03:02:34 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <01961bf4-3d23-e72a-d1a1-2eae3c24c97a@oracle.com> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <3fd76b89-08d5-43ab-a1f1-c28a36c1ace5@default> <65ed6245-f4aa-4360-b14d-c4374c22a902@oracle.com> <715df8aa-a17f-43ce-b571-0f9cfdd66364@default> <01961bf4-3d23-e72a-d1a1-2eae3c24c97a@oracle.com> Message-ID: <9322e0f9-261b-4462-baff-39d759edbe6a@default> Hi Sergey, ? Here is the new webrev with the api names changed to ?addAll? in DefaultComboBoxModel.java: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev05/? ? Thanks, Krishna ? From: Phil Race Sent: Friday, April 13, 2018 11:37 PM To: Krishna Addepalli ; Sergey Bylokhov ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? ? On 04/12/2018 10:36 PM, Krishna Addepalli wrote: Hi Phil, ? Thank you for the review. Yes, those changes are not updated in the CSR. It only contains information about the new APIs being added. ? @Phil, Sergey ? could you mark the CSR reviewed, so that I can finalize it? ? We first need to settle whether you will update the method names as proposed by Sergey. -phil. Thanks, Krishna ? From: Phil Race Sent: Thursday, April 12, 2018 10:53 PM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"; Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? I was only expecting you to update your new code to use {@code .. } but since you've made the changes they are OK to keep. Just make sure you *exclude* those other changes from the CSR, as they aren't a spec. change and will clutter the CSR more than they are cluttering the webrev. +1 -phil. ? On 04/12/2018 03:46 AM, Krishna Addepalli wrote: Hi Phil, Thank you for the review. Here is the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev04/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev04/? ? Thanks, Krishna ? From: Phil Race Sent: Wednesday, April 11, 2018 11:33 PM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"; Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Use the syntax {@code c} instead of c everywhere it is applicable. Use @throws instead of @exception. It is preferred these days. http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@exception doesn't -> does not (we should be formal in the docs). > 560????? * from the index specified. should become "from the specified index." ?* @param index the index from which to start adding elements from this reads awkardly .. as we have "from" twice. Can we instead say : * @param index the position at which to start adding elements ? ? Or, maybe even better, borrow the wording from java.util.List's docs on the same named method since they are very similar : index - index at which to insert the first element from the specified collection -phil. On 04/11/2018 04:25 AM, Krishna Addepalli wrote: Hi All, ? Here is the modified webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev03/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev03/? as per Joe Darcy's suggestion to modify the api to accept a collection object that captures objects of classes that extend type E, in line with underlying Vector API. ? Thanks, Krishna ? -----Original Message----- From: Krishna Addepalli Sent: Tuesday, April 10, 2018 6:14 PM To: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Hi Sergey, ? Please update the test to catch the difference between v00 and v01. Done. ? Some comments about javadoc: - "183????? *

" is unnecessary - Do not use dots at the end of @param/@return tags Done. ? > - Not sure that the text below is necessary(it is duplicate description of @exception tag): >????? "202????? * Throws an IllegalArgumentExceptionif the index was invalid." Removed. ? ? > - It is unclear what this text means: ? >??? "207 if c doesn't fall in the range of the list." ? ? >? - Specify that the new methods will throw NPE on null Done. ? ? > - Why in one class you use addElements/addElementsAt names and in another addAll? In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. To keep with that convention, I named the apis appropriately. ? ? > - In the exception message you use "list" for "DefaultListModel" and "combobox" for DefaultComboBoxModel i?????????????? ??> guess it should be "xxx model". Or you can simplify it to "Index out of range: + index" Done. ? It is also unclear what exception should be thrown, IllegalArgumentException is a good candidate but other methods in these classes like DefaultComboBoxModel.insertElementAt/removeElementAt will throw "ArrayIndexOutOfBoundsException", any thoughts/suggestions? I was also a bit confused about this. Initially I referred to the function above (removeRange) and saw that it was throwing IllegalArgumentException. Now, I have changed the exception to ArrayIndexOutOfBoundsException as you suggested. ? Here is the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev02/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev02/ ? Thanks, Krishna ? On 09/04/2018 04:29, Krishna Addepalli wrote: Hi Andrej, ? Appreciate for the? quick review. Here is the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev01/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev01/ ? Thanks, Krishna ? -----Original Message----- From: Andrej Golovnin HYPERLINK "mailto:andrej.golovnin at gmail.com" Sent: Monday, April 9, 2018 3:15 PM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com" Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) ? Hi Krishna, ? Please review a simple fix for enhancement: ? JDK-4842658: https://bugs.openjdk.java.net/browse/JDK-4842658 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/4842658/webrev00/"http://cr.openjdk.java.net/~kaddepalli/4842658/webrev00/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 ? ? src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java ? 195???????? fireIntervalAdded(this, startIndex, getSize()); ? It should be: ? 195???????? fireIntervalAdded(this, startIndex, getSize() - 1); ? ? 221???????? fireIntervalAdded(this, index, index + c.size()); ? It should be: ? 221???????? fireIntervalAdded(this, index, index + c.size() - 1); ? ? src/java.desktop/share/classes/javax/swing/DefaultListModel.java ? 574???????? if(c.isEmpty()) { ? There should be a space after 'if'. ? Best regards, Andrej Golovnin ? ? ? -- Best regards, Sergey. ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Apr 17 21:50:33 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Apr 2018 14:50:33 -0700 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <151b5e58-36d9-49c8-98b4-ec178587a840@default> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <4041123e-9405-4e54-612c-073e316e697c@oracle.com> <151b5e58-36d9-49c8-98b4-ec178587a840@default> Message-ID: On 12/04/2018 22:34, Krishna Addepalli wrote: > Yes, I saw those methods in DefaultListModel, but it had add method, which is why I have added "addAll" method there. In the case of DefaultComboBoxModel, the add method is "addElement", which is why I chose to rename the plural methods to "addElements", and "addElementsAt". > However, I'm ok to change the method names to addAll. Since these methods do similar thing, and both classes have the same parent AbstractListModel, I suggest to use the same name either addElementsAt or addAll. I think addAll is better, because it is aligned with the common names from Collection framework. > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, April 13, 2018 2:59 AM > To: Krishna Addepalli ; Andrej Golovnin > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > On 10/04/2018 05:43, Krishna Addepalli wrote: >> - Why in one class you use addElements/addElementsAt names and in another addAll? >> In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. >> To keep with that convention, I named the apis appropriately. > > DefaultListModel also has getElementAt()/addElement()/removeElement() > etc. I can guess this is because it is a wrapper of Vector which has the same methods. But in jdk1.2(when Collection framework was added) some additional methods were added to DefaultListModel like > clear()/get()/set()/add() etc. > I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed Apr 18 04:00:57 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 17 Apr 2018 21:00:57 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <4041123e-9405-4e54-612c-073e316e697c@oracle.com> <151b5e58-36d9-49c8-98b4-ec178587a840@default> Message-ID: Hi Sergey, Here is the new webrev with the api names changed to ?addAll? in DefaultComboBoxModel.java: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev05/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, April 18, 2018 3:21 AM To: Krishna Addepalli ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) On 12/04/2018 22:34, Krishna Addepalli wrote: > Yes, I saw those methods in DefaultListModel, but it had add method, which is why I have added "addAll" method there. In the case of DefaultComboBoxModel, the add method is "addElement", which is why I chose to rename the plural methods to "addElements", and "addElementsAt". > However, I'm ok to change the method names to addAll. Since these methods do similar thing, and both classes have the same parent AbstractListModel, I suggest to use the same name either addElementsAt or addAll. I think addAll is better, because it is aligned with the common names from Collection framework. > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, April 13, 2018 2:59 AM > To: Krishna Addepalli ; Andrej Golovnin > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > On 10/04/2018 05:43, Krishna Addepalli wrote: >> - Why in one class you use addElements/addElementsAt names and in another addAll? >> In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. >> To keep with that convention, I named the apis appropriately. > > DefaultListModel also has getElementAt()/addElement()/removeElement() > etc. I can guess this is because it is a wrapper of Vector which has the same methods. But in jdk1.2(when Collection framework was added) some additional methods were added to DefaultListModel like > clear()/get()/set()/add() etc. > I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Apr 19 07:11:24 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 19 Apr 2018 12:41:24 +0530 Subject: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components In-Reply-To: References: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com> <42a16319-9b11-45b8-b429-46bc90fb0c5c@default> Message-ID: Hi Pankaj, looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works? Regards Prasanta On 4/10/2018 3:15 PM, Pankaj Bansal wrote: > Hello Andrej, > > Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out. > Webrev: > http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/ > > > Regards, > Pankaj Bansal > > -----Original Message----- > From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] > Sent: Tuesday, April 10, 2018 2:18 PM > To: Pankaj Bansal > Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components > > Hi Pankaj, > >> Webrev: >> >> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/ > src/java.desktop/windows/native/libawt/windows/awt_Component.cpp > > 3540 BOOL altIsDown = ((modifiers & > java_awt_event_InputEvent_ALT_DOWN_MASK) || > 3541 (modifiers & > java_awt_event_InputEvent_ALT_DOWN_MASK)); > > Applying '||' on the same value does not make sense. I think the line > 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK': > > 3541 (modifiers & > java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK)); > > Best regards, > Andrej Golovnin From abdul.kolarkunnu at oracle.com Fri Apr 20 04:52:51 2018 From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu) Date: Thu, 19 Apr 2018 21:52:51 -0700 (PDT) Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations Message-ID: <476d8480-cb97-4714-9e9f-ad1e27bf63e9@default> Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8202064 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202064/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/ad21d12db156 Regards, Muneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Fri Apr 20 10:18:21 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 20 Apr 2018 10:18:21 +0000 (UTC) Subject: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components In-Reply-To: References: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com> <42a16319-9b11-45b8-b429-46bc90fb0c5c@default> Message-ID: <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default> Hi Prasanta, In case of JMenuItem, there are two ways to add key shortcuts 1. JMenuItem newMenuItem = new JMenuItem("New"); newMenuItem.setMnemonic(KeyEvent.VK_N); In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded. 2. JMenuItem newMenuItem = new JMenuItem("New"); newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N, ActionEvent.ALT_MASK)); In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded in this case. Please let me know what do you think about this. Regards, Pankaj Bansal -----Original Message----- From: Prasanta Sadhukhan Sent: Thursday, April 19, 2018 12:41 PM To: Pankaj Bansal; Andrej Golovnin Cc: Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components Hi Pankaj, looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works? Regards Prasanta On 4/10/2018 3:15 PM, Pankaj Bansal wrote: > Hello Andrej, > > Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out. > Webrev: > http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/ > > > Regards, > Pankaj Bansal > > -----Original Message----- > From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] > Sent: Tuesday, April 10, 2018 2:18 PM > To: Pankaj Bansal > Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: [11] JDK-8194873: right ALT key hotkeys no > longer work in Swing components > > Hi Pankaj, > >> Webrev: >> >> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/ > src/java.desktop/windows/native/libawt/windows/awt_Component.cpp > > 3540 BOOL altIsDown = ((modifiers & > java_awt_event_InputEvent_ALT_DOWN_MASK) || > 3541 (modifiers & > java_awt_event_InputEvent_ALT_DOWN_MASK)); > > Applying '||' on the same value does not make sense. I think the line > 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK': > > 3541 (modifiers & > java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK)); > > Best regards, > Andrej Golovnin From prasanta.sadhukhan at oracle.com Fri Apr 20 11:34:03 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Apr 2018 17:04:03 +0530 Subject: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components In-Reply-To: <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default> References: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com> <42a16319-9b11-45b8-b429-46bc90fb0c5c@default> <31c648fc-9b2c-43ca-91fc-6eea1b0328e8@default> Message-ID: Hi Pankaj, On 4/20/2018 3:48 PM, Pankaj Bansal wrote: > Hi Prasanta, > > In case of JMenuItem, there are two ways to add key shortcuts > > 1. > JMenuItem newMenuItem = new JMenuItem("New"); > newMenuItem.setMnemonic(KeyEvent.VK_N); > In this case, the event is triggered if the N key is pressed. The modifiers are not used in this and pressing only N will work. So ALT or ALT_GRAPH is not required. These shortcut only work if the menu containing the given menu item is expanded. > > 2. > JMenuItem newMenuItem = new JMenuItem("New"); > newMenuItem.setAccelerator(KeyStroke.getKeyStroke( KeyEvent.VK_N, ActionEvent.ALT_MASK)); > In this case we are setting the accelerator key. In this case the key N will work with the modifier passed here. So the user is explicitly telling whether to use ALT, ALT_GRAPH or ALT+ALT+GRAPH. So I think we don?t need to change anything here. The menu containing the menu item does not have to be expanded in this case. But, as far I see in spec, ActionEvent does not have anyway to specify Right ALT mask or ALT_GRAPH_MASK so how the user can tell to use ALT_GRAPH. Regards Prasanta > Please let me know what do you think about this. > > Regards, > Pankaj Bansal > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Thursday, April 19, 2018 12:41 PM > To: Pankaj Bansal; Andrej Golovnin > Cc: Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: [11] JDK-8194873: right ALT key hotkeys no longer work in Swing components > > Hi Pankaj, > > looks good. but it still does not test JMenuItem as I can see. Did you check if you have some menu items inside JMenu and set mnemonic, does Right Alt key works? > > Regards > Prasanta > On 4/10/2018 3:15 PM, Pankaj Bansal wrote: >> Hello Andrej, >> >> Thanks for the quick review. Yes, it does not sense to apply || on same value. It was a typo. Thanks for pointing it out. >> Webrev: >> http://cr.openjdk.java.net/~pbansal/8194873/webrev.02/ >> >> >> Regards, >> Pankaj Bansal >> >> -----Original Message----- >> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] >> Sent: Tuesday, April 10, 2018 2:18 PM >> To: Pankaj Bansal >> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net >> Subject: Re: [11] JDK-8194873: right ALT key hotkeys no >> longer work in Swing components >> >> Hi Pankaj, >> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~pbansal/8194873/webrev.01/ >> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp >> >> 3540 BOOL altIsDown = ((modifiers & >> java_awt_event_InputEvent_ALT_DOWN_MASK) || >> 3541 (modifiers & >> java_awt_event_InputEvent_ALT_DOWN_MASK)); >> >> Applying '||' on the same value does not make sense. I think the line >> 3541 should use 'java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK': >> >> 3541 (modifiers & >> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK)); >> >> Best regards, >> Andrej Golovnin From krishna.addepalli at oracle.com Fri Apr 20 12:24:58 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 20 Apr 2018 05:24:58 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <4041123e-9405-4e54-612c-073e316e697c@oracle.com> <151b5e58-36d9-49c8-98b4-ec178587a840@default> Message-ID: <8d2bc4a2-12c5-42cb-8474-4191edcf2438@default> Hi Sergey, Did you get a chance to review this? Thanks, Krishna -----Original Message----- From: Krishna Addepalli Sent: Wednesday, April 18, 2018 9:31 AM To: Sergey Bylokhov ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) Hi Sergey, Here is the new webrev with the api names changed to ?addAll? in DefaultComboBoxModel.java: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev05/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, April 18, 2018 3:21 AM To: Krishna Addepalli ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) On 12/04/2018 22:34, Krishna Addepalli wrote: > Yes, I saw those methods in DefaultListModel, but it had add method, which is why I have added "addAll" method there. In the case of DefaultComboBoxModel, the add method is "addElement", which is why I chose to rename the plural methods to "addElements", and "addElementsAt". > However, I'm ok to change the method names to addAll. Since these methods do similar thing, and both classes have the same parent AbstractListModel, I suggest to use the same name either addElementsAt or addAll. I think addAll is better, because it is aligned with the common names from Collection framework. > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, April 13, 2018 2:59 AM > To: Krishna Addepalli ; Andrej Golovnin > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > On 10/04/2018 05:43, Krishna Addepalli wrote: >> - Why in one class you use addElements/addElementsAt names and in another addAll? >> In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. >> To keep with that convention, I named the apis appropriately. > > DefaultListModel also has getElementAt()/addElement()/removeElement() > etc. I can guess this is because it is a wrapper of Vector which has the same methods. But in jdk1.2(when Collection framework was added) some additional methods were added to DefaultListModel like > clear()/get()/set()/add() etc. > I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From kevin.rushforth at oracle.com Fri Apr 20 16:43:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Apr 2018 09:43:00 -0700 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> Message-ID: I just noticed that there was in in-progress review for JDK-8189687 on swing-dev [1]. Maybe Prasanta can comment on the state of that review and also review your fix. -- Kevin [1] http://mail.openjdk.java.net/pipermail/swing-dev/2018-March/008462.html On 4/20/2018 9:28 AM, Anton Tarasov wrote: > Hi Kevin, > > Thanks for pointing (I didn't find it). Closed it as duplicate. > > Regards, > Anton. > > On 4/20/2018 7:19 PM, Kevin Rushforth wrote: >> I think the first of these problems is the same as: >> >> https://bugs.openjdk.java.net/browse/JDK-8189687 >> >> Can you please check that and close JDK-8189687 as a duplicate if so? >> >> Thanks. >> >> -- Kevin >> >> >> On 4/20/2018 8:51 AM, Anton Tarasov wrote: >>> Hello! >>> >>> Could you please review the fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 >>> webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 >>> >>> There are two problems: >>> 1) IME candidate window x/y is not scaled. >>> 2) The ancestor window for IME is not the current window when it's >>> "a simple window", but the focus proxy (the owner). >>> >>> Thanks, >>> Anton. >> > From anton.tarasov at jetbrains.com Fri Apr 20 19:23:14 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 20 Apr 2018 22:23:14 +0300 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> Message-ID: Hi Sergey, Prasanta, I'm sorry to interpose, but I've just submitted a fix for this issue: http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013891.html As it seems to more relate to AWT not Swing, I submitted it to awt-dev (I didn't notice you discussion here, but thanks to Kevin who pointed me to) So, let me please comment on the suggested fix. As far as I understand the scaling design in AWT, the boundary b/w the user and device spaces lies on the native side of the AWT peer implementation (talking about the Windows platform). Roughly speaking, every coordinate passed to the native peer belongs to the user space and is converted to the device space (the device with which the peer is currently associated) immediately after. And vice versa, every coordinate passed from the native peer up to java is converted from the device space to the user space just before passing. So, as Sergey said below, Swing/AWT operates coordinates strictly in user space (except for the cases when it comes to raster images may be). In scope of this, the suggested approach? doesn't seem right... So, could you please share your thoughts on it and consider the alternative fix referenced above? Thanks, Anton. On 3/31/2018 4:21 AM, Sergey Bylokhov wrote: > I guess we need to check it again. > We have two coordinate spaces in awt/swing: > ?- User-space which is used by all(most) of our API in awt/swing. It > means that all methods like setSize/setBounds/getLocationOnScreen etc > use this coordinate space. > ?- Device-space which is used by the native system. It is used when we > show something on the screen, when we get some notification from the > OS etc. > > So for the example if we try to set the bounds of the window then we > convert the size from the user-space to device-space. But when we get > some notification from the native system then we will convert > device-space to the user-space. > > In this bug we use wrong location of candidate window. It means that > we lost some conversion. > > So if we start from the first iteration of the fix: > http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java.sdiff.html > > > We calculate the x,y in two places using getTextLocation() and > getLocationOnScreen(). Both functions should return coordinates in the > user-space because both are public API in AWT. If some of these > methods use wrong device space it should be updated(in the place where > we get such coordinates from the native). > > We show the candidate window using openCandidateWindow() method, this > method uses x,y coordinates. In which coordinate system x,y should be? > If it uses device space then we should convert both - results of > getTextLocation() and getLocationOnScreen(). > > > On 28/03/2018 22:02, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> The code flows to JTextComponent.getTextLocation() which does not >> return a scaled rectangle as it uses >> awt_Component.cpp#_GetLocationOnScreen where it is scaled down. Do >> you want me to move the code to JTextComponent.getTextLocation() >> instead? >> >> Regards >> Prasanta >> On 3/28/2018 9:06 PM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> The same question about this code: >>> 281???????? Rectangle r = getReq().getTextLocation(offset); >>> >>> The getReq() returns InputMethodRequests which is implemented by a >>> number of classes, and I think one of them >>> "InputMethodRequestsHandler" returns scaled values from >>> "getTextLocation()" already. >>> Some of these classes may return some stubs which should not be >>> scaled, like in CompositionAreaHandler: >>> // passive client, no composed text, so fake a rectangle >>> return new Rectangle(0, 0, 0, 10); >>> >> >>> >>> On 27/03/2018 22:39, Prasanta Sadhukhan wrote: >>>> Any more comments? >>>> >>>> Regards >>>> Prasanta >>>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote: >>>>> Hi Sergey, >>>>> >>>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote: >>>>>> Hi, Prasanta. >>>>>> Did you check why the "InputMethodContext.getTextLocation()" >>>>>> returns non-scaled rectangle? Maybe we should do this inside >>>>>> InputMethodContext()? >>>>>> >>>>> Yes, this code >>>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 >>>>> >>>>> scales down x,y as part of JDK-8073320 fix. >>>>> I have moved the fix to InputMethodContext as suggested >>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/ >>>>> >>>>> Regards >>>>> Prasanta >>>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote: >>>>>>> Hi Krishna, >>>>>>> >>>>>>> Yes, I did not provide any since the testcase needs to be manual >>>>>>> and would have to contain lots of instructions of how to install >>>>>>> Japanese language and changing the input mode to hiragana >>>>>>> and also similar fix of input method earlier did not have a >>>>>>> testcase for similar reason. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote: >>>>>>>> >>>>>>>> Hi Prasanta, >>>>>>>> >>>>>>>> Now the changes look fine. However, I noticed that there is no >>>>>>>> testcase associated with this fix. Is that intentional? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Krishna >>>>>>>> >>>>>>>> *From:*Prasanta Sadhukhan >>>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM >>>>>>>> *To:* Krishna Addepalli ; >>>>>>>> swing-dev at openjdk.java.net >>>>>>>> *Subject:* Re: [11] RFR JDK-8189687:Swing: Invalid >>>>>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows >>>>>>>> >>>>>>>> Thanks Krishna for your comment. Modified webrev catering to >>>>>>>> retrieval of scalefactor of the active monitor being shown >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> >>>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote: >>>>>>>> >>>>>>>> ??? Hi Prasanta, >>>>>>>> >>>>>>>> ??? I have couple questions regarding your fix: >>>>>>>> >>>>>>>> ??? 1.The AffineTransform object should be retrieved from the >>>>>>>> Screen >>>>>>>> ??? on which the window is showing, whereas in your fix, you are >>>>>>>> ??? directly getting it from the default screen. In multi screen >>>>>>>> ??? environment, it may not be aligned correctly. >>>>>>>> >>>>>>>> ??? 2.Is there any reason to retrieve the object in the top. I >>>>>>>> mean, >>>>>>>> ??? the AffineTransform object can be declared inside the ?if >>>>>>>> ??? (haveActiveClient())? block, at the point of use. >>>>>>>> >>>>>>>> ??? Thanks, >>>>>>>> >>>>>>>> ??? Krishna >>>>>>>> >>>>>>>> ??? *From:*Prasanta Sadhukhan >>>>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM >>>>>>>> ??? *To:* swing-dev at openjdk.java.net >>>>>>>> >>>>>>>> ??? *Subject:* [11] RFR JDK-8189687:Swing: Invalid >>>>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on >>>>>>>> Windows >>>>>>>> >>>>>>>> ??? Hi All, >>>>>>>> >>>>>>>> ??? Please review a fix for an issue where it is seen that >>>>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when >>>>>>>> we enter >>>>>>>> ??? text using IME popup, the popup is positioned on top of text, >>>>>>>> ??? thereby obscuring it >>>>>>>> ??? as seen in this screenshot. >>>>>>>> >>>>>>>> >>>>>>>> ??? Proposed fix is to apply the scaleFactor on the candidate's >>>>>>>> popup >>>>>>>> ??? positional coordinates x,y to generate proper coordinates >>>>>>>> to show >>>>>>>> ??? this popup >>>>>>>> ??? webrev: >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> ??? The screenshot after the fix is >>>>>>>> >>>>>>>> >>>>>>>> ??? Regards >>>>>>>> ??? Prasanta >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From anton.tarasov at jetbrains.com Fri Apr 20 19:27:55 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 20 Apr 2018 22:27:55 +0300 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> Message-ID: <409995c0-489a-1e49-fa18-cd597d19632a@jetbrains.com> Thanks, Kevin, I replied to the ongoing review (sorry for missing it). Anton. On 4/20/2018 7:43 PM, Kevin Rushforth wrote: > I just noticed that there was in in-progress review for JDK-8189687 on > swing-dev [1]. Maybe Prasanta can comment on the state of that review > and also review your fix. > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/swing-dev/2018-March/008462.html > > > On 4/20/2018 9:28 AM, Anton Tarasov wrote: >> Hi Kevin, >> >> Thanks for pointing (I didn't find it). Closed it as duplicate. >> >> Regards, >> Anton. >> >> On 4/20/2018 7:19 PM, Kevin Rushforth wrote: >>> I think the first of these problems is the same as: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8189687 >>> >>> Can you please check that and close JDK-8189687 as a duplicate if so? >>> >>> Thanks. >>> >>> -- Kevin >>> >>> >>> On 4/20/2018 8:51 AM, Anton Tarasov wrote: >>>> Hello! >>>> >>>> Could you please review the fix: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 >>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 >>>> >>>> There are two problems: >>>> 1) IME candidate window x/y is not scaled. >>>> 2) The ancestor window for IME is not the current window when it's >>>> "a simple window", but the focus proxy (the owner). >>>> >>>> Thanks, >>>> Anton. >>> >> > From dipak.kumar at oracle.com Mon Apr 23 04:18:09 2018 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Sun, 22 Apr 2018 21:18:09 -0700 (PDT) Subject: [8u-backport] Review request for 8195095 : Images are not scaled correctly in JEditorPane In-Reply-To: References: Message-ID: <160bba09-b5b7-44e5-bd23-de3d446dc559@default> Just a gentle reminder to review the below patch. Thanks, Dipak From: Dipak Kumar Sent: 13 April 2018 10:52 To: Semyon Sadetsky ; Krishna Addepalli ; Manajit Halder ; swing-dev at openjdk.java.net Subject: [8u-backport] Review request for 8195095 : Images are not scaled correctly in JEditorPane Hi, Please review the below patch (for JDK 8u-dev backport) - Webrev : http://cr.openjdk.java.net/~dkumar/8195095/8u_backport/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8195095 JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/8d8f74e84ff6 Patch pushed for JDK 11 doesn't apply cleanly to JDK 8, mainly because of the line differences and key 'headful' has been removed from the test file. Related Jtreg tests have been run against the proposed patch and results are fine. Thanks, Dipak -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Mon Apr 23 04:40:11 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Sun, 22 Apr 2018 21:40:11 -0700 (PDT) Subject: [8u-backport] Review request for 8195095 : Images are not scaled correctly in JEditorPane In-Reply-To: <160bba09-b5b7-44e5-bd23-de3d446dc559@default> References: <160bba09-b5b7-44e5-bd23-de3d446dc559@default> Message-ID: <16089547-09eb-4b8d-8c59-9e593d9d23f7@default> Looks fine to me. Thanks, Krishna From: Dipak Kumar Sent: Monday, April 23, 2018 9:48 AM To: Semyon Sadetsky ; Krishna Addepalli ; Manajit Halder ; swing-dev at openjdk.java.net Subject: RE: [8u-backport] Review request for 8195095 : Images are not scaled correctly in JEditorPane Just a gentle reminder to review the below patch. Thanks, Dipak From: Dipak Kumar Sent: 13 April 2018 10:52 To: Semyon Sadetsky ; Krishna Addepalli ; Manajit Halder ; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: [8u-backport] Review request for 8195095 : Images are not scaled correctly in JEditorPane Hi, Please review the below patch (for JDK 8u-dev backport) - Webrev : http://cr.openjdk.java.net/~dkumar/8195095/8u_backport/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8195095 JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/8d8f74e84ff6 Patch pushed for JDK 11 doesn't apply cleanly to JDK 8, mainly because of the line differences and key 'headful' has been removed from the test file. Related Jtreg tests have been run against the proposed patch and results are fine. Thanks, Dipak -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Apr 23 05:47:25 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 23 Apr 2018 11:17:25 +0530 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> Message-ID: <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> Hi Anton, This fix looks ok? to me. Probably, you should consider naming the variable at the top as some old compiler may give warning and make the build fail. Regards Prasanta On 4/21/2018 12:53 AM, Anton Tarasov wrote: > Hi Sergey, Prasanta, > > I'm sorry to interpose, but I've just submitted a fix for this issue: > http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013891.html > As it seems to more relate to AWT not Swing, I submitted it to awt-dev > (I didn't notice you discussion here, but thanks to Kevin who pointed > me to) > > So, let me please comment on the suggested fix. As far as I understand > the scaling design in AWT, the boundary b/w the user and device spaces > lies on the native side of the AWT peer implementation (talking about > the Windows platform). Roughly speaking, every coordinate passed to > the native peer belongs to the user space and is converted to the > device space (the device with which the peer is currently associated) > immediately after. And vice versa, every coordinate passed from the > native peer up to java is converted from the device space to the user > space just before passing. So, as Sergey said below, Swing/AWT > operates coordinates strictly in user space (except for the cases when > it comes to raster images may be). In scope of this, the suggested > approach? doesn't seem right... > > So, could you please share your thoughts on it and consider the > alternative fix referenced above? > > Thanks, > Anton. > > > On 3/31/2018 4:21 AM, Sergey Bylokhov wrote: >> I guess we need to check it again. >> We have two coordinate spaces in awt/swing: >> ?- User-space which is used by all(most) of our API in awt/swing. It >> means that all methods like setSize/setBounds/getLocationOnScreen etc >> use this coordinate space. >> ?- Device-space which is used by the native system. It is used when >> we show something on the screen, when we get some notification from >> the OS etc. >> >> So for the example if we try to set the bounds of the window then we >> convert the size from the user-space to device-space. But when we get >> some notification from the native system then we will convert >> device-space to the user-space. >> >> In this bug we use wrong location of candidate window. It means that >> we lost some conversion. >> >> So if we start from the first iteration of the fix: >> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java.sdiff.html >> >> >> We calculate the x,y in two places using getTextLocation() and >> getLocationOnScreen(). Both functions should return coordinates in >> the user-space because both are public API in AWT. If some of these >> methods use wrong device space it should be updated(in the place >> where we get such coordinates from the native). >> >> We show the candidate window using openCandidateWindow() method, this >> method uses x,y coordinates. In which coordinate system x,y should be? >> If it uses device space then we should convert both - results of >> getTextLocation() and getLocationOnScreen(). >> >> >> On 28/03/2018 22:02, Prasanta Sadhukhan wrote: >>> Hi Sergey, >>> >>> The code flows to JTextComponent.getTextLocation() which does not >>> return a scaled rectangle as it uses >>> awt_Component.cpp#_GetLocationOnScreen where it is scaled down. Do >>> you want me to move the code to JTextComponent.getTextLocation() >>> instead? >>> >>> Regards >>> Prasanta >>> On 3/28/2018 9:06 PM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> The same question about this code: >>>> 281???????? Rectangle r = getReq().getTextLocation(offset); >>>> >>>> The getReq() returns InputMethodRequests which is implemented by a >>>> number of classes, and I think one of them >>>> "InputMethodRequestsHandler" returns scaled values from >>>> "getTextLocation()" already. >>>> Some of these classes may return some stubs which should not be >>>> scaled, like in CompositionAreaHandler: >>>> // passive client, no composed text, so fake a rectangle >>>> return new Rectangle(0, 0, 0, 10); >>>> >>> >>>> >>>> On 27/03/2018 22:39, Prasanta Sadhukhan wrote: >>>>> Any more comments? >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote: >>>>>>> Hi, Prasanta. >>>>>>> Did you check why the "InputMethodContext.getTextLocation()" >>>>>>> returns non-scaled rectangle? Maybe we should do this inside >>>>>>> InputMethodContext()? >>>>>>> >>>>>> Yes, this code >>>>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 >>>>>> >>>>>> scales down x,y as part of JDK-8073320 fix. >>>>>> I have moved the fix to InputMethodContext as suggested >>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote: >>>>>>>> Hi Krishna, >>>>>>>> >>>>>>>> Yes, I did not provide any since the testcase needs to be >>>>>>>> manual and would have to contain lots of instructions of how to >>>>>>>> install Japanese language and changing the input mode to hiragana >>>>>>>> and also similar fix of input method earlier did not have a >>>>>>>> testcase for similar reason. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote: >>>>>>>>> >>>>>>>>> Hi Prasanta, >>>>>>>>> >>>>>>>>> Now the changes look fine. However, I noticed that there is no >>>>>>>>> testcase associated with this fix. Is that intentional? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Krishna >>>>>>>>> >>>>>>>>> *From:*Prasanta Sadhukhan >>>>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM >>>>>>>>> *To:* Krishna Addepalli ; >>>>>>>>> swing-dev at openjdk.java.net >>>>>>>>> *Subject:* Re: [11] RFR JDK-8189687:Swing: Invalid >>>>>>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows >>>>>>>>> >>>>>>>>> Thanks Krishna for your comment. Modified webrev catering to >>>>>>>>> retrieval of scalefactor of the active monitor being shown >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote: >>>>>>>>> >>>>>>>>> ??? Hi Prasanta, >>>>>>>>> >>>>>>>>> ??? I have couple questions regarding your fix: >>>>>>>>> >>>>>>>>> ??? 1.The AffineTransform object should be retrieved from the >>>>>>>>> Screen >>>>>>>>> ??? on which the window is showing, whereas in your fix, you are >>>>>>>>> ??? directly getting it from the default screen. In multi screen >>>>>>>>> ??? environment, it may not be aligned correctly. >>>>>>>>> >>>>>>>>> ??? 2.Is there any reason to retrieve the object in the top. I >>>>>>>>> mean, >>>>>>>>> ??? the AffineTransform object can be declared inside the ?if >>>>>>>>> ??? (haveActiveClient())? block, at the point of use. >>>>>>>>> >>>>>>>>> ??? Thanks, >>>>>>>>> >>>>>>>>> ??? Krishna >>>>>>>>> >>>>>>>>> ??? *From:*Prasanta Sadhukhan >>>>>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM >>>>>>>>> ??? *To:* swing-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> ??? *Subject:* [11] RFR JDK-8189687:Swing: Invalid >>>>>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on >>>>>>>>> Windows >>>>>>>>> >>>>>>>>> ??? Hi All, >>>>>>>>> >>>>>>>>> ??? Please review a fix for an issue where it is seen that >>>>>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when >>>>>>>>> we enter >>>>>>>>> ??? text using IME popup, the popup is positioned on top of text, >>>>>>>>> ??? thereby obscuring it >>>>>>>>> ??? as seen in this screenshot. >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? Proposed fix is to apply the scaleFactor on the >>>>>>>>> candidate's popup >>>>>>>>> ??? positional coordinates x,y to generate proper coordinates >>>>>>>>> to show >>>>>>>>> ??? this popup >>>>>>>>> ??? webrev: >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? The screenshot after the fix is >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? Regards >>>>>>>>> ??? Prasanta >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From anton.tarasov at jetbrains.com Mon Apr 23 16:57:47 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Mon, 23 Apr 2018 19:57:47 +0300 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> Message-ID: <4b5db0d2-e57c-2d54-790d-4cd7e29e7f66@jetbrains.com> Hi Prasanta, Thanks for the review. If you meant to declare the variables at the top of the method, then actually there should not be any problem with it as it's allowed in C++ (you can see that awt_Component.cpp contains lots of such declarations). Regards, Anton. On 4/23/2018 8:47 AM, Prasanta Sadhukhan wrote: > Hi Anton, > > This fix looks ok? to me. > Probably, you should consider naming the variable at the top as some > old compiler may give warning and make the build fail. > > Regards > Prasanta > On 4/21/2018 12:53 AM, Anton Tarasov wrote: >> Hi Sergey, Prasanta, >> >> I'm sorry to interpose, but I've just submitted a fix for this issue: >> http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013891.html >> As it seems to more relate to AWT not Swing, I submitted it to >> awt-dev (I didn't notice you discussion here, but thanks to Kevin who >> pointed me to) >> >> So, let me please comment on the suggested fix. As far as I >> understand the scaling design in AWT, the boundary b/w the user and >> device spaces lies on the native side of the AWT peer implementation >> (talking about the Windows platform). Roughly speaking, every >> coordinate passed to the native peer belongs to the user space and is >> converted to the device space (the device with which the peer is >> currently associated) immediately after. And vice versa, every >> coordinate passed from the native peer up to java is converted from >> the device space to the user space just before passing. So, as Sergey >> said below, Swing/AWT operates coordinates strictly in user space >> (except for the cases when it comes to raster images may be). In >> scope of this, the suggested approach? doesn't seem right... >> >> So, could you please share your thoughts on it and consider the >> alternative fix referenced above? >> >> Thanks, >> Anton. >> >> >> On 3/31/2018 4:21 AM, Sergey Bylokhov wrote: >>> I guess we need to check it again. >>> We have two coordinate spaces in awt/swing: >>> ?- User-space which is used by all(most) of our API in awt/swing. It >>> means that all methods like setSize/setBounds/getLocationOnScreen >>> etc use this coordinate space. >>> ?- Device-space which is used by the native system. It is used when >>> we show something on the screen, when we get some notification from >>> the OS etc. >>> >>> So for the example if we try to set the bounds of the window then we >>> convert the size from the user-space to device-space. But when we >>> get some notification from the native system then we will convert >>> device-space to the user-space. >>> >>> In this bug we use wrong location of candidate window. It means that >>> we lost some conversion. >>> >>> So if we start from the first iteration of the fix: >>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java.sdiff.html >>> >>> >>> We calculate the x,y in two places using getTextLocation() and >>> getLocationOnScreen(). Both functions should return coordinates in >>> the user-space because both are public API in AWT. If some of these >>> methods use wrong device space it should be updated(in the place >>> where we get such coordinates from the native). >>> >>> We show the candidate window using openCandidateWindow() method, >>> this method uses x,y coordinates. In which coordinate system x,y >>> should be? >>> If it uses device space then we should convert both - results of >>> getTextLocation() and getLocationOnScreen(). >>> >>> >>> On 28/03/2018 22:02, Prasanta Sadhukhan wrote: >>>> Hi Sergey, >>>> >>>> The code flows to JTextComponent.getTextLocation() which does not >>>> return a scaled rectangle as it uses >>>> awt_Component.cpp#_GetLocationOnScreen where it is scaled down. Do >>>> you want me to move the code to JTextComponent.getTextLocation() >>>> instead? >>>> >>>> Regards >>>> Prasanta >>>> On 3/28/2018 9:06 PM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta. >>>>> The same question about this code: >>>>> 281???????? Rectangle r = getReq().getTextLocation(offset); >>>>> >>>>> The getReq() returns InputMethodRequests which is implemented by a >>>>> number of classes, and I think one of them >>>>> "InputMethodRequestsHandler" returns scaled values from >>>>> "getTextLocation()" already. >>>>> Some of these classes may return some stubs which should not be >>>>> scaled, like in CompositionAreaHandler: >>>>> // passive client, no composed text, so fake a rectangle >>>>> return new Rectangle(0, 0, 0, 10); >>>>> >>>> >>>>> >>>>> On 27/03/2018 22:39, Prasanta Sadhukhan wrote: >>>>>> Any more comments? >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote: >>>>>>>> Hi, Prasanta. >>>>>>>> Did you check why the "InputMethodContext.getTextLocation()" >>>>>>>> returns non-scaled rectangle? Maybe we should do this inside >>>>>>>> InputMethodContext()? >>>>>>>> >>>>>>> Yes, this code >>>>>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 >>>>>>> >>>>>>> scales down x,y as part of JDK-8073320 fix. >>>>>>> I have moved the fix to InputMethodContext as suggested >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote: >>>>>>>>> Hi Krishna, >>>>>>>>> >>>>>>>>> Yes, I did not provide any since the testcase needs to be >>>>>>>>> manual and would have to contain lots of instructions of how >>>>>>>>> to install Japanese language and changing the input mode to >>>>>>>>> hiragana >>>>>>>>> and also similar fix of input method earlier did not have a >>>>>>>>> testcase for similar reason. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote: >>>>>>>>>> >>>>>>>>>> Hi Prasanta, >>>>>>>>>> >>>>>>>>>> Now the changes look fine. However, I noticed that there is >>>>>>>>>> no testcase associated with this fix. Is that intentional? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Krishna >>>>>>>>>> >>>>>>>>>> *From:*Prasanta Sadhukhan >>>>>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM >>>>>>>>>> *To:* Krishna Addepalli ; >>>>>>>>>> swing-dev at openjdk.java.net >>>>>>>>>> *Subject:* Re: [11] RFR JDK-8189687:Swing: >>>>>>>>>> Invalid position of candidate pop-up of InputMethod in Hi-DPI >>>>>>>>>> on Windows >>>>>>>>>> >>>>>>>>>> Thanks Krishna for your comment. Modified webrev catering to >>>>>>>>>> retrieval of scalefactor of the active monitor being shown >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote: >>>>>>>>>> >>>>>>>>>> ??? Hi Prasanta, >>>>>>>>>> >>>>>>>>>> ??? I have couple questions regarding your fix: >>>>>>>>>> >>>>>>>>>> ??? 1.The AffineTransform object should be retrieved from the >>>>>>>>>> Screen >>>>>>>>>> ??? on which the window is showing, whereas in your fix, you are >>>>>>>>>> ??? directly getting it from the default screen. In multi screen >>>>>>>>>> ??? environment, it may not be aligned correctly. >>>>>>>>>> >>>>>>>>>> ??? 2.Is there any reason to retrieve the object in the top. >>>>>>>>>> I mean, >>>>>>>>>> ??? the AffineTransform object can be declared inside the ?if >>>>>>>>>> ??? (haveActiveClient())? block, at the point of use. >>>>>>>>>> >>>>>>>>>> ??? Thanks, >>>>>>>>>> >>>>>>>>>> ??? Krishna >>>>>>>>>> >>>>>>>>>> ??? *From:*Prasanta Sadhukhan >>>>>>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM >>>>>>>>>> ??? *To:* swing-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> ??? *Subject:* [11] RFR JDK-8189687:Swing: Invalid >>>>>>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on >>>>>>>>>> Windows >>>>>>>>>> >>>>>>>>>> ??? Hi All, >>>>>>>>>> >>>>>>>>>> ??? Please review a fix for an issue where it is seen that >>>>>>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when >>>>>>>>>> we enter >>>>>>>>>> ??? text using IME popup, the popup is positioned on top of >>>>>>>>>> text, >>>>>>>>>> ??? thereby obscuring it >>>>>>>>>> ??? as seen in this screenshot. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? Proposed fix is to apply the scaleFactor on the >>>>>>>>>> candidate's popup >>>>>>>>>> ??? positional coordinates x,y to generate proper coordinates >>>>>>>>>> to show >>>>>>>>>> ??? this popup >>>>>>>>>> ??? webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? The screenshot after the fix is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? Regards >>>>>>>>>> ??? Prasanta >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > From Sergey.Bylokhov at oracle.com Tue Apr 24 01:48:03 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Apr 2018 18:48:03 -0700 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> Message-ID: <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> For the record, the fix which is under discussion: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 If I understand it correctly then GetHWnd() was replaced by ImmGetHWnd() to support the focus proxy. But note that ScaleUpX/ScaleUpY will use device where GetHWnd() is located, not a device where ImmGetHWnd() is located. Is it possible that these windows will be located on a different screens -> wrong scale factor will be used? BTW there is a typo: 3888 int sx = ScaleUpX(x) - p.x; 3889 int sy = ScaleUpX(y) - p.y; On 22/04/2018 22:47, Prasanta Sadhukhan wrote: > Hi Anton, > > This fix looks ok? to me. > Probably, you should consider naming the variable at the top as some old > compiler may give warning and make the build fail. > > Regards > Prasanta > On 4/21/2018 12:53 AM, Anton Tarasov wrote: >> Hi Sergey, Prasanta, >> >> I'm sorry to interpose, but I've just submitted a fix for this issue: >> http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013891.html >> As it seems to more relate to AWT not Swing, I submitted it to awt-dev >> (I didn't notice you discussion here, but thanks to Kevin who pointed >> me to) >> >> So, let me please comment on the suggested fix. As far as I understand >> the scaling design in AWT, the boundary b/w the user and device spaces >> lies on the native side of the AWT peer implementation (talking about >> the Windows platform). Roughly speaking, every coordinate passed to >> the native peer belongs to the user space and is converted to the >> device space (the device with which the peer is currently associated) >> immediately after. And vice versa, every coordinate passed from the >> native peer up to java is converted from the device space to the user >> space just before passing. So, as Sergey said below, Swing/AWT >> operates coordinates strictly in user space (except for the cases when >> it comes to raster images may be). In scope of this, the suggested >> approach? doesn't seem right... >> >> So, could you please share your thoughts on it and consider the >> alternative fix referenced above? >> >> Thanks, >> Anton. >> >> >> On 3/31/2018 4:21 AM, Sergey Bylokhov wrote: >>> I guess we need to check it again. >>> We have two coordinate spaces in awt/swing: >>> ?- User-space which is used by all(most) of our API in awt/swing. It >>> means that all methods like setSize/setBounds/getLocationOnScreen etc >>> use this coordinate space. >>> ?- Device-space which is used by the native system. It is used when >>> we show something on the screen, when we get some notification from >>> the OS etc. >>> >>> So for the example if we try to set the bounds of the window then we >>> convert the size from the user-space to device-space. But when we get >>> some notification from the native system then we will convert >>> device-space to the user-space. >>> >>> In this bug we use wrong location of candidate window. It means that >>> we lost some conversion. >>> >>> So if we start from the first iteration of the fix: >>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java.sdiff.html >>> >>> >>> We calculate the x,y in two places using getTextLocation() and >>> getLocationOnScreen(). Both functions should return coordinates in >>> the user-space because both are public API in AWT. If some of these >>> methods use wrong device space it should be updated(in the place >>> where we get such coordinates from the native). >>> >>> We show the candidate window using openCandidateWindow() method, this >>> method uses x,y coordinates. In which coordinate system x,y should be? >>> If it uses device space then we should convert both - results of >>> getTextLocation() and getLocationOnScreen(). >>> >>> >>> On 28/03/2018 22:02, Prasanta Sadhukhan wrote: >>>> Hi Sergey, >>>> >>>> The code flows to JTextComponent.getTextLocation() which does not >>>> return a scaled rectangle as it uses >>>> awt_Component.cpp#_GetLocationOnScreen where it is scaled down. Do >>>> you want me to move the code to JTextComponent.getTextLocation() >>>> instead? >>>> >>>> Regards >>>> Prasanta >>>> On 3/28/2018 9:06 PM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta. >>>>> The same question about this code: >>>>> 281???????? Rectangle r = getReq().getTextLocation(offset); >>>>> >>>>> The getReq() returns InputMethodRequests which is implemented by a >>>>> number of classes, and I think one of them >>>>> "InputMethodRequestsHandler" returns scaled values from >>>>> "getTextLocation()" already. >>>>> Some of these classes may return some stubs which should not be >>>>> scaled, like in CompositionAreaHandler: >>>>> // passive client, no composed text, so fake a rectangle >>>>> return new Rectangle(0, 0, 0, 10); >>>>> >>>> >>>>> >>>>> On 27/03/2018 22:39, Prasanta Sadhukhan wrote: >>>>>> Any more comments? >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote: >>>>>>>> Hi, Prasanta. >>>>>>>> Did you check why the "InputMethodContext.getTextLocation()" >>>>>>>> returns non-scaled rectangle? Maybe we should do this inside >>>>>>>> InputMethodContext()? >>>>>>>> >>>>>>> Yes, this code >>>>>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 >>>>>>> >>>>>>> scales down x,y as part of JDK-8073320 fix. >>>>>>> I have moved the fix to InputMethodContext as suggested >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote: >>>>>>>>> Hi Krishna, >>>>>>>>> >>>>>>>>> Yes, I did not provide any since the testcase needs to be >>>>>>>>> manual and would have to contain lots of instructions of how to >>>>>>>>> install Japanese language and changing the input mode to hiragana >>>>>>>>> and also similar fix of input method earlier did not have a >>>>>>>>> testcase for similar reason. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote: >>>>>>>>>> >>>>>>>>>> Hi Prasanta, >>>>>>>>>> >>>>>>>>>> Now the changes look fine. However, I noticed that there is no >>>>>>>>>> testcase associated with this fix. Is that intentional? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Krishna >>>>>>>>>> >>>>>>>>>> *From:*Prasanta Sadhukhan >>>>>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM >>>>>>>>>> *To:* Krishna Addepalli ; >>>>>>>>>> swing-dev at openjdk.java.net >>>>>>>>>> *Subject:* Re: [11] RFR JDK-8189687:Swing: Invalid >>>>>>>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows >>>>>>>>>> >>>>>>>>>> Thanks Krishna for your comment. Modified webrev catering to >>>>>>>>>> retrieval of scalefactor of the active monitor being shown >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote: >>>>>>>>>> >>>>>>>>>> ??? Hi Prasanta, >>>>>>>>>> >>>>>>>>>> ??? I have couple questions regarding your fix: >>>>>>>>>> >>>>>>>>>> ??? 1.The AffineTransform object should be retrieved from the >>>>>>>>>> Screen >>>>>>>>>> ??? on which the window is showing, whereas in your fix, you are >>>>>>>>>> ??? directly getting it from the default screen. In multi screen >>>>>>>>>> ??? environment, it may not be aligned correctly. >>>>>>>>>> >>>>>>>>>> ??? 2.Is there any reason to retrieve the object in the top. I >>>>>>>>>> mean, >>>>>>>>>> ??? the AffineTransform object can be declared inside the ?if >>>>>>>>>> ??? (haveActiveClient())? block, at the point of use. >>>>>>>>>> >>>>>>>>>> ??? Thanks, >>>>>>>>>> >>>>>>>>>> ??? Krishna >>>>>>>>>> >>>>>>>>>> ??? *From:*Prasanta Sadhukhan >>>>>>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM >>>>>>>>>> ??? *To:* swing-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> ??? *Subject:* [11] RFR JDK-8189687:Swing: Invalid >>>>>>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on >>>>>>>>>> Windows >>>>>>>>>> >>>>>>>>>> ??? Hi All, >>>>>>>>>> >>>>>>>>>> ??? Please review a fix for an issue where it is seen that >>>>>>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when >>>>>>>>>> we enter >>>>>>>>>> ??? text using IME popup, the popup is positioned on top of text, >>>>>>>>>> ??? thereby obscuring it >>>>>>>>>> ??? as seen in this screenshot. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? Proposed fix is to apply the scaleFactor on the >>>>>>>>>> candidate's popup >>>>>>>>>> ??? positional coordinates x,y to generate proper coordinates >>>>>>>>>> to show >>>>>>>>>> ??? this popup >>>>>>>>>> ??? webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? The screenshot after the fix is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? Regards >>>>>>>>>> ??? Prasanta >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > -- Best regards, Sergey. From abdul.kolarkunnu at oracle.com Tue Apr 24 12:40:29 2018 From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu) Date: Tue, 24 Apr 2018 05:40:29 -0700 (PDT) Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations In-Reply-To: <476d8480-cb97-4714-9e9f-ad1e27bf63e9@default> References: <476d8480-cb97-4714-9e9f-ad1e27bf63e9@default> Message-ID: <8e892877-2434-4d7f-9383-a5ab4bf24917@default> Gentle Reminder! Regards, Muneer From: Muneer Kolarkunnu Sent: Friday, April 20, 2018 10:23 AM To: swing-dev at openjdk.java.net Cc: Aleksandre Iline Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8202064 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202064/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/ad21d12db156 Regards, Muneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at jetbrains.com Tue Apr 24 18:07:18 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 24 Apr 2018 21:07:18 +0300 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> Message-ID: Hi Sergey, On 4/24/2018 4:48 AM, Sergey Bylokhov wrote: > For the record, the fix which is under discussion: > http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 > > If I understand it correctly then GetHWnd() was replaced by > ImmGetHWnd() to support the focus proxy. But note that > ScaleUpX/ScaleUpY will use device where GetHWnd() is located, not a > device where ImmGetHWnd() is located. Is it possible that these > windows will be located on a different screens -> wrong scale factor > will be used? The thing is this. Say, we have a simple window and its owner. Then, what we do in java is this: Point pt = textInWindow.getLocationOnScreen(); showCandidateWindow(pt); 'pt' is the coordinate in the global multi-monitor user space (relative to the origin of the main monitor). We construct it on the native side (AwtComponent::_GetLocationOnScreen): RECT rect; ::GetWindowRect(peer->GetHWnd(), &rect); // the owned window location in the global multi-monitor device space x = peer->ScaleDownX(rect.left) y = peer->ScaleDownY(rect.top) where 'peer' is the owned window. Next, we do the following: POINT p = // location of the owner, in the global multi-monitor device space int sx = ScaleUpX(x) - p.x; int sy = ScaleUpY(y) - p.y; Here, ScaleUp(x/y) is the inverse operation of what we did above. As the result we get the owned window location in the global multi-monitor device space. (ScaleUp(x,y) - p) is the same, but relative to the owner. I've checked that it indeed works, placing the owner and the window on different monitors with different scales. However, there's some serious problem in this construct which you may have noticed. It's here: x = peer->ScaleDownX(rect.left); 'rect.left' may span a number of displays, each with different scale. Thus, to get the real ScaleDown, rect.left should be split into parts, corresponding to the displays it crosses. Then a display scale should be applied to each part, and then the sum would be the correct result in the user space. As for now, the result is incorrect. Why it works is just because textInWindow.getLocationOnScreen() is immediately passed back to native, where it is up-scaled the same (incorrect) way. However, in other cases this problem may cause issues. And I have no simple solution for it... > > BTW there is a typo: > 3888???? int sx = ScaleUpX(x) - p.x; > 3889???? int sy = ScaleUpX(y) - p.y; Thanks for the catch, fixed it. http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.1 Regards, Anton. > > > On 22/04/2018 22:47, Prasanta Sadhukhan wrote: >> Hi Anton, >> >> This fix looks ok? to me. >> Probably, you should consider naming the variable at the top as some >> old compiler may give warning and make the build fail. >> >> Regards >> Prasanta >> On 4/21/2018 12:53 AM, Anton Tarasov wrote: >>> Hi Sergey, Prasanta, >>> >>> I'm sorry to interpose, but I've just submitted a fix for this >>> issue: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013891.html >>> As it seems to more relate to AWT not Swing, I submitted it to >>> awt-dev (I didn't notice you discussion here, but thanks to Kevin >>> who pointed me to) >>> >>> So, let me please comment on the suggested fix. As far as I >>> understand the scaling design in AWT, the boundary b/w the user and >>> device spaces lies on the native side of the AWT peer implementation >>> (talking about the Windows platform). Roughly speaking, every >>> coordinate passed to the native peer belongs to the user space and >>> is converted to the device space (the device with which the peer is >>> currently associated) immediately after. And vice versa, every >>> coordinate passed from the native peer up to java is converted from >>> the device space to the user space just before passing. So, as >>> Sergey said below, Swing/AWT operates coordinates strictly in user >>> space (except for the cases when it comes to raster images may be). >>> In scope of this, the suggested approach? doesn't seem right... >>> >>> So, could you please share your thoughts on it and consider the >>> alternative fix referenced above? >>> >>> Thanks, >>> Anton. >>> >>> >>> On 3/31/2018 4:21 AM, Sergey Bylokhov wrote: >>>> I guess we need to check it again. >>>> We have two coordinate spaces in awt/swing: >>>> ?- User-space which is used by all(most) of our API in awt/swing. >>>> It means that all methods like >>>> setSize/setBounds/getLocationOnScreen etc use this coordinate space. >>>> ?- Device-space which is used by the native system. It is used when >>>> we show something on the screen, when we get some notification from >>>> the OS etc. >>>> >>>> So for the example if we try to set the bounds of the window then >>>> we convert the size from the user-space to device-space. But when >>>> we get some notification from the native system then we will >>>> convert device-space to the user-space. >>>> >>>> In this bug we use wrong location of candidate window. It means >>>> that we lost some conversion. >>>> >>>> So if we start from the first iteration of the fix: >>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java.sdiff.html >>>> >>>> >>>> We calculate the x,y in two places using getTextLocation() and >>>> getLocationOnScreen(). Both functions should return coordinates in >>>> the user-space because both are public API in AWT. If some of these >>>> methods use wrong device space it should be updated(in the place >>>> where we get such coordinates from the native). >>>> >>>> We show the candidate window using openCandidateWindow() method, >>>> this method uses x,y coordinates. In which coordinate system x,y >>>> should be? >>>> If it uses device space then we should convert both - results of >>>> getTextLocation() and getLocationOnScreen(). >>>> >>>> >>>> On 28/03/2018 22:02, Prasanta Sadhukhan wrote: >>>>> Hi Sergey, >>>>> >>>>> The code flows to JTextComponent.getTextLocation() which does not >>>>> return a scaled rectangle as it uses >>>>> awt_Component.cpp#_GetLocationOnScreen where it is scaled down. Do >>>>> you want me to move the code to JTextComponent.getTextLocation() >>>>> instead? >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 3/28/2018 9:06 PM, Sergey Bylokhov wrote: >>>>>> Hi, Prasanta. >>>>>> The same question about this code: >>>>>> 281???????? Rectangle r = getReq().getTextLocation(offset); >>>>>> >>>>>> The getReq() returns InputMethodRequests which is implemented by >>>>>> a number of classes, and I think one of them >>>>>> "InputMethodRequestsHandler" returns scaled values from >>>>>> "getTextLocation()" already. >>>>>> Some of these classes may return some stubs which should not be >>>>>> scaled, like in CompositionAreaHandler: >>>>>> // passive client, no composed text, so fake a rectangle >>>>>> return new Rectangle(0, 0, 0, 10); >>>>>> >>>>> >>>>>> >>>>>> On 27/03/2018 22:39, Prasanta Sadhukhan wrote: >>>>>>> Any more comments? >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Prasanta. >>>>>>>>> Did you check why the "InputMethodContext.getTextLocation()" >>>>>>>>> returns non-scaled rectangle? Maybe we should do this inside >>>>>>>>> InputMethodContext()? >>>>>>>>> >>>>>>>> Yes, this code >>>>>>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 >>>>>>>> >>>>>>>> scales down x,y as part of JDK-8073320 fix. >>>>>>>> I have moved the fix to InputMethodContext as suggested >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi Krishna, >>>>>>>>>> >>>>>>>>>> Yes, I did not provide any since the testcase needs to be >>>>>>>>>> manual and would have to contain lots of instructions of how >>>>>>>>>> to install Japanese language and changing the input mode to >>>>>>>>>> hiragana >>>>>>>>>> and also similar fix of input method earlier did not have a >>>>>>>>>> testcase for similar reason. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Prasanta, >>>>>>>>>>> >>>>>>>>>>> Now the changes look fine. However, I noticed that there is >>>>>>>>>>> no testcase associated with this fix. Is that intentional? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Krishna >>>>>>>>>>> >>>>>>>>>>> *From:*Prasanta Sadhukhan >>>>>>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM >>>>>>>>>>> *To:* Krishna Addepalli ; >>>>>>>>>>> swing-dev at openjdk.java.net >>>>>>>>>>> *Subject:* Re: [11] RFR JDK-8189687:Swing: >>>>>>>>>>> Invalid position of candidate pop-up of InputMethod in >>>>>>>>>>> Hi-DPI on Windows >>>>>>>>>>> >>>>>>>>>>> Thanks Krishna for your comment. Modified webrev catering to >>>>>>>>>>> retrieval of scalefactor of the active monitor being shown >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> >>>>>>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote: >>>>>>>>>>> >>>>>>>>>>> ??? Hi Prasanta, >>>>>>>>>>> >>>>>>>>>>> ??? I have couple questions regarding your fix: >>>>>>>>>>> >>>>>>>>>>> ??? 1.The AffineTransform object should be retrieved from >>>>>>>>>>> the Screen >>>>>>>>>>> ??? on which the window is showing, whereas in your fix, you >>>>>>>>>>> are >>>>>>>>>>> ??? directly getting it from the default screen. In multi >>>>>>>>>>> screen >>>>>>>>>>> ??? environment, it may not be aligned correctly. >>>>>>>>>>> >>>>>>>>>>> ??? 2.Is there any reason to retrieve the object in the top. >>>>>>>>>>> I mean, >>>>>>>>>>> ??? the AffineTransform object can be declared inside the ?if >>>>>>>>>>> ??? (haveActiveClient())? block, at the point of use. >>>>>>>>>>> >>>>>>>>>>> ??? Thanks, >>>>>>>>>>> >>>>>>>>>>> ??? Krishna >>>>>>>>>>> >>>>>>>>>>> ??? *From:*Prasanta Sadhukhan >>>>>>>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM >>>>>>>>>>> ??? *To:* swing-dev at openjdk.java.net >>>>>>>>>>> >>>>>>>>>>> ??? *Subject:* [11] RFR JDK-8189687:Swing: Invalid >>>>>>>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on >>>>>>>>>>> Windows >>>>>>>>>>> >>>>>>>>>>> ??? Hi All, >>>>>>>>>>> >>>>>>>>>>> ??? Please review a fix for an issue where it is seen that >>>>>>>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, >>>>>>>>>>> when we enter >>>>>>>>>>> ??? text using IME popup, the popup is positioned on top of >>>>>>>>>>> text, >>>>>>>>>>> ??? thereby obscuring it >>>>>>>>>>> ??? as seen in this screenshot. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ??? Proposed fix is to apply the scaleFactor on the >>>>>>>>>>> candidate's popup >>>>>>>>>>> ??? positional coordinates x,y to generate proper >>>>>>>>>>> coordinates to show >>>>>>>>>>> ??? this popup >>>>>>>>>>> ??? webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ??? The screenshot after the fix is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ??? Regards >>>>>>>>>>> ??? Prasanta >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > From anton.tarasov at jetbrains.com Tue Apr 24 20:22:23 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 24 Apr 2018 23:22:23 +0300 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> Message-ID: <773252c5-1930-aba2-71ef-889588fba446@jetbrains.com> On 4/24/2018 9:07 PM, Anton Tarasov wrote: > However, there's some serious problem in this construct which you may > have noticed. It's here: > > x = peer->ScaleDownX(rect.left); > > 'rect.left' may span a number of displays, each with different scale. > Thus, to get the real ScaleDown, rect.left should be split into parts, > corresponding to the displays it crosses. > Then a display scale should be applied to each part, and then the sum > would be the correct result in the user space. As for now, the result > is incorrect. > Why it works is just because textInWindow.getLocationOnScreen() is > immediately passed back to native, where it is up-scaled the same > (incorrect) way. > However, in other cases this problem may cause issues. And I have no > simple solution for it... Clarification. The coordinate should not actually be split into displays every time it's scaled up/down. It's enough to calculate its offset in the "terminal" display and scale it accordingly. Then have all the displays already mapped b/w device and user spaces. But the problem is right here. Even in the current implementation, when there are two displays with different scales, their bounds are converted to the user space incorrectly. The conversion is straight-forward - scaleDown(x,y), ScaleDown(w/h). However, in order to keep the layout of the displays in the user space, the origin of a display should be scaled by the scale factor of the adjacent display, not its own. It's not a problem for two displays, however it's a problem for three (or more). Imagine you have three displays with different scales, two are placed in a row and the third is placed underneath b/w the two (by the x-axis). Now, you can scale the origin of the third display by the scale of the first or the second. In either case, the layout in user space will be broken. And if you try to calculate a distance b/w two UI elements, which crosses the displays, it may be incorrect when converted to the device space. Regards, Anton. From Sergey.Bylokhov at oracle.com Tue Apr 24 20:53:28 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Apr 2018 13:53:28 -0700 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: <773252c5-1930-aba2-71ef-889588fba446@jetbrains.com> References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> <773252c5-1930-aba2-71ef-889588fba446@jetbrains.com> Message-ID: <07997941-8bcb-3c37-27a1-3560bada7024@oracle.com> On 24/04/2018 13:22, Anton Tarasov wrote: > Clarification. The coordinate should not actually be split into displays > every time it's scaled up/down. It's enough to calculate its offset in > the "terminal" display and scale it accordingly. Then have all the > displays already mapped b/w device and user spaces. But the problem is > right here. Even in the current implementation, when there are two > displays with different scales, their bounds are converted to the user > space incorrectly. The conversion is straight-forward - scaleDown(x,y), > ScaleDown(w/h). However, in order to keep the layout of the displays in > the user space, the origin of a display should be scaled by the scale > factor of the adjacent display, not its own. I remember that we tried to implement it this way, or even implemented it this way, but changed later. The problem in situation above is occurred if there are a few screens on the left side with different scales and it is unclear which one should be used to scale the x,y of the right screen. Situation became worse if there are some holes between screens, or screens are intersected. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 24 20:55:28 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Apr 2018 13:55:28 -0700 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> Message-ID: >> BTW there is a typo: >> 3888???? int sx = ScaleUpX(x) - p.x; >> 3889???? int sy = ScaleUpX(y) - p.y; > > Thanks for the catch, fixed it. > > http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.1 Looks fine. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 24 22:05:08 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Apr 2018 15:05:08 -0700 Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations In-Reply-To: <8e892877-2434-4d7f-9383-a5ab4bf24917@default> References: <476d8480-cb97-4714-9e9f-ad1e27bf63e9@default> <8e892877-2434-4d7f-9383-a5ab4bf24917@default> Message-ID: <55b884ef-13d2-0120-bc14-0ad1c13a2a08@oracle.com> +1 On 24/04/2018 05:40, Muneer Kolarkunnu wrote: > Gentle Reminder! > > Regards, > > Muneer > > *From:* Muneer Kolarkunnu > *Sent:* Friday, April 20, 2018 10:23 AM > *To:* swing-dev at openjdk.java.net > *Cc:* Aleksandre Iline > *Subject:* [11] RFR [JDK-8202064] Jemmy > JInternalFrameOperator: Add wait for close(), activate(), resize() and > move() operations > > Hi All, > > Please review an enhancement in jemmy: > > Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8202064 > > Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202064/webrev.00/ > > This fix is a copy of fix made in the Jemmy code-tools repository. > > http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/ad21d12db156 > > Regards, > > Muneer > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 24 22:11:46 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Apr 2018 15:11:46 -0700 Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <4041123e-9405-4e54-612c-073e316e697c@oracle.com> <151b5e58-36d9-49c8-98b4-ec178587a840@default> Message-ID: <41fd8f80-a248-55c1-957b-b5df7b4166de@oracle.com> Looks fine. Please update the test as well before the push(it contains 'addAllElements, addAllElementsAt"). On 17/04/2018 21:00, Krishna Addepalli wrote: > Hi Sergey, > > Here is the new webrev with the api names changed to ?addAll? in DefaultComboBoxModel.java: http://cr.openjdk.java.net/~kaddepalli/4842658/webrev05/ > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, April 18, 2018 3:21 AM > To: Krishna Addepalli ; Andrej Golovnin > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) > > On 12/04/2018 22:34, Krishna Addepalli wrote: >> Yes, I saw those methods in DefaultListModel, but it had add method, which is why I have added "addAll" method there. In the case of DefaultComboBoxModel, the add method is "addElement", which is why I chose to rename the plural methods to "addElements", and "addElementsAt". >> However, I'm ok to change the method names to addAll. > > Since these methods do similar thing, and both classes have the same parent AbstractListModel, I suggest to use the same name either addElementsAt or addAll. I think addAll is better, because it is aligned with the common names from Collection framework. > >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Friday, April 13, 2018 2:59 AM >> To: Krishna Addepalli ; Andrej Golovnin >> Cc: swing-dev at openjdk.java.net >> Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) >> >> On 10/04/2018 05:43, Krishna Addepalli wrote: >>> - Why in one class you use addElements/addElementsAt names and in another addAll? >>> In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. >>> To keep with that convention, I named the apis appropriately. >> >> DefaultListModel also has getElementAt()/addElement()/removeElement() >> etc. I can guess this is because it is a wrapper of Vector which has the same methods. But in jdk1.2(when Collection framework was added) some additional methods were added to DefaultListModel like >> clear()/get()/set()/add() etc. >> I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? >> >> >> -- >> Best regards, Sergey. >> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 24 22:13:20 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Apr 2018 15:13:20 -0700 Subject: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable In-Reply-To: References: Message-ID: Any volunteers to review? =) On 12/03/2018 22:27, Sergey Bylokhov wrote: > Hello. > Please review the update of the test for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198342 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8198342/webrev.00 > > This test creates a number of FileSystemView which internally register a > listeners in UIManager, and the test assumes that these listeners will > be removed when FileSystemView will be collected by GC.(The listener > itself is removed by the Cleaner which uses a separate thread). > > The problem is that in the high-loaded systems when the test is executed > in parallel with many other heavyweight tests the cleaner's thread is > not always able to remove the listeners in time and test fails. > > In the fix the umber of FileSystemView in the test is decreased to 1, I > have checked that the test still fail before related bug(JDK-8175968) > was fixed. > > -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed Apr 25 04:34:04 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 24 Apr 2018 21:34:04 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: <41fd8f80-a248-55c1-957b-b5df7b4166de@oracle.com> References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <4041123e-9405-4e54-612c-073e316e697c@oracle.com> <151b5e58-36d9-49c8-98b4-ec178587a840@default> <41fd8f80-a248-55c1-957b-b5df7b4166de@oracle.com> Message-ID: Thanks for the review Sergey, but I have already updated the test appropriately. Also, please approve the CSR. Krishna -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, April 25, 2018 3:42 AM To: Krishna Addepalli ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) Looks fine. Please update the test as well before the push(it contains 'addAllElements, addAllElementsAt"). On 17/04/2018 21:00, Krishna Addepalli wrote: > Hi Sergey, > > Here is the new webrev with the api names changed to ?addAll? in > DefaultComboBoxModel.java: > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev05/ > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, April 18, 2018 3:21 AM > To: Krishna Addepalli ; Andrej Golovnin > > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and > DefaultComboBoxModel should support addAll (Collection c) > > On 12/04/2018 22:34, Krishna Addepalli wrote: >> Yes, I saw those methods in DefaultListModel, but it had add method, which is why I have added "addAll" method there. In the case of DefaultComboBoxModel, the add method is "addElement", which is why I chose to rename the plural methods to "addElements", and "addElementsAt". >> However, I'm ok to change the method names to addAll. > > Since these methods do similar thing, and both classes have the same parent AbstractListModel, I suggest to use the same name either addElementsAt or addAll. I think addAll is better, because it is aligned with the common names from Collection framework. > >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Friday, April 13, 2018 2:59 AM >> To: Krishna Addepalli ; Andrej Golovnin >> >> Cc: swing-dev at openjdk.java.net >> Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and >> DefaultComboBoxModel should support addAll (Collection c) >> >> On 10/04/2018 05:43, Krishna Addepalli wrote: >>> - Why in one class you use addElements/addElementsAt names and in another addAll? >>> In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. >>> To keep with that convention, I named the apis appropriately. >> >> DefaultListModel also has getElementAt()/addElement()/removeElement() >> etc. I can guess this is because it is a wrapper of Vector which has >> the same methods. But in jdk1.2(when Collection framework was added) >> some additional methods were added to DefaultListModel like >> clear()/get()/set()/add() etc. >> I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? >> >> >> -- >> Best regards, Sergey. >> > > -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed Apr 25 04:50:31 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 24 Apr 2018 21:50:31 -0700 (PDT) Subject: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable In-Reply-To: References: Message-ID: <61ad91ed-0747-47a6-9f62-86e77ecd43bc@default> Looks fine to me. -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, April 25, 2018 3:43 AM To: swing-dev at openjdk.java.net Subject: Re: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable Any volunteers to review? =) On 12/03/2018 22:27, Sergey Bylokhov wrote: > Hello. > Please review the update of the test for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198342 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8198342/webrev.00 > > This test creates a number of FileSystemView which internally register > a listeners in UIManager, and the test assumes that these listeners > will be removed when FileSystemView will be collected by GC.(The > listener itself is removed by the Cleaner which uses a separate thread). > > The problem is that in the high-loaded systems when the test is > executed in parallel with many other heavyweight tests the cleaner's > thread is not always able to remove the listeners in time and test fails. > > In the fix the umber of FileSystemView in the test is decreased to 1, > I have checked that the test still fail before related > bug(JDK-8175968) was fixed. > > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Apr 25 05:31:32 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 25 Apr 2018 11:01:32 +0530 Subject: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable In-Reply-To: References: Message-ID: +1 Regards Prasanta On 4/25/2018 3:43 AM, Sergey Bylokhov wrote: > Any volunteers to review? =) > > On 12/03/2018 22:27, Sergey Bylokhov wrote: >> Hello. >> Please review the update of the test for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198342 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8198342/webrev.00 >> >> This test creates a number of FileSystemView which internally >> register a listeners in UIManager, and the test assumes that these >> listeners will be removed when FileSystemView will be collected by >> GC.(The listener itself is removed by the Cleaner which uses a >> separate thread). >> >> The problem is that in the high-loaded systems when the test is >> executed in parallel with many other heavyweight tests the cleaner's >> thread is not always able to remove the listeners in time and test >> fails. >> >> In the fix the umber of FileSystemView in the test is decreased to 1, >> I have checked that the test still fail before related >> bug(JDK-8175968) was fixed. >> >> > > From jayathirth.d.v at oracle.com Wed Apr 25 06:27:27 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 24 Apr 2018 23:27:27 -0700 (PDT) Subject: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable In-Reply-To: References: Message-ID: <1e0a37d2-0d2c-4d1e-8abf-353511626fcd@default> Hi Sergey, I went through the changes done in JDK-8175968 and I can understand why you would have added creation of multiple CustomFileSystemView like stress test scenario. But as you have mentioned in highly loaded systems there can sometimes be problem with CleanerFactory clearing all listeners on time under GC. My observations: 1) Instead of decreasing the number of CustomFileSystemView to 1, can we add some wait after we generate OOM in test case and check for number of listeners later. 2) Also adding jtreg @summary tag would help to understand the basic functionality of test case. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, April 25, 2018 3:43 AM To: swing-dev at openjdk.java.net Subject: Re: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable Any volunteers to review? =) On 12/03/2018 22:27, Sergey Bylokhov wrote: > Hello. > Please review the update of the test for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198342 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8198342/webrev.00 > > This test creates a number of FileSystemView which internally register > a listeners in UIManager, and the test assumes that these listeners > will be removed when FileSystemView will be collected by GC.(The > listener itself is removed by the Cleaner which uses a separate thread). > > The problem is that in the high-loaded systems when the test is > executed in parallel with many other heavyweight tests the cleaner's > thread is not always able to remove the listeners in time and test fails. > > In the fix the umber of FileSystemView in the test is decreased to 1, > I have checked that the test still fail before related > bug(JDK-8175968) was fixed. > > -- Best regards, Sergey. From anton.tarasov at jetbrains.com Wed Apr 25 10:46:27 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Wed, 25 Apr 2018 13:46:27 +0300 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: <07997941-8bcb-3c37-27a1-3560bada7024@oracle.com> References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> <773252c5-1930-aba2-71ef-889588fba446@jetbrains.com> <07997941-8bcb-3c37-27a1-3560bada7024@oracle.com> Message-ID: On 4/24/2018 11:53 PM, Sergey Bylokhov wrote: > > On 24/04/2018 13:22, Anton Tarasov wrote: >> Clarification. The coordinate should not actually be split into >> displays every time it's scaled up/down. It's enough to calculate its >> offset in the "terminal" display and scale it accordingly. Then have >> all the displays already mapped b/w device and user spaces. But the >> problem is right here. Even in the current implementation, when there >> are two displays with different scales, their bounds are converted to >> the user space incorrectly. The conversion is straight-forward - >> scaleDown(x,y), ScaleDown(w/h). However, in order to keep the layout >> of the displays in the user space, the origin of a display should be >> scaled by the scale factor of the adjacent display, not its own. > > I remember that we tried to implement it this way, or even implemented > it this way, but changed later. The problem in situation above is > occurred if there are a few screens on the left side with different > scales and it is unclear which one should be used to scale the x,y of > the right screen. Situation became worse if there are some holes > between screens, or screens are intersected. Well, in theory I'm thinking of the following. Consider introducing a notion of a coordinate with a state: unresolved, resolved. An unresolved coordinate can be resolved only in relationship. Say, an origin of a monitor adjacent to several other monitors with different scales (ambiguous situation mentioned above) is resolved to a fixed value (in user space) in relationship to a particular adjacent monitor. The relationship comes into play when, roughly speaking, you need to calculate a distance b/w two points, belonging to two different monitors. In case of the origin of a monitor, the other point would be the origin of another monitor. Hard to say if it's feasible (and relevant) in the context of Swing/AWT... Regards, Anton. From anton.tarasov at jetbrains.com Wed Apr 25 10:52:29 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Wed, 25 Apr 2018 13:52:29 +0300 Subject: [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com> <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com> <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com> <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com> <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com> <60b4a23a-cfd8-259a-0a68-cc137070d4e7@oracle.com> <5da8449e-7938-5c1a-e5a7-7e39a6d1d0af@oracle.com> Message-ID: On 4/24/2018 11:55 PM, Sergey Bylokhov wrote: >>> BTW there is a typo: >>> 3888???? int sx = ScaleUpX(x) - p.x; >>> 3889???? int sy = ScaleUpX(y) - p.y; >> >> Thanks for the catch, fixed it. >> >> http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.1 > > Looks fine Thanks. As the fix now has two reviewers it can be pushed as 8189687. Prasanta, will you do that or should I push it myself? Regards, Anton. From krishna.addepalli at oracle.com Wed Apr 25 16:24:09 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 25 Apr 2018 09:24:09 -0700 (PDT) Subject: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) In-Reply-To: References: <24e2182b-8b9a-432e-9fea-e3670401c903@default> <1b751802-f0cd-44b6-b608-3850f2a37e05@default> <4041123e-9405-4e54-612c-073e316e697c@oracle.com> <151b5e58-36d9-49c8-98b4-ec178587a840@default> <41fd8f80-a248-55c1-957b-b5df7b4166de@oracle.com> Message-ID: <97f9f115-fad1-4943-ad4d-c6a92f21d926@default> Hi Sergey, Phil Here is the link to CSR: https://bugs.openjdk.java.net/browse/JDK-8201289 I have updated the CSR as per the latest webrev. Thanks, Krishna -----Original Message----- From: Krishna Addepalli Sent: Wednesday, April 25, 2018 10:04 AM To: Sergey Bylokhov ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: RE: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) Thanks for the review Sergey, but I have already updated the test appropriately. Also, please approve the CSR. Krishna -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, April 25, 2018 3:42 AM To: Krishna Addepalli ; Andrej Golovnin Cc: swing-dev at openjdk.java.net Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) Looks fine. Please update the test as well before the push(it contains 'addAllElements, addAllElementsAt"). On 17/04/2018 21:00, Krishna Addepalli wrote: > Hi Sergey, > > Here is the new webrev with the api names changed to ?addAll? in > DefaultComboBoxModel.java: > http://cr.openjdk.java.net/~kaddepalli/4842658/webrev05/ > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, April 18, 2018 3:21 AM > To: Krishna Addepalli ; Andrej Golovnin > > Cc: swing-dev at openjdk.java.net > Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and > DefaultComboBoxModel should support addAll (Collection c) > > On 12/04/2018 22:34, Krishna Addepalli wrote: >> Yes, I saw those methods in DefaultListModel, but it had add method, which is why I have added "addAll" method there. In the case of DefaultComboBoxModel, the add method is "addElement", which is why I chose to rename the plural methods to "addElements", and "addElementsAt". >> However, I'm ok to change the method names to addAll. > > Since these methods do similar thing, and both classes have the same parent AbstractListModel, I suggest to use the same name either addElementsAt or addAll. I think addAll is better, because it is aligned with the common names from Collection framework. > >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Friday, April 13, 2018 2:59 AM >> To: Krishna Addepalli ; Andrej Golovnin >> >> Cc: swing-dev at openjdk.java.net >> Subject: Re: [11][JDK-4842658] RFR: DefaultListModel and >> DefaultComboBoxModel should support addAll (Collection c) >> >> On 10/04/2018 05:43, Krishna Addepalli wrote: >>> - Why in one class you use addElements/addElementsAt names and in another addAll? >>> In the DefaultComboBoxModel, the functions to add a single element are named as addElement, addElementAt. >>> To keep with that convention, I named the apis appropriately. >> >> DefaultListModel also has getElementAt()/addElement()/removeElement() >> etc. I can guess this is because it is a wrapper of Vector which has >> the same methods. But in jdk1.2(when Collection framework was added) >> some additional methods were added to DefaultListModel like >> clear()/get()/set()/add() etc. >> I don't urge to change the existing methods in DefaultComboBoxModel but it would be good to use one common name pattern for models which is used in Collection framework. Any thoughts? >> >> >> -- >> Best regards, Sergey. >> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Apr 26 00:17:43 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Apr 2018 17:17:43 -0700 Subject: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable In-Reply-To: <1e0a37d2-0d2c-4d1e-8abf-353511626fcd@default> References: <1e0a37d2-0d2c-4d1e-8abf-353511626fcd@default> Message-ID: <49e9ac34-b33c-0fa8-53cd-ab4651862014@oracle.com> Hi, Jay. On 24/04/2018 23:27, Jayathirth D V wrote: > I went through the changes done in JDK-8175968 and I can understand why you would have added creation of multiple CustomFileSystemView like stress test scenario. > But as you have mentioned in highly loaded systems there can sometimes be problem with CleanerFactory clearing all listeners on time under GC. Correct. > 1) Instead of decreasing the number of CustomFileSystemView to 1, can we add some wait after we generate OOM in test case and check for number of listeners later. The problem here is that there is no reliable ways to know when all listeners(allocated in 30 seconds) will be cleaned, and how many time we can spent on wait. I tried to generate OOM a few times, or set an additional delay to 5 seconds but it fails time to time(Ofcourse I can change it to 30 seconds and more, but I am not sure that it will be enough for all configurations). I assume in such cases this test was executed on the test systems in parallel with some other heavyweight tests. Since it is enough to check only one instance of FileSystemView to reproduce the bug for which this test was created, I have changed the test this way. > 2) Also adding jtreg @summary tag would help to understand the basic functionality of test case. webrev is updated: http://cr.openjdk.java.net/~serb/8198342/webrev.01 -- Best regards, Sergey. From jayathirth.d.v at oracle.com Thu Apr 26 02:46:35 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 25 Apr 2018 19:46:35 -0700 (PDT) Subject: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable In-Reply-To: <49e9ac34-b33c-0fa8-53cd-ab4651862014@oracle.com> References: <1e0a37d2-0d2c-4d1e-8abf-353511626fcd@default> <49e9ac34-b33c-0fa8-53cd-ab4651862014@oracle.com> Message-ID: Hi Sergey, Thanks for the clarification. Changes are fine. Regards, Jay -----Original Message----- From: Sergey Bylokhov Sent: Thursday, April 26, 2018 5:48 AM To: Jayathirth D V; swing-dev at openjdk.java.net Subject: Re: [11] Review Request: 8198342 Test FileSystemViewListenerLeak.java is unstable Hi, Jay. On 24/04/2018 23:27, Jayathirth D V wrote: > I went through the changes done in JDK-8175968 and I can understand why you would have added creation of multiple CustomFileSystemView like stress test scenario. > But as you have mentioned in highly loaded systems there can sometimes be problem with CleanerFactory clearing all listeners on time under GC. Correct. > 1) Instead of decreasing the number of CustomFileSystemView to 1, can we add some wait after we generate OOM in test case and check for number of listeners later. The problem here is that there is no reliable ways to know when all listeners(allocated in 30 seconds) will be cleaned, and how many time we can spent on wait. I tried to generate OOM a few times, or set an additional delay to 5 seconds but it fails time to time(Ofcourse I can change it to 30 seconds and more, but I am not sure that it will be enough for all configurations). I assume in such cases this test was executed on the test systems in parallel with some other heavyweight tests. Since it is enough to check only one instance of FileSystemView to reproduce the bug for which this test was created, I have changed the test this way. > 2) Also adding jtreg @summary tag would help to understand the basic functionality of test case. webrev is updated: http://cr.openjdk.java.net/~serb/8198342/webrev.01 -- Best regards, Sergey. From manajit.halder at oracle.com Thu Apr 26 11:14:14 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Thu, 26 Apr 2018 16:44:14 +0530 Subject: Swing dev>[11] Review request for JDK-8189253: [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu In-Reply-To: References: <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com> <6724f7b1-94c0-742b-081b-47dde62426b3@oracle.com> <71FF00F4-C636-435F-B192-DFEBFFBE7945@oracle.com> <5e25040d-fc6f-a859-9484-443a7d1b5365@oracle.com> Message-ID: <24CF01B0-96EC-4C8E-BB74-395F42DCE548@oracle.com> Hi Semyon, The drag issue observed by you on Linux is a different issue and it is observed with 8GA build also. Prasanta has updated JBS with his findings. Since the issue is different and not related to my fix I request you provide further comments on my fix: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ Regards, Manajit > On 12-Jan-2018, at 11:04 AM, Manajit Halder wrote: > > Hi Semyon, > > Thank you for the clarification. I will try to fix the problem in the native code. > > Thanks, > Manajit > > >> On 10-Jan-2018, at 9:11 PM, Semyon Sadetsky > wrote: >> >> Hi Manajit, >> >> Not sure what did you mean under valid. The general approach is user may do with the mouse whatever he wants nevertheless UI should not be broken. This is just an indication the issue you are trying to fix may be a generic one. >> >> --Semyon >> >> On 01/10/2018 05:21 AM, Manajit Halder wrote: >>> Hi Semyon, >>> >>> I could reproduce the behaviour on Ubuntu. But I am curious to know whether this particular mouse operation is a valid operation? >>> >>> Thanks, >>> Manajit >>> >>>> On 08-Jan-2018, at 10:06 PM, Semyon Sadetsky > wrote: >>>> >>>> Hi Manajit, >>>> >>>> Still didn't get why are you limited to Mac platform only while you change updates generic code. Why mouse provided by Apple matters here? >>>> --Semyon >>>> >>>> On 01/08/2018 01:40 AM, Manajit Halder wrote: >>>>> Hi Semyon, >>>>> >>>>> I could not reproduce the behaviour on Mac as on Mac this operation is not possible and hence it won?t be a problem on Mac. It is not possible to press the right button or the left button when the other button is already pressed using both Mouse provided by Apple and Track pad. Once the left button is pressed it need to be release to press the right button and vice versa. >>>>> >>>>> Thanks, >>>>> Manajit >>>>> >>>>>> On 05-Jan-2018, at 7:08 AM, Semyon Sadetsky > wrote: >>>>>> >>>>>> Hi Manajit, >>>>>> >>>>>> I could reproduce similar behaviour on Linux when mouse is dragged to another component with the left button pressed and then the right button is immediately pressed. The popup is triggered by the same logic despite it isn't configured for the component. >>>>>> --Semyon >>>>>> >>>>>> On 01/04/2018 10:22 AM, Manajit Halder wrote: >>>>>>> Hi Semyon, >>>>>>> >>>>>>> Fix for issue JDK-8080729 has caused this regression due to changes in method setVisible(boolean visible) in file CPlatformWindow.java >>>>>>> orderWindow is causing the issue here, if we revert to addChildWindow then the issue is not observed but then the fix for issue JDK-8080729 fails. >>>>>>> Before this change the child window used to be added on to the parent as shown below in the commented code. But after the change child window is ordered above the parent. >>>>>>> >>>>>>> Below code causes the regression: >>>>>>> >>>>>>> CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, ownerPtr); >>>>>>> //CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, CWrapper.NSWindow.NSWindowAbove); >>>>>>> >>>>>>> Debugging further I found that if we use orderWindow then the new window is considered as new graphics device in the method notifyReshape in LWWindowPeer.java (the method updateGraphicsDevice() returns true) and is the difference between using orderWindow and addChildWindow. >>>>>>> >>>>>>> Since the option to add child window is between choosing oderWindow and addChildWindow we don?t have any option to do the fix in the Mac OS native code. >>>>>>> >>>>>>> Regards, >>>>>>> Manajit >>>>>>> >>>>>>> >>>>>>>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky > wrote: >>>>>>>> >>>>>>>> Hi Manajit, >>>>>>>> >>>>>>>> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac OS code only. Nevertheless you are suggesting to fix the regression in generic code. This need to be explained somehow. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> On 12/25/2017 02:42 AM, Manajit Halder wrote: >>>>>>>>> Hi Semyon, >>>>>>>>> >>>>>>>>> Regression is cause by JDK-8080729 . The fix can?t be reversed since it is the choice between addChildWindow or orderWindow. Went through code flow related to the issue but didn?t find any other better place in code to handle this issue. The best way to fix the issue would be to avoid retargeting of events (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window (when the mouse is actually on the child window). Therefore request you to review the webrev.00. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Manajit >>>>>>>>> >>>>>>>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com wrote: >>>>>>>>>> >>>>>>>>>> Hi Manajit, >>>>>>>>>> >>>>>>>>>> Can you provide information which fix caused the regression? >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 12/8/17 5:53 AM, Manajit Halder wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Kindly review the following Swing fix. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Cause: >>>>>>>>>>> Issue was due to retargeting of mouse enter exit events. >>>>>>>>>>> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the modeless JDialog. >>>>>>>>>>> >>>>>>>>>>> Fix: >>>>>>>>>>> Retargeting of events is not done in-between MOUSE_PRESS and MOUSE_RELEASE. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Manajit >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Apr 27 06:52:24 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 27 Apr 2018 12:22:24 +0530 Subject: [11] RFR: JDK-8199441: Wrong caret position in multiline text components on Windows with a screen resolution higher than 100% Message-ID: Hi All, Please review a fix for an issue where it is seen that, ?with a screen resolution higher than 100% and then clicking in a JTextArea having setLineWrap(true) set, the caret (insertion point) is not aligned with the cursor. The issue seems to stem from the fact that caret position calculation in DefaultCaret class utilises API that uses integer calculation than floating point calculations. The code flow as seen is DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses integer arithmetic to get the caret position. The same getTabbedOffset uses Font.getStringBounds() which uses floating point arithmetic via Rectangle2D.Float. Proposed fix is to make sure getTabbedOffset uses floating point calculations by using getStringBounds() instead of charsWidth() so that it calculates the character width(s) of text present in JTextArea in floating point to align the caret. Bug: https://bugs.openjdk.java.net/browse/JDK-8199441 webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/ Regards Prasanta From abdul.kolarkunnu at oracle.com Fri Apr 27 09:07:13 2018 From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu) Date: Fri, 27 Apr 2018 02:07:13 -0700 (PDT) Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations In-Reply-To: <8e892877-2434-4d7f-9383-a5ab4bf24917@default> References: <476d8480-cb97-4714-9e9f-ad1e27bf63e9@default> <8e892877-2434-4d7f-9383-a5ab4bf24917@default> Message-ID: Gentle Reminder! Regards, Muneer From: Muneer Kolarkunnu Sent: Tuesday, April 24, 2018 6:10 PM To: swing-dev at openjdk.java.net Cc: Aleksandre Iline Subject: Re: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations Gentle Reminder! Regards, Muneer From: Muneer Kolarkunnu Sent: Friday, April 20, 2018 10:23 AM To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Cc: Aleksandre Iline Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8202064 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202064/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/ad21d12db156 Regards, Muneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Apr 27 23:54:50 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 27 Apr 2018 16:54:50 -0700 Subject: Swing dev>[10] Review request for JDK-8189253: [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu In-Reply-To: References: <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com> Message-ID: <9d50b102-d69b-ce25-2bce-d3ae4007cedd@oracle.com> Hi, Manajit. Please clarify why this bug is occurred after JDK-8080729, how orderWindow/addChildWindow are related to the mouse events which we get? Did we start to get more event or less events or we get events in the different order, what is the difference? On 04/01/2018 10:22, Manajit Halder wrote: > Hi Semyon, > > Fix for issue JDK-8080729 > has caused this > regression due to changes in method setVisible(boolean visible) in file > CPlatformWindow.java > orderWindow is causing the issue here, if we revert to addChildWindow > then the issue is not observed but then the fix for issue JDK-8080729 fails. > Before this change the child window used to be added on to the parent as > shown below in the commented code. But after the change child window is > ordered above the parent. > > Below code causes the regression: > > *CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, > ownerPtr);* > *//CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, > CWrapper.NSWindow.NSWindowAbove);* > > Debugging further I found that if we use orderWindow then the new window > is considered as new graphics device in the method notifyReshape in > LWWindowPeer.java (the method updateGraphicsDevice() returns true) and > is the difference between using orderWindow and addChildWindow. > > Since the option to add child window is between choosing oderWindow and > addChildWindow we don?t have any option to do the fix in the Mac OS > native code. > > Regards, > Manajit > > >> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky >> > wrote: >> >> Hi Manajit, >> >> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac >> OS code only. Nevertheless you are suggesting to fix the regression in >> generic code. This need to be explained somehow. >> >> --Semyon >> >> On 12/25/2017 02:42 AM, Manajit Halder wrote: >>> Hi Semyon, >>> >>> Regression is cause by JDK-8080729 >>> . The fix can?t be >>> reversed since it is the?choice between addChildWindow or >>> orderWindow. Went through code flow related to the issue but?didn?t >>> find any other better place in code to handle this issue. The best >>> way to fix the issue would be to avoid retargeting of events >>> (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on >>> the parent window (when the mouse is actually on the child window). >>> Therefore request you to review the webrev.00. >>> >>> Regards, >>> Manajit >>> >>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com >>>> wrote: >>>> >>>> Hi Manajit, >>>> >>>> Can you provide information which fix caused the regression? >>>> >>>> --Semyon >>>> >>>> >>>> On 12/8/17 5:53 AM, Manajit Halder wrote: >>>>> Hi All, >>>>> >>>>> Kindly review the following Swing fix. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 >>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ >>>>> >>>>> >>>>> Cause: >>>>> Issue was due to retargeting of mouse enter exit events. >>>>> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window >>>>> (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the >>>>> modeless JDialog. >>>>> >>>>> Fix: >>>>> Retargeting of events is not done in-between MOUSE_PRESS and >>>>> MOUSE_RELEASE. >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>> >>> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Apr 28 00:08:12 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 27 Apr 2018 17:08:12 -0700 Subject: [11] RFR: JDK-8199441: Wrong caret position in multiline text components on Windows with a screen resolution higher than 100% In-Reply-To: References: Message-ID: Hi, Prasanta. Please confirm that you run related jck/reg tests. On 26/04/2018 23:52, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that, > ?with a screen resolution higher than 100% and then clicking in a > JTextArea having setLineWrap(true) set, the caret (insertion point) is > not aligned with the cursor. > > The issue seems to stem from the fact that caret position calculation in > DefaultCaret class utilises API that uses integer calculation than > floating point calculations. > The code flow as seen is > DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset > > Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses > integer arithmetic to get the caret position. > The same getTabbedOffset uses Font.getStringBounds() which uses floating > point arithmetic via Rectangle2D.Float. > > Proposed fix is to make sure getTabbedOffset uses floating point > calculations by using getStringBounds() instead of charsWidth() so that > it calculates > the character width(s) of text present in JTextArea in floating point to > align the caret. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199441 > webrev: http://cr.openjdk.java.net/~psadhukhan/8199441/webrev.00/ > > Regards > Prasanta -- Best regards, Sergey.