From vikrant.v.agarwal at oracle.com Wed May 2 05:33:11 2018 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Tue, 1 May 2018 22:33:11 -0700 (PDT) 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: <67a9ecd9-4c4d-4e33-a5df-fb86688e9e14@default> Hi Phil, Please review this new Swingset client sanity test. Best Regards, Vikrant -----Original Message----- From: Vikrant Agarwal Sent: Tuesday, April 10, 2018 6:54 PM To: Sergey Bylokhov ; swing-dev at openjdk.java.net Cc: Aleksandre Iline Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo 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 philip.race at oracle.com Wed May 2 23:02:56 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 2 May 2018 16:02:56 -0700 Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo In-Reply-To: <67a9ecd9-4c4d-4e33-a5df-fb86688e9e14@default> References: <23614819-0fda-4df8-a538-61931fcec4d8@default> <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> <4da635b1-9b5a-4cbe-b727-6f759a09bc74@default> <67a9ecd9-4c4d-4e33-a5df-fb86688e9e14@default> Message-ID: <2dec6a1c-2185-b855-4e14-693ff942fa53@oracle.com> 90 checkInteractionOnDispaly(); 239 private void checkInteractionOnDispaly() { typo in the name here. -phil. On 05/01/2018 10:33 PM, Vikrant Agarwal wrote: > Hi Phil, > > Please review this new Swingset client sanity test. > > Best Regards, > Vikrant > > -----Original Message----- > From: Vikrant Agarwal > Sent: Tuesday, April 10, 2018 6:54 PM > To: Sergey Bylokhov ; swing-dev at openjdk.java.net > Cc: Aleksandre Iline > Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo > > 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 abdul.kolarkunnu at oracle.com Thu May 3 02:04:12 2018 From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu) Date: Wed, 2 May 2018 19:04:12 -0700 (PDT) Subject: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window In-Reply-To: References: Message-ID: <6e24c994-40e1-4be4-a900-33ec6f2b00ae@default> Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8197948 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8197948/webrev.01/ Summary: This is a new test for automated testing of SwingSet2 main window using Jemmy. Aim of this is to test all swing components which are new in Swingset2 main window and are not part of SwingSet3 demos. Components to include in this test are JCheckBoxMenuItem , JRadioButtonMenuItem and different themes for Metal look and feel. Only the file test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java is newly created. All others are taken from SwingSet2 demo with necessary changes for testing (mainly removed unwanted codes). Regards, Muneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikrant.v.agarwal at oracle.com Thu May 3 07:02:33 2018 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Thu, 3 May 2018 00:02:33 -0700 (PDT) Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo In-Reply-To: <2dec6a1c-2185-b855-4e14-693ff942fa53@oracle.com> References: <23614819-0fda-4df8-a538-61931fcec4d8@default> <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> <4da635b1-9b5a-4cbe-b727-6f759a09bc74@default> <67a9ecd9-4c4d-4e33-a5df-fb86688e9e14@default> <2dec6a1c-2185-b855-4e14-693ff942fa53@oracle.com> Message-ID: <9358a67c-9c08-400f-b4eb-6aa647939dd7@default> Thanks Phil, Updated Webrev: http://cr.openjdk.java.net/~vagarwal/8200605/webrev.2/ Best Regards, Vikrant -----Original Message----- From: Philip Race Sent: Thursday, May 03, 2018 4:33 AM To: Vikrant Agarwal Cc: Aleksandre Iline ; Sergey Bylokhov ; swing-dev at openjdk.java.net Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo 90 checkInteractionOnDispaly(); 239 private void checkInteractionOnDispaly() { typo in the name here. -phil. On 05/01/2018 10:33 PM, Vikrant Agarwal wrote: > Hi Phil, > > Please review this new Swingset client sanity test. > > Best Regards, > Vikrant > > -----Original Message----- > From: Vikrant Agarwal > Sent: Tuesday, April 10, 2018 6:54 PM > To: Sergey Bylokhov ; > swing-dev at openjdk.java.net > Cc: Aleksandre Iline > Subject: Re: [11]JDK-8200605: Create test for > GridBagLayoutDemo > > 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 prasanta.sadhukhan at oracle.com Fri May 4 12:00:20 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 4 May 2018 17:30:20 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop Message-ID: Hi All, Please review an enhancement to remove the tight coupling of JDK internal class from FX so that when javafx.* modules are removed from Openjdk build in jdk11, FX in general, and fx swing interop, in particular, can still build and function. Right now, FX uses 6 jdk internal packages sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and sun.java2d. However, the goal is not to use qualified exports of these internal packages once FX is removed to be built along with JDK, The solution will define a new "jdk.unsupported.desktop" module that exports public API that is intended to be used by the javafx.swing module (but it does so with public exports and not qualified exports). The idea is the same as jdk.unsupported, in that it is documented as being unsupported. Further, since it is only intended to be used by javafx.swing, it need not be in the default module graph. The module-info.java will look like this: |module jdk.unsupported.desktop { requires transitive java.desktop; exports jdk.swing.interop; } ||| Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, https://bugs.openjdk.java.net/browse/JDK-8195811 webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 Regards Prasanta || -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri May 4 12:10:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 May 2018 05:10:42 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: Message-ID: <2178d15d-6a33-46bf-c4c6-1cdb9b71b6ca@oracle.com> Thanks, Prasanta. As an additional note to reviewers: The JDK portion of this change (JDK-8202199) is the subject for this review. The FX webrev is enough to be able to test the JDK side, but will need additional refactoring (to allow it to continue to build / run with JDK 10) before being ready for review. If you spot something of concern in the FX webrev, please feel free to bring it up, but don't spend time doing a thorough review just yet. -- Kevin On 5/4/2018 5:00 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review an enhancement to remove the tight coupling of JDK > internal class from FX so that > when javafx.* modules are removed from Openjdk build in jdk11, FX in > general, and fx swing interop, in particular, can still build and > function. > > Right now, FX uses 6 jdk internal packages > sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and > sun.java2d. > > However, the goal is not to use qualified exports of these internal > packages once FX is removed to be built along with JDK, > > The solution will define a new "jdk.unsupported.desktop" module that > exports public API > that is intended to be used by the javafx.swing module (but it does so > with public exports and not qualified exports). > The idea is the same as jdk.unsupported, in that it is documented as > being unsupported. > Further, since it is only intended to be used by javafx.swing, it need > not be in the default module graph. > > The module-info.java will look like this: > |module jdk.unsupported.desktop { requires transitive java.desktop; > exports jdk.swing.interop; } ||| > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, > https://bugs.openjdk.java.net/browse/JDK-8195811 > webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta > || > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri May 4 20:53:03 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 4 May 2018 13:53:03 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: Message-ID: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> Two quick comments. 1) I'd like "Peer" removed from all the exported API. 2) It is probably stable enough now that you can start to add some javadoc. -phil. On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review an enhancement to remove the tight coupling of JDK > internal class from FX so that > when javafx.* modules are removed from Openjdk build in jdk11, FX in > general, and fx swing interop, in particular, can still build and > function. > > Right now, FX uses 6 jdk internal packages > sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and > sun.java2d. > > However, the goal is not to use qualified exports of these internal > packages once FX is removed to be built along with JDK, > > The solution will define a new "jdk.unsupported.desktop" module that > exports public API > that is intended to be used by the javafx.swing module (but it does so > with public exports and not qualified exports). > The idea is the same as jdk.unsupported, in that it is documented as > being unsupported. > Further, since it is only intended to be used by javafx.swing, it need > not be in the default module graph. > > The module-info.java will look like this: > > |module jdk.unsupported.desktop { requires transitive java.desktop; > exports jdk.swing.interop; } ||| > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, > https://bugs.openjdk.java.net/browse/JDK-8195811 > webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta > > || > > From mandy.chung at oracle.com Fri May 4 21:08:33 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 4 May 2018 14:08:33 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: Message-ID: <554d7847-8c52-f5f0-9893-77443d718887@oracle.com> I skimmed through the sources.? It's good to see that this patch is straight forward.? A couple of comments: jdk.unsupported.desktop is defined to the application class loader which I think it's fine as FX modules are defined to the same class loader. I expect src/java.base/share/lib/security/default.security will need to be modified and grant permissions to jdk.unsupported.desktop. Kevin and I talked about potential issues with running with security manager enabled.? Maybe it is a separate task to follow up and it may reveal if any operation needs doPrivileged - that's fine with me. The docs build starts with a known set of root modules for javadoc generation.? I believe jdk.unsupported.desktop won't be included in the docs build which is intended (as it's unsupported).? Can you verify it? Nit: jdk.swing.interop.* source files it'd be good to keep import statements sorted by the names. Mandy On 5/4/18 5:00 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review an enhancement to remove the tight coupling of JDK > internal class from FX so that > when javafx.* modules are removed from Openjdk build in jdk11, FX in > general, and fx swing interop, in particular, can still build and > function. > > Right now, FX uses 6 jdk internal packages > sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and > sun.java2d. > > However, the goal is not to use qualified exports of these internal > packages once FX is removed to be built along with JDK, > > The solution will define a new "jdk.unsupported.desktop" module that > exports public API > that is intended to be used by the javafx.swing module (but it does so > with public exports and not qualified exports). > The idea is the same as jdk.unsupported, in that it is documented as > being unsupported. > Further, since it is only intended to be used by javafx.swing, it need > not be in the default module graph. > > The module-info.java will look like this: > |module jdk.unsupported.desktop { requires transitive java.desktop; > exports jdk.swing.interop; } ||| > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, > https://bugs.openjdk.java.net/browse/JDK-8195811 > webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta > || > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri May 4 22:30:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 May 2018 15:30:09 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <554d7847-8c52-f5f0-9893-77443d718887@oracle.com> References: <554d7847-8c52-f5f0-9893-77443d718887@oracle.com> Message-ID: > jdk.unsupported.desktop is defined to the application class loader > which I think it's fine as FX modules are defined to the same class > loader. I noticed this, too, during my testing this morning. It still fails when the security manager is enabled. We already have a bug filed for this: https://bugs.openjdk.java.net/browse/JDK-8202451 I had hoped would be fixed along with the new unsupported API, but I agree that this could be fixed later. -- Kevin On 5/4/2018 2:08 PM, mandy chung wrote: > I skimmed through the sources.? It's good to see that this patch > is straight forward.? A couple of comments: > > jdk.unsupported.desktop is defined to the application class loader > which I think it's fine as FX modules are defined to the same class > loader. > > I expect src/java.base/share/lib/security/default.security will > need to be modified and grant permissions to jdk.unsupported.desktop. > Kevin and I talked about potential issues with running with security > manager enabled.? Maybe it is a separate task to follow up and it > may reveal if any operation needs doPrivileged - that's fine with me. > > The docs build starts with a known set of root modules for javadoc > generation.? I believe jdk.unsupported.desktop won't be included > in the docs build which is intended (as it's unsupported).? Can > you verify it? > > Nit: jdk.swing.interop.* source files > it'd be good to keep import statements sorted by the names. > > Mandy > > On 5/4/18 5:00 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review an enhancement to remove the tight coupling of JDK >> internal class from FX so that >> when javafx.* modules are removed from Openjdk build in jdk11, FX in >> general, and fx swing interop, in particular, can still build and >> function. >> >> Right now, FX uses 6 jdk internal packages >> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and >> sun.java2d. >> >> However, the goal is not to use qualified exports of these internal >> packages once FX is removed to be built along with JDK, >> >> The solution will define a new "jdk.unsupported.desktop" module that >> exports public API >> that is intended to be used by the javafx.swing module (but it does >> so with public exports and not qualified exports). >> The idea is the same as jdk.unsupported, in that it is documented as >> being unsupported. >> Further, since it is only intended to be used by javafx.swing, it >> need not be in the default module graph. >> >> The module-info.java will look like this: >> |module jdk.unsupported.desktop { requires transitive java.desktop; >> exports jdk.swing.interop; } ||| >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >> https://bugs.openjdk.java.net/browse/JDK-8195811 >> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta >> || >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri May 4 23:02:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 May 2018 16:02:51 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> Message-ID: <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> My quick comments: 1. The changes to java.desktop module-info.java won't compile when applied to jdk-client, since there is already a qualified export of the sun.swing package to another internal class. Can you update your patch to be based off of jdk-client? I note that it requires a small patch to be able to build FX with JDK 11 (it's a known gradle issue), but it's not hard to do. 2. As I mentioned in an off-line email, the final version of the javafx.swing patch will need to use 'requires static jdk.unsupported.desktop' in its module-info.java, so that it will still run on JDK 10 EA. This means that you will need to ensure that jdk.unsupported.desktop is loaded via a service loader as discussed. This will not affect the public API at all, so that can proceed in parallel, but this needs to be fixed. 3. As I mentioned in my earlier reply to Mandy's comment, Swing interop apps will fail if a security manager is installed, because the jdk.unsupported.desktop classes are loaded by the app class loader. This can be sorted out later as a follow-on bug, with permissions added to the default policy file, etc. 4. As Phil mentioned, some docs would be good. They don't need to be all that detailed, since it isn't intended for use by applications, and will not be included in the published API docs bundle (i.e., it should be excluded from "make docs"). I will do a more detailed review early next week. -- Kevin On 5/4/2018 1:53 PM, Phil Race wrote: > Two quick comments. > > 1) I'd like "Peer" removed from all the exported API. > 2) It is probably stable enough now that you can start to add some > javadoc. > > -phil. > > On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review an enhancement to remove the tight coupling of JDK >> internal class from FX so that >> when javafx.* modules are removed from Openjdk build in jdk11, FX in >> general, and fx swing interop, in particular, can still build and >> function. >> >> Right now, FX uses 6 jdk internal packages >> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and >> sun.java2d. >> >> However, the goal is not to use qualified exports of these internal >> packages once FX is removed to be built along with JDK, >> >> The solution will define a new "jdk.unsupported.desktop" module that >> exports public API >> that is intended to be used by the javafx.swing module (but it does >> so with public exports and not qualified exports). >> The idea is the same as jdk.unsupported, in that it is documented as >> being unsupported. >> Further, since it is only intended to be used by javafx.swing, it >> need not be in the default module graph. >> >> The module-info.java will look like this: >> >> |module jdk.unsupported.desktop { requires transitive java.desktop; >> exports jdk.swing.interop; } ||| >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >> https://bugs.openjdk.java.net/browse/JDK-8195811 >> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta >> >> || >> >> > From philip.race at oracle.com Fri May 4 23:27:21 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 04 May 2018 16:27:21 -0700 Subject: RFR: 8202679 : Updates on windows failures in the problem list Message-ID: <5AECEC59.1040008@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8202679 webrev: http://cr.openjdk.java.net/~prr/8202679/ The additions comprise : 4 new bugs were filed for consistent failures A couple of bugs were not included for existing open bugs The modifications are Extending some tests to be generic-all Fixing the path for a couple of bugs. -phil. From Sergey.Bylokhov at oracle.com Fri May 4 23:35:24 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 4 May 2018 16:35:24 -0700 Subject: RFR: 8202679 : Updates on windows failures in the problem list In-Reply-To: <5AECEC59.1040008@oracle.com> References: <5AECEC59.1040008@oracle.com> Message-ID: <37e19d74-e821-704f-35bd-8d2da3c11c85@oracle.com> Looks fine. On 04/05/2018 16:27, Philip Race wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8202679 > webrev: http://cr.openjdk.java.net/~prr/8202679/ > > The additions comprise : > 4 new bugs were filed for consistent failures > A couple of bugs were not included for existing open bugs > > The modifications are > Extending some tests to be generic-all > Fixing the path for a couple of bugs. > > -phil. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Sat May 5 08:58:57 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 5 May 2018 14:28:57 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> Message-ID: <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> Hi All, I have tried to address all comments from Nir, Phil, Mandy and Kevin got so far in this webrev http://cr.openjdk.java.net/~psadhukhan/fxswing.7 >>In?SwingNode, lines 870 -883, is there a reason that only the first method uncommented @Override? I don't understand the comment that wants to skip @Override. If @override is not added, then it will cause recursion between LightweightContent.java:130 and LightweightContent.java:187 thereby causing StackOverflowError. I am also not sure about the comment of skipping @Override but I have removed it from this webrev. Regards Prasanta On 5/5/2018 4:32 AM, Kevin Rushforth wrote: > My quick comments: > > 1. The changes to java.desktop module-info.java won't compile when > applied to jdk-client, since there is already a qualified export of > the sun.swing package to another internal class. Can you update your > patch to be based off of jdk-client? I note that it requires a small > patch to be able to build FX with JDK 11 (it's a known gradle issue), > but it's not hard to do. > > 2. As I mentioned in an off-line email, the final version of the > javafx.swing patch will need to use 'requires static > jdk.unsupported.desktop' in its module-info.java, so that it will > still run on JDK 10 EA. This means that you will need to ensure that > jdk.unsupported.desktop is loaded via a service loader as discussed. > This will not affect the public API at all, so that can proceed in > parallel, but this needs to be fixed. > > 3. As I mentioned in my earlier reply to Mandy's comment, Swing > interop apps will fail if a security manager is installed, because the > jdk.unsupported.desktop classes are loaded by the app class loader. > This can be sorted out later as a follow-on bug, with permissions > added to the default policy file, etc. > > 4. As Phil mentioned, some docs would be good. They don't need to be > all that detailed, since it isn't intended for use by applications, > and will not be included in the published API docs bundle (i.e., it > should be excluded from "make docs"). > > I will do a more detailed review early next week. > > -- Kevin > > On 5/4/2018 1:53 PM, Phil Race wrote: >> Two quick comments. >> >> 1) I'd like "Peer" removed from all the exported API. >> 2) It is probably stable enough now that you can start to add some >> javadoc. >> >> -phil. >> >> On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review an enhancement to remove the tight coupling of JDK >>> internal class from FX so that >>> when javafx.* modules are removed from Openjdk build in jdk11, FX in >>> general, and fx swing interop, in particular, can still build and >>> function. >>> >>> Right now, FX uses 6 jdk internal packages >>> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image >>> and sun.java2d. >>> >>> However, the goal is not to use qualified exports of these internal >>> packages once FX is removed to be built along with JDK, >>> >>> The solution will define a new "jdk.unsupported.desktop" module that >>> exports public API >>> that is intended to be used by the javafx.swing module (but it does >>> so with public exports and not qualified exports). >>> The idea is the same as jdk.unsupported, in that it is documented as >>> being unsupported. >>> Further, since it is only intended to be used by javafx.swing, it >>> need not be in the default module graph. >>> >>> The module-info.java will look like this: >>> >>> |module jdk.unsupported.desktop { requires transitive java.desktop; >>> exports jdk.swing.interop; } ||| >>> >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >>> https://bugs.openjdk.java.net/browse/JDK-8195811 >>> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>> >>> Regards >>> Prasanta >>> >>> || >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Sat May 5 15:20:40 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 5 May 2018 20:50:40 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> Message-ID: Updated webrev to modify java.desktop module-info.java (only difference between webrev7 and this) to remove the duplicate exports of sun.awt so we will have now exports sun.awt to ??????? jdk.accessibility, ??????? jdk.unsupported.desktop; http://cr.openjdk.java.net/~psadhukhan/fxswing.8/ Regards Prasanta On 5/5/2018 2:28 PM, Prasanta Sadhukhan wrote: > Hi All, > > I have tried to address all comments from Nir, Phil, Mandy and Kevin > got so far in this webrev > http://cr.openjdk.java.net/~psadhukhan/fxswing.7 > > >>In?SwingNode, lines 870 -883, is there a reason that only the first > method uncommented @Override? I don't understand the comment that > wants to skip @Override. > If @override is not added, then it will cause recursion between > LightweightContent.java:130 and LightweightContent.java:187 thereby > causing StackOverflowError. I am also not sure about the comment of > skipping @Override but I have removed it from this webrev. > > Regards > Prasanta > On 5/5/2018 4:32 AM, Kevin Rushforth wrote: >> My quick comments: >> >> 1. The changes to java.desktop module-info.java won't compile when >> applied to jdk-client, since there is already a qualified export of >> the sun.swing package to another internal class. Can you update your >> patch to be based off of jdk-client? I note that it requires a small >> patch to be able to build FX with JDK 11 (it's a known gradle issue), >> but it's not hard to do. >> >> 2. As I mentioned in an off-line email, the final version of the >> javafx.swing patch will need to use 'requires static >> jdk.unsupported.desktop' in its module-info.java, so that it will >> still run on JDK 10 EA. This means that you will need to ensure that >> jdk.unsupported.desktop is loaded via a service loader as discussed. >> This will not affect the public API at all, so that can proceed in >> parallel, but this needs to be fixed. >> >> 3. As I mentioned in my earlier reply to Mandy's comment, Swing >> interop apps will fail if a security manager is installed, because >> the jdk.unsupported.desktop classes are loaded by the app class >> loader. This can be sorted out later as a follow-on bug, with >> permissions added to the default policy file, etc. >> >> 4. As Phil mentioned, some docs would be good. They don't need to be >> all that detailed, since it isn't intended for use by applications, >> and will not be included in the published API docs bundle (i.e., it >> should be excluded from "make docs"). >> >> I will do a more detailed review early next week. >> >> -- Kevin >> >> On 5/4/2018 1:53 PM, Phil Race wrote: >>> Two quick comments. >>> >>> 1) I'd like "Peer" removed from all the exported API. >>> 2) It is probably stable enough now that you can start to add some >>> javadoc. >>> >>> -phil. >>> >>> On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review an enhancement to remove the tight coupling of JDK >>>> internal class from FX so that >>>> when javafx.* modules are removed from Openjdk build in jdk11, FX >>>> in general, and fx swing interop, in particular, can still build >>>> and function. >>>> >>>> Right now, FX uses 6 jdk internal packages >>>> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image >>>> and sun.java2d. >>>> >>>> However, the goal is not to use qualified exports of these internal >>>> packages once FX is removed to be built along with JDK, >>>> >>>> The solution will define a new "jdk.unsupported.desktop" module >>>> that exports public API >>>> that is intended to be used by the javafx.swing module (but it does >>>> so with public exports and not qualified exports). >>>> The idea is the same as jdk.unsupported, in that it is documented >>>> as being unsupported. >>>> Further, since it is only intended to be used by javafx.swing, it >>>> need not be in the default module graph. >>>> >>>> The module-info.java will look like this: >>>> >>>> |module jdk.unsupported.desktop { requires transitive java.desktop; >>>> exports jdk.swing.interop; } ||| >>>> >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >>>> https://bugs.openjdk.java.net/browse/JDK-8195811 >>>> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>>> >>>> Regards >>>> Prasanta >>>> >>>> || >>>> >>>> >>> >> > From Alan.Bateman at oracle.com Sun May 6 07:45:18 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 May 2018 08:45:18 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> Message-ID: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> On 05/05/2018 16:20, Prasanta Sadhukhan wrote: > Updated webrev to modify java.desktop module-info.java (only > difference between webrev7 and this) to remove the duplicate exports > of sun.awt so we will have now > > exports sun.awt to > ??????? jdk.accessibility, > ??????? jdk.unsupported.desktop; > > http://cr.openjdk.java.net/~psadhukhan/fxswing.8/ At a high-level, the module declarations look good and using service binding to ensure that the jdk.unsupported.desktop module is resolved looks good. The only thing is the name of the service provider interface, it might be clearer if you use InteropProvider rather than InteropInterface. I assume dependencies/java.desktop/module-info.java.extra will be removed once the remaining dependency on sun.print goes away. -Alan From prasanta.sadhukhan at oracle.com Mon May 7 09:26:54 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 7 May 2018 14:56:54 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> Message-ID: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> On 5/6/2018 1:15 PM, Alan Bateman wrote: > On 05/05/2018 16:20, Prasanta Sadhukhan wrote: >> Updated webrev to modify java.desktop module-info.java (only >> difference between webrev7 and this) to remove the duplicate exports >> of sun.awt so we will have now >> >> exports sun.awt to >> ??????? jdk.accessibility, >> ??????? jdk.unsupported.desktop; >> >> http://cr.openjdk.java.net/~psadhukhan/fxswing.8/ > > At a high-level, the module declarations look good and using service > binding to ensure that the jdk.unsupported.desktop module is resolved > looks good. The only thing is the name of the service provider > interface, it might be clearer if you use InteropProvider rather than > InteropInterface. > Modified webrev to use InteropProvider http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > I assume dependencies/java.desktop/module-info.java.extra will be > removed once the remaining dependency on sun.print goes away. > Yes, that's the plan. Regards Prasanta > -Alan From abdul.kolarkunnu at oracle.com Mon May 7 12:47:44 2018 From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu) Date: Mon, 7 May 2018 05:47:44 -0700 (PDT) Subject: [11] RFR [JDK-8202718] Jemmy JInternalFrameOperator: Dependency with orders of Minimize, Maximize and Close buttons Message-ID: <61ba2bd2-9ca0-4cc9-a768-8dba56081f13@default> Hi All, Please review fix for a bug in jemmy: Bug: https://bugs.openjdk.java.net/browse/JDK-8202718 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202718/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/b39eb1713cff Regards, Muneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 7 14:57:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 May 2018 15:57:09 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> Message-ID: <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: > : > > Modified webrev to use InteropProvider > http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ This looks okay although for consistent then InteropImpl could be renamed too. -Alan From prasanta.sadhukhan at oracle.com Mon May 7 15:01:40 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 7 May 2018 20:31:40 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> Message-ID: <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> Would InteropProviderImpl sound good? Regards Prasanta On 5/7/2018 8:27 PM, Alan Bateman wrote: > > > On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >> : >> >> Modified webrev to use InteropProvider >> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > This looks okay although for consistent then InteropImpl could be > renamed too. > > -Alan From kevin.rushforth at oracle.com Mon May 7 15:05:30 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 7 May 2018 08:05:30 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> Message-ID: <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> That name seems good to me. -- Kevin On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: > Would InteropProviderImpl sound good? > > Regards > Prasanta > On 5/7/2018 8:27 PM, Alan Bateman wrote: >> >> >> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >>> : >>> >>> Modified webrev to use InteropProvider >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >> This looks okay although for consistent then InteropImpl could be >> renamed too. >> >> -Alan > From mandy.chung at oracle.com Mon May 7 16:57:40 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 7 May 2018 09:57:40 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> Message-ID: <0ab91959-1122-b3c4-e413-40eaeb0a9c04@oracle.com> On 5/7/18 2:26 AM, Prasanta Sadhukhan wrote: > Modified webrev to use InteropProvider > http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ This version looks good.?? InteropProviderImpl name is okay with me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.iline at oracle.com Mon May 7 17:48:15 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 7 May 2018 10:48:15 -0700 Subject: [11] RFR [JDK-8202718] Jemmy JInternalFrameOperator: Dependency with orders of Minimize, Maximize and Close buttons In-Reply-To: <61ba2bd2-9ca0-4cc9-a768-8dba56081f13@default> References: <61ba2bd2-9ca0-4cc9-a768-8dba56081f13@default> Message-ID: These changes seem to be consistent with what?s in Jemmy code-tools repository and, therefore, correct. Shura > On May 7, 2018, at 5:47 AM, Muneer Kolarkunnu wrote: > > Hi All, > > Please review fix for a bug in jemmy: > Bug: https://bugs.openjdk.java.net/browse/JDK-8202718 > Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202718/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/b39eb1713cff > > Regards, > Muneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon May 7 19:34:39 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 May 2018 12:34:39 -0700 Subject: [11] RFR [JDK-8202718] Jemmy JInternalFrameOperator: Dependency with orders of Minimize, Maximize and Close buttons In-Reply-To: References: <61ba2bd2-9ca0-4cc9-a768-8dba56081f13@default> Message-ID: <750570e0-ba27-c058-9c02-1ffc8d1feb0e@oracle.com> Then looks fine. On 07/05/2018 10:48, Alexandre (Shura) Iline wrote: > These changes seem to be consistent with what?s in Jemmy code-tools > repository and, therefore, correct. > > Shura > >> On May 7, 2018, at 5:47 AM, Muneer Kolarkunnu >> > wrote: >> >> Hi All, >> Please review fix for a bug in jemmy: >> Bug:https://bugs.openjdk.java.net/browse/JDK-8202718 >> Webrev:http://cr.openjdk.java.net/~akolarkunnu/8202718/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/b39eb1713cff >> Regards, >> Muneer > -- Best regards, Sergey. From abdul.kolarkunnu at oracle.com Tue May 8 00:21:02 2018 From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu) Date: Mon, 7 May 2018 17:21:02 -0700 (PDT) Subject: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window In-Reply-To: <6e24c994-40e1-4be4-a900-33ec6f2b00ae@default> References: <6e24c994-40e1-4be4-a900-33ec6f2b00ae@default> Message-ID: <6647ca79-85df-4566-8039-8f5447db8a3b@default> Gentle Reminder. Regards, Muneer From: Muneer Kolarkunnu Sent: Thursday, May 03, 2018 7:34 AM To: swing-dev at openjdk.java.net Subject: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8197948 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8197948/webrev.01/ Summary: This is a new test for automated testing of SwingSet2 main window using Jemmy. Aim of this is to test all swing components which are new in Swingset2 main window and are not part of SwingSet3 demos. Components to include in this test are JCheckBoxMenuItem , JRadioButtonMenuItem and different themes for Metal look and feel. Only the file test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java is newly created. All others are taken from SwingSet2 demo with necessary changes for testing (mainly removed unwanted codes). Regards, Muneer -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue May 8 05:51:24 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 8 May 2018 11:21:24 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> Message-ID: Modified webrev to rename to InteropProviderImpl http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ Regards Prasanta On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > That name seems good to me. > > -- Kevin > > > On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: >> Would InteropProviderImpl sound good? >> >> Regards >> Prasanta >> On 5/7/2018 8:27 PM, Alan Bateman wrote: >>> >>> >>> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >>>> : >>>> >>>> Modified webrev to use InteropProvider >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >>> This looks okay although for consistent then InteropImpl could be >>> renamed too. >>> >>> -Alan >> > From prasanta.sadhukhan at oracle.com Tue May 8 06:54:34 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 8 May 2018 12:24:34 +0530 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: <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com> Hi Sergey, I have run javax/swing/text jtreg and jck tests and did not observe any regressions. Regards Prasanta On 4/28/2018 5:38 AM, Sergey Bylokhov wrote: > 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 > > From prasanta.sadhukhan at oracle.com Tue May 8 07:53:26 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 8 May 2018 13:23:26 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> Message-ID: <69499881-75db-6690-70a9-b485de821084@oracle.com> We have discussed this internally and we believe that "unsupportedness" is the critical property here so it justifies grouping them in the same "unsupported" namespace rather than desktop namespace. Regards Prasanta On 5/8/2018 12:56 PM, Ali Ebrahimi wrote: > Hi, > What about " jdk.desktop.unsupported" for new module name? > > On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan > > > wrote: > > Modified webrev to rename to InteropProviderImpl > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > > > Regards > Prasanta > > On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > > That name seems good to me. > > -- Kevin > > > On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: > > Would InteropProviderImpl sound good? > > Regards > Prasanta > On 5/7/2018 8:27 PM, Alan Bateman wrote: > > > > On 07/05/2018 10:26, Prasanta Sadhukhan wrote: > > : > > Modified webrev to use InteropProvider > http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > > > This looks okay although for consistent then > InteropImpl could be renamed too. > > -Alan > > > > > > > > -- > > Best Regards, > Ali Ebrahimi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue May 8 10:31:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 8 May 2018 11:31:14 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> Message-ID: <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: > Modified webrev to rename to InteropProviderImpl > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ This looks okay to me. -Alan From kevin.rushforth at oracle.com Tue May 8 15:19:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 May 2018 08:19:45 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <69499881-75db-6690-70a9-b485de821084@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <69499881-75db-6690-70a9-b485de821084@oracle.com> Message-ID: <363e9216-5f1e-4ca2-4f47-b2b09d6d55ea@oracle.com> Exactly. The current naming was recommended by the jigsaw team, and I fully agree. -- Kevin On 5/8/2018 12:53 AM, Prasanta Sadhukhan wrote: > We have discussed this internally and we believe that > "unsupportedness" is the critical property here so it justifies > grouping them in the same "unsupported" namespace rather than desktop > namespace. > > Regards > Prasanta > On 5/8/2018 12:56 PM, Ali Ebrahimi wrote: >> Hi, >> What about " jdk.desktop.unsupported" for new module name? >> >> On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan >> > > wrote: >> >> ??? Modified webrev to rename to InteropProviderImpl >> >> ??? http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >> ??? >> >> ??? Regards >> ??? Prasanta >> >> ??? On 5/7/2018 8:35 PM, Kevin Rushforth wrote: >> >> ??????? That name seems good to me. >> >> ??????? -- Kevin >> >> >> ??????? On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: >> >> ??????????? Would InteropProviderImpl sound good? >> >> ??????????? Regards >> ??????????? Prasanta >> ??????????? On 5/7/2018 8:27 PM, Alan Bateman wrote: >> >> >> >> ??????????????? On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >> >> ??????????????????? : >> >> ??????????????????? Modified webrev to use InteropProvider >> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >> >> >> ??????????????? This looks okay although for consistent then >> ??????????????? InteropImpl could be renamed too. >> >> ??????????????? -Alan >> >> >> >> >> >> >> >> -- >> >> Best Regards, >> Ali Ebrahimi > From philip.race at oracle.com Tue May 8 16:52:44 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 8 May 2018 09:52:44 -0700 Subject: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window In-Reply-To: <6e24c994-40e1-4be4-a900-33ec6f2b00ae@default> References: <6e24c994-40e1-4be4-a900-33ec6f2b00ae@default> Message-ID: +1 -phil. On 05/02/2018 07:04 PM, Muneer Kolarkunnu wrote: > > Hi All, > > Please review the following, a new client sanity test case: > > Task: https://bugs.openjdk.java.net/browse/JDK-8197948 > > Webrev Link:http://cr.openjdk.java.net/~akolarkunnu/8197948/webrev.01/ > > > Summary: This is a new test for automated testing of SwingSet2 main > window using Jemmy. > > Aim of this is to test all swing components which are new in Swingset2 > main window and are not part of SwingSet3 demos. > > Components to include in this test are JCheckBoxMenuItem , > JRadioButtonMenuItem and different themes for Metal look and feel. > > Only the file > test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java is newly > created. All others are taken from SwingSet2 demo with necessary > changes for testing (mainly removed unwanted codes). > > Regards, > > Muneer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue May 8 19:11:13 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 8 May 2018 12:11:13 -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: <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com> References: <144dafff-1f84-ec29-db67-4b97ff372e80@oracle.com> Message-ID: I am not sure this is the right fix. If the intention had been to change all calls to getTabbedTextOffset() to use the FP API it would have just been changed .. rather than adding a new API that provides the option to specify whether to use FP. So perhaps the problem is that internal code needs to be updated to call the FP version directly .. I'd like to read https://bugs.openjdk.java.net/browse/JDK-8168992 to see what was said there but JBS just went down for 5 hours maintenance .. -phil. On 05/07/2018 11:54 PM, Prasanta Sadhukhan wrote: > Hi Sergey, > > I have run javax/swing/text jtreg and jck tests and did not observe > any regressions. > > Regards > Prasanta > On 4/28/2018 5:38 AM, Sergey Bylokhov wrote: >> 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 >> >> > From kevin.rushforth at oracle.com Tue May 8 23:33:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 May 2018 16:33:54 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> Message-ID: <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> The module definition for jdk.unsupported.desktop and the changes to java.desktop look fine. In reviewing the jdk.swing.interop API, I have the following suggestions / observations: 1. DispatcherWrapper, DragSourceContextWrapper, DropTargetContextWrapper, and LightweightContentWrapper can all be abstract, along with most of the methods (rather than having an empty body return value that is never used). 2. The addNotify method in LightweightFrameWrapper is unused. Should be used somewhere? If not, then it can be removed. The implementation of the new wrapper classes looks OK to me with one observation that might or might not matter: 3. The behavior of getDefaultScaleX/Y (which is now in SwingInteropUtils) has changed in the case where the Graphics is not an instance of SunGraphics2D. The former behavior was to leave the instance variables X and Y unchanged. The new behavior will set them back to 1.0. Maybe this can't happen in practice, but it is something to consider. -- Kevin On 5/8/2018 3:31 AM, Alan Bateman wrote: > On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >> Modified webrev to rename to InteropProviderImpl >> >> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > This looks okay to me. > > -Alan From ali.ebrahimi1781 at gmail.com Tue May 8 07:26:21 2018 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 8 May 2018 11:56:21 +0430 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> Message-ID: Hi, What about " jdk.desktop.unsupported" for new module name? On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan < prasanta.sadhukhan at oracle.com> wrote: > Modified webrev to rename to InteropProviderImpl > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > > Regards > Prasanta > > On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > >> That name seems good to me. >> >> -- Kevin >> >> >> On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: >> >>> Would InteropProviderImpl sound good? >>> >>> Regards >>> Prasanta >>> On 5/7/2018 8:27 PM, Alan Bateman wrote: >>> >>>> >>>> >>>> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >>>> >>>>> : >>>>> >>>>> Modified webrev to use InteropProvider >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >>>>> >>>> This looks okay although for consistent then InteropImpl could be >>>> renamed too. >>>> >>>> -Alan >>>> >>> >>> >> > -- Best Regards, Ali Ebrahimi -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed May 9 09:14:52 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 May 2018 14:44:52 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> Message-ID: Modified webrev to cater to these 3 observations http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ Regards Prasanta On 5/9/2018 5:03 AM, Kevin Rushforth wrote: > The module definition for jdk.unsupported.desktop and the changes to > java.desktop look fine. > > In reviewing the jdk.swing.interop API, I have the following > suggestions / observations: > > 1. DispatcherWrapper, DragSourceContextWrapper, > DropTargetContextWrapper, and LightweightContentWrapper can all be > abstract, along with most of the methods (rather than having an empty > body return value that is never used). > > 2. The addNotify method in LightweightFrameWrapper is unused. Should > be used somewhere? If not, then it can be removed. > > The implementation of the new wrapper classes looks OK to me with one > observation that might or might not matter: > > 3. The behavior of getDefaultScaleX/Y (which is now in > SwingInteropUtils) has changed in the case where the Graphics is not > an instance of SunGraphics2D. The former behavior was to leave the > instance variables X and Y unchanged. The new behavior will set them > back to 1.0. Maybe this can't happen in practice, but it is something > to consider. > > -- Kevin > > > On 5/8/2018 3:31 AM, Alan Bateman wrote: >> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>> Modified webrev to rename to InteropProviderImpl >>> >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >> This looks okay to me. >> >> -Alan > From kevin.rushforth at oracle.com Wed May 9 12:28:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 May 2018 05:28:49 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> Message-ID: The following can also be abstract: LightweightContentWrapper: ? getComponent, createDragGestureRecognizer, createDragSourceContextPeer DropTargetContextWrapper: ? getTargetActions, getDropTarget, getTransferDataFlavors, getTransferable, isTransferableJVMLocal DispatcherWrapper: ? isDispatchThread, createSecondaryLoop The rest looks good to me (although I still see two public methods with "Peer" in the name, so Phil may want those renamed). -- Kevin On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: > Modified webrev to cater to these 3 observations > http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ > > Regards > Prasanta > > On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >> The module definition for jdk.unsupported.desktop and the changes to >> java.desktop look fine. >> >> In reviewing the jdk.swing.interop API, I have the following >> suggestions / observations: >> >> 1. DispatcherWrapper, DragSourceContextWrapper, >> DropTargetContextWrapper, and LightweightContentWrapper can all be >> abstract, along with most of the methods (rather than having an empty >> body return value that is never used). >> >> 2. The addNotify method in LightweightFrameWrapper is unused. Should >> be used somewhere? If not, then it can be removed. >> >> The implementation of the new wrapper classes looks OK to me with one >> observation that might or might not matter: >> >> 3. The behavior of getDefaultScaleX/Y (which is now in >> SwingInteropUtils) has changed in the case where the Graphics is not >> an instance of SunGraphics2D. The former behavior was to leave the >> instance variables X and Y unchanged. The new behavior will set them >> back to 1.0. Maybe this can't happen in practice, but it is something >> to consider. >> >> -- Kevin >> >> >> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>> Modified webrev to rename to InteropProviderImpl >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>> This looks okay to me. >>> >>> -Alan >> > From prasanta.sadhukhan at oracle.com Wed May 9 14:14:47 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 May 2018 19:44:47 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> Message-ID: <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> Modified webrev to cater to this http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ Regards Prasanta On 5/9/2018 5:58 PM, Kevin Rushforth wrote: > The following can also be abstract: > > LightweightContentWrapper: > ? getComponent, createDragGestureRecognizer, createDragSourceContextPeer > > DropTargetContextWrapper: > ? getTargetActions, getDropTarget, getTransferDataFlavors, > getTransferable, isTransferableJVMLocal > > DispatcherWrapper: > ? isDispatchThread, createSecondaryLoop > > The rest looks good to me (although I still see two public methods > with "Peer" in the name, so Phil may want those renamed). > > -- Kevin > > > On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >> Modified webrev to cater to these 3 observations >> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >> >> Regards >> Prasanta >> >> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>> The module definition for jdk.unsupported.desktop and the changes to >>> java.desktop look fine. >>> >>> In reviewing the jdk.swing.interop API, I have the following >>> suggestions / observations: >>> >>> 1. DispatcherWrapper, DragSourceContextWrapper, >>> DropTargetContextWrapper, and LightweightContentWrapper can all be >>> abstract, along with most of the methods (rather than having an >>> empty body return value that is never used). >>> >>> 2. The addNotify method in LightweightFrameWrapper is unused. Should >>> be used somewhere? If not, then it can be removed. >>> >>> The implementation of the new wrapper classes looks OK to me with >>> one observation that might or might not matter: >>> >>> 3. The behavior of getDefaultScaleX/Y (which is now in >>> SwingInteropUtils) has changed in the case where the Graphics is not >>> an instance of SunGraphics2D. The former behavior was to leave the >>> instance variables X and Y unchanged. The new behavior will set them >>> back to 1.0. Maybe this can't happen in practice, but it is >>> something to consider. >>> >>> -- Kevin >>> >>> >>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>> Modified webrev to rename to InteropProviderImpl >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>> This looks okay to me. >>>> >>>> -Alan >>> >> > From philip.race at oracle.com Wed May 9 14:42:33 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 09 May 2018 07:42:33 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> Message-ID: <5AF308D9.8080408@oracle.com> Yes, they (the methods mentioning Peer) should be renamed. Qn. to Mandy & Alan : it seems there is no need to mention this module in make/common/Modules.gmk in order to get it built, but is there any advantage in doing so ? I mean without it, there is no conscious listing of it as a module nor classification of it. Another thing that Kevin & I touched on in conversation is that it seems doclint fail on warning must be disabled by default .. and I suppose that is what we want here since documentation is minimal. -phil. On 5/9/18, 5:28 AM, Kevin Rushforth wrote: > The following can also be abstract: > > LightweightContentWrapper: > getComponent, createDragGestureRecognizer, createDragSourceContextPeer > > DropTargetContextWrapper: > getTargetActions, getDropTarget, getTransferDataFlavors, > getTransferable, isTransferableJVMLocal > > DispatcherWrapper: > isDispatchThread, createSecondaryLoop > > The rest looks good to me (although I still see two public methods > with "Peer" in the name, so Phil may want those renamed). > > -- Kevin > > > On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >> Modified webrev to cater to these 3 observations >> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >> >> Regards >> Prasanta >> >> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>> The module definition for jdk.unsupported.desktop and the changes to >>> java.desktop look fine. >>> >>> In reviewing the jdk.swing.interop API, I have the following >>> suggestions / observations: >>> >>> 1. DispatcherWrapper, DragSourceContextWrapper, >>> DropTargetContextWrapper, and LightweightContentWrapper can all be >>> abstract, along with most of the methods (rather than having an >>> empty body return value that is never used). >>> >>> 2. The addNotify method in LightweightFrameWrapper is unused. Should >>> be used somewhere? If not, then it can be removed. >>> >>> The implementation of the new wrapper classes looks OK to me with >>> one observation that might or might not matter: >>> >>> 3. The behavior of getDefaultScaleX/Y (which is now in >>> SwingInteropUtils) has changed in the case where the Graphics is not >>> an instance of SunGraphics2D. The former behavior was to leave the >>> instance variables X and Y unchanged. The new behavior will set them >>> back to 1.0. Maybe this can't happen in practice, but it is >>> something to consider. >>> >>> -- Kevin >>> >>> >>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>> Modified webrev to rename to InteropProviderImpl >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>> This looks okay to me. >>>> >>>> -Alan >>> >> > From Alan.Bateman at oracle.com Wed May 9 14:48:50 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 May 2018 15:48:50 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF308D9.8080408@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <5AF308D9.8080408@oracle.com> Message-ID: On 09/05/2018 15:42, Philip Race wrote: > : > > Qn. to Mandy & Alan : it seems there is no need to mention this module > in make/common/Modules.gmk in order to get it built, but is there any > advantage in doing so ? I mean without it, there is no conscious > listing of > it as a module nor classification of it. Right, it's not necessary to list modules that are defined to the application class loader and are only in the JDK image. There's a comment at the top of the make file on this but it probably could be a bit clearer. -Alan From mandy.chung at oracle.com Wed May 9 15:55:51 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 9 May 2018 08:55:51 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <5AF308D9.8080408@oracle.com> Message-ID: On 5/9/18 7:48 AM, Alan Bateman wrote: > On 09/05/2018 15:42, Philip Race wrote: >> : >> >> Qn. to Mandy & Alan : it seems there is no need to mention this module >> in make/common/Modules.gmk in order to get it built, but is there any >> advantage in doing so ? I mean without it, there is no conscious >> listing of >> it as a module nor classification of it. > Right, it's not necessary to list modules that are defined to the > application class loader and are only in the JDK image. There's a > comment at the top of the make file on this but it probably could be a > bit clearer. The build determines the modules to be compiled from the source directory per the modular source layout.? make/common/Modules.gmk serves a few purpose and the relevant one here is the module to class loader mapping.? It lists the modules defined to the boot loader and platform boot loader. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed May 9 17:10:37 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 May 2018 10:10:37 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF308D9.8080408@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <5AF308D9.8080408@oracle.com> Message-ID: I just checked, and it looks like the build doesn't generate docs for the jdk.unsupported.desktop module. So the issue of doclint warnings is probably a moot point. -- Kevin On 5/9/2018 7:42 AM, Philip Race wrote: > Yes, they (the methods mentioning Peer) should be renamed. > > Qn. to Mandy & Alan : it seems there is no need to mention this module > in make/common/Modules.gmk in order to get it built, but is there any > advantage in doing so ? I mean without it, there is no conscious > listing of > it as a module nor classification of it. > > Another thing that Kevin & I touched on in conversation is that it seems > doclint fail on warning must be disabled by default .. and I suppose that > is what we want here since documentation is minimal. > > -phil. > > On 5/9/18, 5:28 AM, Kevin Rushforth wrote: >> The following can also be abstract: >> >> LightweightContentWrapper: >> ? getComponent, createDragGestureRecognizer, createDragSourceContextPeer >> >> DropTargetContextWrapper: >> ? getTargetActions, getDropTarget, getTransferDataFlavors, >> getTransferable, isTransferableJVMLocal >> >> DispatcherWrapper: >> ? isDispatchThread, createSecondaryLoop >> >> The rest looks good to me (although I still see two public methods >> with "Peer" in the name, so Phil may want those renamed). >> >> -- Kevin >> >> >> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>> Modified webrev to cater to these 3 observations >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>> >>> Regards >>> Prasanta >>> >>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>> The module definition for jdk.unsupported.desktop and the changes >>>> to java.desktop look fine. >>>> >>>> In reviewing the jdk.swing.interop API, I have the following >>>> suggestions / observations: >>>> >>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>> DropTargetContextWrapper, and LightweightContentWrapper can all be >>>> abstract, along with most of the methods (rather than having an >>>> empty body return value that is never used). >>>> >>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>> Should be used somewhere? If not, then it can be removed. >>>> >>>> The implementation of the new wrapper classes looks OK to me with >>>> one observation that might or might not matter: >>>> >>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>> SwingInteropUtils) has changed in the case where the Graphics is >>>> not an instance of SunGraphics2D. The former behavior was to leave >>>> the instance variables X and Y unchanged. The new behavior will set >>>> them back to 1.0. Maybe this can't happen in practice, but it is >>>> something to consider. >>>> >>>> -- Kevin >>>> >>>> >>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>> Modified webrev to rename to InteropProviderImpl >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>> This looks okay to me. >>>>> >>>>> -Alan >>>> >>> >> From kevin.rushforth at oracle.com Wed May 9 17:59:32 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 May 2018 10:59:32 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> Message-ID: <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> Hi Prasanta, The API looks good now. All of our automated tests work (except for the ones with a security manager due to JDK-8202451 ). The only functional problem that I see is that Drag and Drop onto a SwingNode doesn't work. We need to make sure that we test the following four cases: 1. Drag / drop onto a Swing component in a SwingNode 2. Drag / drop from a Swing component in a SwingNode 3. Drag / drop onto a JavaFX control in a JFXPanel 4. Drag / drop from a JavaFX control in a JFXPanel So far I only tried the first one; the others still need to be validated. -- Kevin On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: > Modified webrev to cater to this > > http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ > > Regards > Prasanta > On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >> The following can also be abstract: >> >> LightweightContentWrapper: >> ? getComponent, createDragGestureRecognizer, createDragSourceContextPeer >> >> DropTargetContextWrapper: >> ? getTargetActions, getDropTarget, getTransferDataFlavors, >> getTransferable, isTransferableJVMLocal >> >> DispatcherWrapper: >> ? isDispatchThread, createSecondaryLoop >> >> The rest looks good to me (although I still see two public methods >> with "Peer" in the name, so Phil may want those renamed). >> >> -- Kevin >> >> >> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>> Modified webrev to cater to these 3 observations >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>> >>> Regards >>> Prasanta >>> >>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>> The module definition for jdk.unsupported.desktop and the changes >>>> to java.desktop look fine. >>>> >>>> In reviewing the jdk.swing.interop API, I have the following >>>> suggestions / observations: >>>> >>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>> DropTargetContextWrapper, and LightweightContentWrapper can all be >>>> abstract, along with most of the methods (rather than having an >>>> empty body return value that is never used). >>>> >>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>> Should be used somewhere? If not, then it can be removed. >>>> >>>> The implementation of the new wrapper classes looks OK to me with >>>> one observation that might or might not matter: >>>> >>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>> SwingInteropUtils) has changed in the case where the Graphics is >>>> not an instance of SunGraphics2D. The former behavior was to leave >>>> the instance variables X and Y unchanged. The new behavior will set >>>> them back to 1.0. Maybe this can't happen in practice, but it is >>>> something to consider. >>>> >>>> -- Kevin >>>> >>>> >>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>> Modified webrev to rename to InteropProviderImpl >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>> This looks okay to me. >>>>> >>>>> -Alan >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu May 10 15:20:56 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 10 May 2018 20:50:56 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> Message-ID: Hi Kevin,All, Please find the modified webrev fixing this #1 issue http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ via change in jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext and FXDnD.java#postDropTargetEvent For me, #2 works, #3 doesn't work even now due to JDK-8141391 and #4 works for me. Regards Prasanta On 5/9/2018 11:29 PM, Kevin Rushforth wrote: > Hi Prasanta, > > The API looks good now. > > All of our automated tests work (except for the ones with a security > manager due to JDK-8202451 > ). > > The only functional problem that I see is that Drag and Drop onto a > SwingNode doesn't work. We need to make sure that we test the > following four cases: > > 1. Drag / drop onto a Swing component in a SwingNode > 2. Drag / drop from a Swing component in a SwingNode > 3. Drag / drop onto a JavaFX control in a JFXPanel > 4. Drag / drop from a JavaFX control in a JFXPanel > > So far I only tried the first one; the others still need to be validated. > > -- Kevin > > > > On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >> Modified webrev to cater to this >> >> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >> >> Regards >> Prasanta >> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>> The following can also be abstract: >>> >>> LightweightContentWrapper: >>> ? getComponent, createDragGestureRecognizer, >>> createDragSourceContextPeer >>> >>> DropTargetContextWrapper: >>> ? getTargetActions, getDropTarget, getTransferDataFlavors, >>> getTransferable, isTransferableJVMLocal >>> >>> DispatcherWrapper: >>> ? isDispatchThread, createSecondaryLoop >>> >>> The rest looks good to me (although I still see two public methods >>> with "Peer" in the name, so Phil may want those renamed). >>> >>> -- Kevin >>> >>> >>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>> Modified webrev to cater to these 3 observations >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>> >>>> Regards >>>> Prasanta >>>> >>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>> The module definition for jdk.unsupported.desktop and the changes >>>>> to java.desktop look fine. >>>>> >>>>> In reviewing the jdk.swing.interop API, I have the following >>>>> suggestions / observations: >>>>> >>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>> DropTargetContextWrapper, and LightweightContentWrapper can all be >>>>> abstract, along with most of the methods (rather than having an >>>>> empty body return value that is never used). >>>>> >>>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>>> Should be used somewhere? If not, then it can be removed. >>>>> >>>>> The implementation of the new wrapper classes looks OK to me with >>>>> one observation that might or might not matter: >>>>> >>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>> SwingInteropUtils) has changed in the case where the Graphics is >>>>> not an instance of SunGraphics2D. The former behavior was to leave >>>>> the instance variables X and Y unchanged. The new behavior will >>>>> set them back to 1.0. Maybe this can't happen in practice, but it >>>>> is something to consider. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>> This looks okay to me. >>>>>> >>>>>> -Alan >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Thu May 10 15:32:29 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 May 2018 08:32:29 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> Message-ID: I confirm that this fixes the issue. The interface change to make the two static methods e instance methods is a good change in any case. I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me. -- Kevin On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote: > > Hi Kevin,All, > > Please find the modified webrev fixing this #1 issue > http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ > via change in > jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext > and FXDnD.java#postDropTargetEvent > > For me, #2 works, #3 doesn't work even now due to JDK-8141391 > and #4 works for me. > > Regards > Prasanta > On 5/9/2018 11:29 PM, Kevin Rushforth wrote: >> Hi Prasanta, >> >> The API looks good now. >> >> All of our automated tests work (except for the ones with a security >> manager due to JDK-8202451 >> ). >> >> The only functional problem that I see is that Drag and Drop onto a >> SwingNode doesn't work. We need to make sure that we test the >> following four cases: >> >> 1. Drag / drop onto a Swing component in a SwingNode >> 2. Drag / drop from a Swing component in a SwingNode >> 3. Drag / drop onto a JavaFX control in a JFXPanel >> 4. Drag / drop from a JavaFX control in a JFXPanel >> >> So far I only tried the first one; the others still need to be validated. >> >> -- Kevin >> >> >> >> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >>> Modified webrev to cater to this >>> >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >>> >>> Regards >>> Prasanta >>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>>> The following can also be abstract: >>>> >>>> LightweightContentWrapper: >>>> ? getComponent, createDragGestureRecognizer, >>>> createDragSourceContextPeer >>>> >>>> DropTargetContextWrapper: >>>> ? getTargetActions, getDropTarget, getTransferDataFlavors, >>>> getTransferable, isTransferableJVMLocal >>>> >>>> DispatcherWrapper: >>>> ? isDispatchThread, createSecondaryLoop >>>> >>>> The rest looks good to me (although I still see two public methods >>>> with "Peer" in the name, so Phil may want those renamed). >>>> >>>> -- Kevin >>>> >>>> >>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>>> Modified webrev to cater to these 3 observations >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>>> The module definition for jdk.unsupported.desktop and the changes >>>>>> to java.desktop look fine. >>>>>> >>>>>> In reviewing the jdk.swing.interop API, I have the following >>>>>> suggestions / observations: >>>>>> >>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>>> DropTargetContextWrapper, and LightweightContentWrapper can all >>>>>> be abstract, along with most of the methods (rather than having >>>>>> an empty body return value that is never used). >>>>>> >>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>>>> Should be used somewhere? If not, then it can be removed. >>>>>> >>>>>> The implementation of the new wrapper classes looks OK to me with >>>>>> one observation that might or might not matter: >>>>>> >>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>>> SwingInteropUtils) has changed in the case where the Graphics is >>>>>> not an instance of SunGraphics2D. The former behavior was to >>>>>> leave the instance variables X and Y unchanged. The new behavior >>>>>> will set them back to 1.0. Maybe this can't happen in practice, >>>>>> but it is something to consider. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>>> This looks okay to me. >>>>>>> >>>>>>> -Alan >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbtobin at gmail.com Fri May 11 00:29:48 2018 From: jamesbtobin at gmail.com (James Tobin) Date: Fri, 11 May 2018 01:29:48 +0100 Subject: JOB | Permanent Web Developer (New York) Message-ID: Hello, I'm working with an employer that is looking to hire a permanent senior developer (for their New York office) to work on migrating their legacy Swing app to the web using Javascript, React and Redux. Consequently I had hoped that 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 philip.race at oracle.com Fri May 11 00:49:51 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 10 May 2018 17:49:51 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> Message-ID: <5AF4E8AF.60202@oracle.com> I've looked over the Swing code. No time to actually try it out so I can only comment on what I see. I am not sure what I think about class docs like "This class wraps .." I know no javadoc is generated but this module is exported and probably should say something less specific. In general I really have to hold my nose when looking at this whole module and I find it distasteful to endorse it. I really don't like all the things SwingInterOpUtils.java does. I worry we are creating something we'll come to regret here. The "unsupportedness" needs to be backed up by deprecated-for-removal being included today so we can get rid of it the next release if we want to. No @since tags anywhere.... -phil. On 5/10/18, 8:32 AM, Kevin Rushforth wrote: > I confirm that this fixes the issue. The interface change to make the > two static methods e instance methods is a good change in any case. > > I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me. > > -- Kevin > > > On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote: >> >> Hi Kevin,All, >> >> Please find the modified webrev fixing this #1 issue >> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ >> via change in >> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext >> and FXDnD.java#postDropTargetEvent >> >> For me, #2 works, #3 doesn't work even now due to JDK-8141391 >> and #4 works for me. >> >> Regards >> Prasanta >> On 5/9/2018 11:29 PM, Kevin Rushforth wrote: >>> Hi Prasanta, >>> >>> The API looks good now. >>> >>> All of our automated tests work (except for the ones with a security >>> manager due to JDK-8202451 >>> ). >>> >>> The only functional problem that I see is that Drag and Drop onto a >>> SwingNode doesn't work. We need to make sure that we test the >>> following four cases: >>> >>> 1. Drag / drop onto a Swing component in a SwingNode >>> 2. Drag / drop from a Swing component in a SwingNode >>> 3. Drag / drop onto a JavaFX control in a JFXPanel >>> 4. Drag / drop from a JavaFX control in a JFXPanel >>> >>> So far I only tried the first one; the others still need to be >>> validated. >>> >>> -- Kevin >>> >>> >>> >>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >>>> Modified webrev to cater to this >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >>>> >>>> Regards >>>> Prasanta >>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>>>> The following can also be abstract: >>>>> >>>>> LightweightContentWrapper: >>>>> getComponent, createDragGestureRecognizer, >>>>> createDragSourceContextPeer >>>>> >>>>> DropTargetContextWrapper: >>>>> getTargetActions, getDropTarget, getTransferDataFlavors, >>>>> getTransferable, isTransferableJVMLocal >>>>> >>>>> DispatcherWrapper: >>>>> isDispatchThread, createSecondaryLoop >>>>> >>>>> The rest looks good to me (although I still see two public methods >>>>> with "Peer" in the name, so Phil may want those renamed). >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>>>> Modified webrev to cater to these 3 observations >>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> >>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>>>> The module definition for jdk.unsupported.desktop and the >>>>>>> changes to java.desktop look fine. >>>>>>> >>>>>>> In reviewing the jdk.swing.interop API, I have the following >>>>>>> suggestions / observations: >>>>>>> >>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can all >>>>>>> be abstract, along with most of the methods (rather than having >>>>>>> an empty body return value that is never used). >>>>>>> >>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>>>>> Should be used somewhere? If not, then it can be removed. >>>>>>> >>>>>>> The implementation of the new wrapper classes looks OK to me >>>>>>> with one observation that might or might not matter: >>>>>>> >>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>>>> SwingInteropUtils) has changed in the case where the Graphics is >>>>>>> not an instance of SunGraphics2D. The former behavior was to >>>>>>> leave the instance variables X and Y unchanged. The new behavior >>>>>>> will set them back to 1.0. Maybe this can't happen in practice, >>>>>>> but it is something to consider. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>>>> This looks okay to me. >>>>>>>> >>>>>>>> -Alan >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri May 11 01:29:32 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 10 May 2018 18:29:32 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF4E8AF.60202@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> Message-ID: <5AF4F1FC.2030802@oracle.com> PS .. there should be some tests on the JDK side that don't use FX Or at least a reasoned explanation as to why this isn't possible. -phil. On 5/10/18, 5:49 PM, Philip Race wrote: > I've looked over the Swing code. No time to actually try it out so I > can only comment on what I see. > > I am not sure what I think about class docs like "This class wraps > .." > I know no javadoc is generated but this module is exported and > probably should say something > less specific. > > In general I really have to hold my nose when looking at this whole > module and I > find it distasteful to endorse it. > > I really don't like all the things SwingInterOpUtils.java does. > > I worry we are creating something we'll come to regret here. > The "unsupportedness" needs to be backed up by deprecated-for-removal > being included > today so we can get rid of it the next release if we want to. > > No @since tags anywhere.... > > -phil. > > On 5/10/18, 8:32 AM, Kevin Rushforth wrote: >> I confirm that this fixes the issue. The interface change to make the >> two static methods e instance methods is a good change in any case. >> >> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me. >> >> -- Kevin >> >> >> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote: >>> >>> Hi Kevin,All, >>> >>> Please find the modified webrev fixing this #1 issue >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ >>> via change in >>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext >>> and FXDnD.java#postDropTargetEvent >>> >>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 >>> and #4 works for me. >>> >>> Regards >>> Prasanta >>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote: >>>> Hi Prasanta, >>>> >>>> The API looks good now. >>>> >>>> All of our automated tests work (except for the ones with a >>>> security manager due to JDK-8202451 >>>> ). >>>> >>>> The only functional problem that I see is that Drag and Drop onto a >>>> SwingNode doesn't work. We need to make sure that we test the >>>> following four cases: >>>> >>>> 1. Drag / drop onto a Swing component in a SwingNode >>>> 2. Drag / drop from a Swing component in a SwingNode >>>> 3. Drag / drop onto a JavaFX control in a JFXPanel >>>> 4. Drag / drop from a JavaFX control in a JFXPanel >>>> >>>> So far I only tried the first one; the others still need to be >>>> validated. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >>>>> Modified webrev to cater to this >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>>>>> The following can also be abstract: >>>>>> >>>>>> LightweightContentWrapper: >>>>>> getComponent, createDragGestureRecognizer, >>>>>> createDragSourceContextPeer >>>>>> >>>>>> DropTargetContextWrapper: >>>>>> getTargetActions, getDropTarget, getTransferDataFlavors, >>>>>> getTransferable, isTransferableJVMLocal >>>>>> >>>>>> DispatcherWrapper: >>>>>> isDispatchThread, createSecondaryLoop >>>>>> >>>>>> The rest looks good to me (although I still see two public >>>>>> methods with "Peer" in the name, so Phil may want those renamed). >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>>>>> Modified webrev to cater to these 3 observations >>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> >>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>>>>> The module definition for jdk.unsupported.desktop and the >>>>>>>> changes to java.desktop look fine. >>>>>>>> >>>>>>>> In reviewing the jdk.swing.interop API, I have the following >>>>>>>> suggestions / observations: >>>>>>>> >>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can all >>>>>>>> be abstract, along with most of the methods (rather than having >>>>>>>> an empty body return value that is never used). >>>>>>>> >>>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>>>>>> Should be used somewhere? If not, then it can be removed. >>>>>>>> >>>>>>>> The implementation of the new wrapper classes looks OK to me >>>>>>>> with one observation that might or might not matter: >>>>>>>> >>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>>>>> SwingInteropUtils) has changed in the case where the Graphics >>>>>>>> is not an instance of SunGraphics2D. The former behavior was to >>>>>>>> leave the instance variables X and Y unchanged. The new >>>>>>>> behavior will set them back to 1.0. Maybe this can't happen in >>>>>>>> practice, but it is something to consider. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>>>>> This looks okay to me. >>>>>>>>> >>>>>>>>> -Alan >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri May 11 01:42:54 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 May 2018 18:42:54 -0700 Subject: [11] Review Request: 8202878 com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java fails Message-ID: <2145d57d-0bbc-b17e-f137-d6a88c2a2a15@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8202878 Fix: http://cr.openjdk.java.net/~serb/8202878/webrev.00 The test tries to check that the JMenuItem will be collected by GC if it was removed from the menu. The problem is that the code below does not guarantied that gc will happen: 68 System.gc(); 69 System.runFinalization(); 70 Thread.sleep(1000); In the fix it is replaced by the code which will generate OOM, to be sure that gc will happen. -- Best regards, Sergey. From philip.race at oracle.com Fri May 11 01:45:52 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 10 May 2018 18:45:52 -0700 Subject: [11] Review Request: 8202878 com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java fails In-Reply-To: <2145d57d-0bbc-b17e-f137-d6a88c2a2a15@oracle.com> References: <2145d57d-0bbc-b17e-f137-d6a88c2a2a15@oracle.com> Message-ID: <5AF4F5D0.6040106@oracle.com> +1 -phil. On 5/10/18, 6:42 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202878 > Fix: http://cr.openjdk.java.net/~serb/8202878/webrev.00 > > The test tries to check that the JMenuItem will be collected by GC if > it was removed from the menu. The problem is that the code below does > not guarantied that gc will happen: > > 68 System.gc(); > 69 System.runFinalization(); > 70 Thread.sleep(1000); > > In the fix it is replaced by the code which will generate OOM, to be > sure that gc will happen. > From philip.race at oracle.com Fri May 11 17:46:52 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 10:46:52 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop Message-ID: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8202811 webrev: http://cr.openjdk.java.net/~prr/8202811/ This started out as wanting to problem list a few tests that left windows open or otherwise did not terminate. And these are in there, but I also tried to clean up most of the reproducible Linux failures I see on Ubuntu 16.04. All the problem listed tests fail when being run one per jtreg invocation and were repeatable. -phil. From philip.race at oracle.com Fri May 11 19:08:29 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 12:08:29 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop In-Reply-To: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> References: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> Message-ID: <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> PS .. I forgot I wanted to piggy back an update to TEST.ROOT to add some remaining directories for jtreg to use othervm mode : http://cr.openjdk.java.net/~prr/8202811.1/ -phil. On 05/11/2018 10:46 AM, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8202811 > webrev: http://cr.openjdk.java.net/~prr/8202811/ > > This started out as wanting to problem list a few tests that left > windows open > or otherwise did not terminate. And these are in there, but I also > tried to clean up > most of the reproducible Linux failures I see on Ubuntu 16.04. > All the problem listed tests fail when being run one per jtreg > invocation and > were repeatable. > > -phil. From Sergey.Bylokhov at oracle.com Fri May 11 20:57:55 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2018 13:57:55 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop In-Reply-To: <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> References: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> Message-ID: Looks fine as a first step in our cleanup of the tests on lin/mac. Note: I think that some of the tests fail because of some unrelated issues(other tests or some setup issues), at least some of them works fine on my mac, for example: java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java 8202931 macosx-all On 11/05/2018 12:08, Phil Race wrote: > PS .. I forgot I wanted to piggy back an update to TEST.ROOT to > add some remaining directories for jtreg to use othervm mode : > > http://cr.openjdk.java.net/~prr/8202811.1/ > > -phil. > > > On 05/11/2018 10:46 AM, Phil Race wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8202811 >> webrev: http://cr.openjdk.java.net/~prr/8202811/ >> >> This started out as wanting to problem list a few tests that left >> windows open >> or otherwise did not terminate. And these are in there, but I also >> tried to clean up >> most of the reproducible Linux failures I see on Ubuntu 16.04. >> All the problem listed tests fail when being run one per jtreg >> invocation and >> were repeatable. >> >> -phil. > -- Best regards, Sergey. From philip.race at oracle.com Fri May 11 21:07:03 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 14:07:03 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop In-Reply-To: References: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> Message-ID: I expect that some tests that fail one one system will pass on another and identifying the set up issues or environmental issues may be tricky. -phil. On 05/11/2018 01:57 PM, Sergey Bylokhov wrote: > Looks fine as a first step in our cleanup of the tests on lin/mac. > > Note: I think that some of the tests fail because of some unrelated > issues(other tests or some setup issues), at least some of them works > fine on my mac, for example: > java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java 8202931 > macosx-all > > On 11/05/2018 12:08, Phil Race wrote: >> PS .. I forgot I wanted to piggy back an update to TEST.ROOT to >> add some remaining directories for jtreg to use othervm mode : >> >> http://cr.openjdk.java.net/~prr/8202811.1/ >> >> -phil. >> >> >> On 05/11/2018 10:46 AM, Phil Race wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8202811 >>> webrev: http://cr.openjdk.java.net/~prr/8202811/ >>> >>> This started out as wanting to problem list a few tests that left >>> windows open >>> or otherwise did not terminate. And these are in there, but I also >>> tried to clean up >>> most of the reproducible Linux failures I see on Ubuntu 16.04. >>> All the problem listed tests fail when being run one per jtreg >>> invocation and >>> were repeatable. >>> >>> -phil. >> > > From Sergey.Bylokhov at oracle.com Fri May 11 21:48:59 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2018 14:48:59 -0700 Subject: [11] Review Request: 8202878 com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java fails In-Reply-To: <5AF4F5D0.6040106@oracle.com> References: <2145d57d-0bbc-b17e-f137-d6a88c2a2a15@oracle.com> <5AF4F5D0.6040106@oracle.com> Message-ID: The fix problemList is updated after JDK-8202811[1] was pushed: http://cr.openjdk.java.net/~serb/8202878/webrev.01 [1] http://cr.openjdk.java.net/~prr/8202811.1/ On 10/05/2018 18:45, Philip Race wrote: > +1 > > -phil. > > On 5/10/18, 6:42 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202878 >> Fix: http://cr.openjdk.java.net/~serb/8202878/webrev.00 >> >> The test tries to check that the JMenuItem will be collected by GC if >> it was removed from the menu. The problem is that the code below does >> not guarantied that gc will happen: >> >> 68???????? System.gc(); >> 69???????? System.runFinalization(); >> 70???????? Thread.sleep(1000); >> >> In the fix it is replaced by the code which will generate OOM, to be >> sure that gc will happen. >> -- Best regards, Sergey. From philip.race at oracle.com Fri May 11 22:14:44 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 15:14:44 -0700 Subject: [11] Review Request: 8202878 com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java fails In-Reply-To: References: <2145d57d-0bbc-b17e-f137-d6a88c2a2a15@oracle.com> <5AF4F5D0.6040106@oracle.com> Message-ID: <17e8a4fa-b68a-6627-f6cf-a1185fbc085c@oracle.com> sorry about that.. +1 again. -phil. On 05/11/2018 02:48 PM, Sergey Bylokhov wrote: > The fix problemList is updated after JDK-8202811[1] was pushed: > http://cr.openjdk.java.net/~serb/8202878/webrev.01 > > [1] http://cr.openjdk.java.net/~prr/8202811.1/ > > On 10/05/2018 18:45, Philip Race wrote: >> +1 >> >> -phil. >> >> On 5/10/18, 6:42 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk11. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202878 >>> Fix: http://cr.openjdk.java.net/~serb/8202878/webrev.00 >>> >>> The test tries to check that the JMenuItem will be collected by GC >>> if it was removed from the menu. The problem is that the code below >>> does not guarantied that gc will happen: >>> >>> 68 System.gc(); >>> 69 System.runFinalization(); >>> 70 Thread.sleep(1000); >>> >>> In the fix it is replaced by the code which will generate OOM, to be >>> sure that gc will happen. >>> > > From Sergey.Bylokhov at oracle.com Wed May 16 15:16:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 May 2018 08:16:16 -0700 Subject: [11] Review Request: 8199150 and 8150156 Message-ID: <91d14378-516e-9fe9-f6e8-97a6fff2e8d6@oracle.com> Hello. Please review the fix for jdk11, which fixed some accessibility issues in the specification. Bug: https://bugs.openjdk.java.net/browse/JDK-8199150 https://bugs.openjdk.java.net/browse/JDK-8150156 Fix: http://cr.openjdk.java.net/~serb/8199150/webrev.01 Description: - The links to "bugs.sun.com" were replaced by "bugs.java.com" - To most of our doc-files the "
" tag is added. - In some files the numbers in "H" tag are renumbered to h1/h2/h3 - In JTextComponent the tag was removed, this line was missed in JDK-8184219 - The accessibility checkers report that the red color on the white/gray background has "Insufficient contrast", so I replaced red to blue color -- Best regards, Sergey. From vikrant.v.agarwal at oracle.com Mon May 21 08:18:26 2018 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Mon, 21 May 2018 01:18:26 -0700 (PDT) Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo In-Reply-To: <9358a67c-9c08-400f-b4eb-6aa647939dd7@default> References: <23614819-0fda-4df8-a538-61931fcec4d8@default> <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> <4da635b1-9b5a-4cbe-b727-6f759a09bc74@default> <67a9ecd9-4c4d-4e33-a5df-fb86688e9e14@default> <2dec6a1c-2185-b855-4e14-693ff942fa53@oracle.com> <9358a67c-9c08-400f-b4eb-6aa647939dd7@default> Message-ID: Gentle Reminder -----Original Message----- From: Vikrant Agarwal Sent: Thursday, May 03, 2018 12:33 PM To: Philip Race Cc: Aleksandre Iline ; swing-dev at openjdk.java.net Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo Thanks Phil, Updated Webrev: http://cr.openjdk.java.net/~vagarwal/8200605/webrev.2/ Best Regards, Vikrant -----Original Message----- From: Philip Race Sent: Thursday, May 03, 2018 4:33 AM To: Vikrant Agarwal Cc: Aleksandre Iline ; Sergey Bylokhov ; swing-dev at openjdk.java.net Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo 90 checkInteractionOnDispaly(); 239 private void checkInteractionOnDispaly() { typo in the name here. -phil. On 05/01/2018 10:33 PM, Vikrant Agarwal wrote: > Hi Phil, > > Please review this new Swingset client sanity test. > > Best Regards, > Vikrant > > -----Original Message----- > From: Vikrant Agarwal > Sent: Tuesday, April 10, 2018 6:54 PM > To: Sergey Bylokhov ; > swing-dev at openjdk.java.net > Cc: Aleksandre Iline > Subject: Re: [11]JDK-8200605: Create test for > GridBagLayoutDemo > > 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 Sergey.Bylokhov at oracle.com Mon May 21 16:40:15 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2018 09:40:15 -0700 Subject: [11]JDK-8200605: Create test for GridBagLayoutDemo In-Reply-To: References: <23614819-0fda-4df8-a538-61931fcec4d8@default> <3f9371af-9dd3-b4b2-f154-932756fa48a3@oracle.com> <4da635b1-9b5a-4cbe-b727-6f759a09bc74@default> <67a9ecd9-4c4d-4e33-a5df-fb86688e9e14@default> <2dec6a1c-2185-b855-4e14-693ff942fa53@oracle.com> <9358a67c-9c08-400f-b4eb-6aa647939dd7@default> Message-ID: <9b6ed756-ce54-57a7-54d4-8b727b9d4742@oracle.com> Looks fine. On 21/05/2018 01:18, Vikrant Agarwal wrote: > Gentle Reminder > > -----Original Message----- > From: Vikrant Agarwal > Sent: Thursday, May 03, 2018 12:33 PM > To: Philip Race > Cc: Aleksandre Iline ; swing-dev at openjdk.java.net > Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo > > Thanks Phil, > > Updated Webrev: http://cr.openjdk.java.net/~vagarwal/8200605/webrev.2/ > > Best Regards, > Vikrant > > -----Original Message----- > From: Philip Race > Sent: Thursday, May 03, 2018 4:33 AM > To: Vikrant Agarwal > Cc: Aleksandre Iline ; Sergey Bylokhov ; swing-dev at openjdk.java.net > Subject: Re: [11]JDK-8200605: Create test for GridBagLayoutDemo > > 90 checkInteractionOnDispaly(); > 239 private void checkInteractionOnDispaly() { > > typo in the name here. > > -phil. > > On 05/01/2018 10:33 PM, Vikrant Agarwal wrote: >> Hi Phil, >> >> Please review this new Swingset client sanity test. >> >> Best Regards, >> Vikrant >> >> -----Original Message----- >> From: Vikrant Agarwal >> Sent: Tuesday, April 10, 2018 6:54 PM >> To: Sergey Bylokhov ; >> swing-dev at openjdk.java.net >> Cc: Aleksandre Iline >> Subject: Re: [11]JDK-8200605: Create test for >> GridBagLayoutDemo >> >> 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. > -- Best regards, Sergey. From hurricup at gmail.com Tue May 29 09:11:51 2018 From: hurricup at gmail.com (Alexandr Evstigneev) Date: Tue, 29 May 2018 12:11:51 +0300 Subject: Docs error in javax.swing.JComponent Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 19532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 20986 bytes Desc: not available URL: From Sergey.Bylokhov at oracle.com Tue May 29 15:19:43 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 May 2018 08:19:43 -0700 Subject: Docs error in javax.swing.JComponent In-Reply-To: References: Message-ID: <490ad92d-8141-9a37-002e-12e2ba7c2f2e@oracle.com> These typos were fixed in jdk9: https://bugs.openjdk.java.net/browse/JDK-8068374 On 29/05/2018 02:11, Alexandr Evstigneev wrote: -- Best regards, Sergey. From philip.race at oracle.com Tue May 29 22:43:21 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 29 May 2018 15:43:21 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF4E8AF.60202@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> Message-ID: <5B0DD789.8000809@oracle.com> Some follow up comments. On 5/10/18, 5:49 PM, Philip Race wrote: > I've looked over the Swing code. No time to actually try it out so I > can only comment on what I see. > > I am not sure what I think about class docs like "This class wraps > .." > I know no javadoc is generated but this module is exported and > probably should say something > less specific. > > In general I really have to hold my nose when looking at this whole > module and I > find it distasteful to endorse it. > > I really don't like all the things SwingInterOpUtils.java does. > Specific things we should look at in this file - getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that is passed to JComponent.paintComponent() .. so I wonder if we really need this internal API. I doubt any other code is updating the transform in a way that would make it a problem so the information you get should be valid. The code to get the data array for the raster and associated information can be extracted via standard API like this : DataBuffer db = BufferedImage.getRaster().getDataBuffer(); if (db instanceof DataBufferInt) { data = (DataBufferInt)db.getData(); } So all of those can be fixed. The code that accepts a native window handle maybe should require it is accessed via JNI ... It could still be unsupported, but it would be package private or similar. If you have a native ID, then you are already using native code. This sidesteps any questions about the stability of such an API which accepts a native resource. The code that finds a component by location is probably harmless ... I'm less sure about the event posting and focus grabbing support. I'd like to have Sergey comment on those. the DnD code is too much for me to examine in detail. > I worry we are creating something we'll come to regret here. > The "unsupportedness" needs to be backed up by deprecated-for-removal > being included > today so we can get rid of it the next release if we want to. I've looked at jdk.unsupported and they don't seem to have deprecation tags so maybe that isn't an issue. -phil > > No @since tags anywhere.... > > -phil. > > On 5/10/18, 8:32 AM, Kevin Rushforth wrote: >> I confirm that this fixes the issue. The interface change to make the >> two static methods e instance methods is a good change in any case. >> >> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me. >> >> -- Kevin >> >> >> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote: >>> >>> Hi Kevin,All, >>> >>> Please find the modified webrev fixing this #1 issue >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ >>> via change in >>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext >>> and FXDnD.java#postDropTargetEvent >>> >>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 >>> and #4 works for me. >>> >>> Regards >>> Prasanta >>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote: >>>> Hi Prasanta, >>>> >>>> The API looks good now. >>>> >>>> All of our automated tests work (except for the ones with a >>>> security manager due to JDK-8202451 >>>> ). >>>> >>>> The only functional problem that I see is that Drag and Drop onto a >>>> SwingNode doesn't work. We need to make sure that we test the >>>> following four cases: >>>> >>>> 1. Drag / drop onto a Swing component in a SwingNode >>>> 2. Drag / drop from a Swing component in a SwingNode >>>> 3. Drag / drop onto a JavaFX control in a JFXPanel >>>> 4. Drag / drop from a JavaFX control in a JFXPanel >>>> >>>> So far I only tried the first one; the others still need to be >>>> validated. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >>>>> Modified webrev to cater to this >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>>>>> The following can also be abstract: >>>>>> >>>>>> LightweightContentWrapper: >>>>>> getComponent, createDragGestureRecognizer, >>>>>> createDragSourceContextPeer >>>>>> >>>>>> DropTargetContextWrapper: >>>>>> getTargetActions, getDropTarget, getTransferDataFlavors, >>>>>> getTransferable, isTransferableJVMLocal >>>>>> >>>>>> DispatcherWrapper: >>>>>> isDispatchThread, createSecondaryLoop >>>>>> >>>>>> The rest looks good to me (although I still see two public >>>>>> methods with "Peer" in the name, so Phil may want those renamed). >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>>>>> Modified webrev to cater to these 3 observations >>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> >>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>>>>> The module definition for jdk.unsupported.desktop and the >>>>>>>> changes to java.desktop look fine. >>>>>>>> >>>>>>>> In reviewing the jdk.swing.interop API, I have the following >>>>>>>> suggestions / observations: >>>>>>>> >>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can all >>>>>>>> be abstract, along with most of the methods (rather than having >>>>>>>> an empty body return value that is never used). >>>>>>>> >>>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>>>>>> Should be used somewhere? If not, then it can be removed. >>>>>>>> >>>>>>>> The implementation of the new wrapper classes looks OK to me >>>>>>>> with one observation that might or might not matter: >>>>>>>> >>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>>>>> SwingInteropUtils) has changed in the case where the Graphics >>>>>>>> is not an instance of SunGraphics2D. The former behavior was to >>>>>>>> leave the instance variables X and Y unchanged. The new >>>>>>>> behavior will set them back to 1.0. Maybe this can't happen in >>>>>>>> practice, but it is something to consider. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>>>>> This looks okay to me. >>>>>>>>> >>>>>>>>> -Alan >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 30 18:50:58 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 11:50:58 -0700 Subject: [OpenJDK 2D-Dev] [11] Review Request: 8199150 and 8150156 In-Reply-To: <91d14378-516e-9fe9-f6e8-97a6fff2e8d6@oracle.com> References: <91d14378-516e-9fe9-f6e8-97a6fff2e8d6@oracle.com> Message-ID: +1 -phil. On 05/16/2018 08:16 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11, which fixed some accessibility issues > in the specification. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199150 > https://bugs.openjdk.java.net/browse/JDK-8150156 > Fix: http://cr.openjdk.java.net/~serb/8199150/webrev.01 > > Description: > - The links to "bugs.sun.com" were replaced by "bugs.java.com" > - To most of our doc-files the "
" tag is added. > - In some files the numbers in "H" tag are renumbered to h1/h2/h3 > - In JTextComponent the tag was removed, this line was missed in > JDK-8184219 > - The accessibility checkers report that the red color on the > white/gray background has "Insufficient contrast", so I replaced red > to blue color > From tristan.yu at nokia-sbell.com Thu May 31 03:45:25 2018 From: tristan.yu at nokia-sbell.com (Yu, Tristan (NSB - CN/Qingdao)) Date: Thu, 31 May 2018 03:45:25 +0000 Subject: exception for JFileChooser Message-ID: <6dc0efa1a35f44ebbb164af468542520@nokia-sbell.com> Hi Swing-dev, I tried the example from oracle https://docs.oracle.com/javase/tutorial/displayCode.html?code=https://docs.oracle.com/javase/tutorial/uiswing/examples/components/FileChooserDemoProject/src/components/FileChooserDemo.java When click directories very quick, I got the below exceptions. DO you have any ideas? Thanks! Exception in thread "AWT-EventQueue-0" java.lang.IndexOutOfBoundsException: Invalid index at java.desktop/javax.swing.DefaultRowSorter.convertUnsortedUnfiltered(DefaultRowSorter.java:523) at java.desktop/javax.swing.DefaultRowSorter.convertRowIndexToModel(DefaultRowSorter.java:506) at java.desktop/sun.swing.FilePane$SortableListModel.getElementAt(FilePane.java:676) at java.desktop/javax.swing.JList.getSelectedValue(JList.java:2356) at java.desktop/javax.swing.plaf.basic.BasicFileChooserUI$Handler.valueChanged(BasicFileChooserUI.java:696) at java.desktop/javax.swing.JList.fireSelectionValueChanged(JList.java:1804) at java.desktop/javax.swing.JList$ListSelectionHandler.valueChanged(JList.java:1818) at java.desktop/javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:219) at java.desktop/javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:186) at java.desktop/javax.swing.DefaultListSelectionModel.setValueIsAdjusting(DefaultListSelectionModel.java:723) at java.desktop/javax.swing.JList.setValueIsAdjusting(JList.java:2152) at java.desktop/javax.swing.plaf.basic.BasicListUI$Handler.mouseReleased(BasicListUI.java:2957) at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:298) at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6589) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) at java.desktop/java.awt.Component.processEvent(Component.java:6354) at java.desktop/java.awt.Container.processEvent(Container.java:2261) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4966) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2319) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4914) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4543) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4484) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2305) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) at java.desktop/java.awt.EventQueue.access$600(EventQueue.java:97) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:117) at java.desktop/java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:190) at java.desktop/java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:235) at java.desktop/java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:233) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:233) at java.desktop/java.awt.Dialog.show(Dialog.java:1070) at java.desktop/javax.swing.JFileChooser.showDialog(JFileChooser.java:756) at java.desktop/javax.swing.JFileChooser.showOpenDialog(JFileChooser.java:653) at FileChooserDemo.actionPerformed(FileChooserDemo.java:76) at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967) at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308) at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405) at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262) at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:270) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6589) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) at java.desktop/java.awt.Component.processEvent(Component.java:6354) at java.desktop/java.awt.Container.processEvent(Container.java:2261) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4966) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2319) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4914) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4543) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4484) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2305) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) at java.desktop/java.awt.EventQueue.access$600(EventQueue.java:97) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) Thanks, Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: