From dmitry.markov at oracle.com Sun Jul 1 09:26:22 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Sun, 1 Jul 2018 10:26:22 +0100 Subject: [11] RFR 8205479: OS X: requestFocus() does not work properly for embedded frame In-Reply-To: <96ea92f3-186d-3419-9582-bdaf9e7924f3@oracle.com> References: <617bb0d7-440f-2881-ccd7-08a974bdb840@oracle.com> <96239E96-2B4C-44F7-BCA1-486D0E92C63E@oracle.com> <96ea92f3-186d-3419-9582-bdaf9e7924f3@oracle.com> Message-ID: Hi Sergey, The changes in CPlatformEmbeddedFrame are intended for handling the case when the embedder window contains several embedded frames and focus is transferred programmatically between the frames. In particular if requestFocus() is invoked for some component located at inactive frame it is necessary to activate the frame via CPlatformEmbeddedFrame.requestWindowFocus() to make such focus transition possible. I am sorry, I do not have information about whether the situation described above is applicable for SWT or not. Anyway it is out of scope for this review. Thanks, Dmitry > On 1 Jul 2018, at 00:21, Sergey Bylokhov wrote: > > Hi, Dmitry > Can you please clarify why the changes in CPlatformEmbeddedFrame are necessary? Why the same code does not exists in CViewPlatformEmbeddedFrame? > > On 27/06/2018 10:25, Dmitry Markov wrote: >> Hi Sergey, >> You are right, it is better to use synthesizeWindowActivation(). Please find the updated webrew here: http://cr.openjdk.java.net/~dmarkov/8205479/webrev.01/ >> Changes: >> - Overrode synthesizeWindowActivation() for CEmbeddedFrame. It calls handleWindowFocusEvent() which actually activates or deactivates embedded frame. >> - Added updateGlobalFocusedWindow() to CEmbeddedFrame. This method should be called when the focus is transferred to embedded frame programmatically since handleWindowFocusEvent() skips activation for non-focused embedded frames. >> Thanks, >> Dmitry >>> On 27 Jun 2018, at 01:20, Sergey Bylokhov >> wrote: >>> >>> Hi, Dmitry. >>> Can you please confirm that we should not implement synthesizeWindowActivation() to achieve this behavior? >>> I guess we should do the same as in CViewEmbeddedFrame which is used by SWT. >>> >>> On 25/06/2018 09:11, Dmitry Markov wrote: >>>> Hello, >>>> Could you review a fix for jdk11, please? >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8205479 >>>> webrev: http://cr.openjdk.java.net/~dmarkov/8205479/webrev.00/ >>>> Problem description: >>>> On Mac OSX when focus is transferred to some component located at embedded frame, CPlatformEmbeddedFrame.requestWindowFocus() is called to activate owning frame. However that method does nothing, (i.e. no activation happens). As a result the focus cannot be transferred to the component because its owner is not active. >>>> Fix: >>>> CPlatformEmbeddedFrame.requestWindowFocus() should activate the embedded frame, (i.e. invoke notifyActivation() for the corresponding peer). >>>> Thanks, >>>> Dmitry >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Mon Jul 2 04:13:14 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Sun, 1 Jul 2018 21:13:14 -0700 (PDT) Subject: [12] JDK-8195991: [TEST_BUG]:Regression manual Test java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html fails In-Reply-To: <5e5201f8-25e9-a6be-1e57-70f412fa3792@oracle.com> References: <66dea529-6931-4ec6-a7ee-7a7a20f14fa8@default> <5e5201f8-25e9-a6be-1e57-70f412fa3792@oracle.com> Message-ID: Thank you Sergey for the review. -Shashi -----Original Message----- From: Sergey Bylokhov Sent: Sunday, July 1, 2018 4:38 AM To: Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net Subject: Re: [12] JDK-8195991: [TEST_BUG]:Regression manual Test java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html fails Looks fine. On 27/06/2018 02:33, Shashidhara Veerabhadraiah wrote: > Hi All, Please find the test bug fix for the below bug: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195991 > > Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195991/webrev.01/ > > Change details: The test mostly gets stuck on the windows platform > after performing a few steps hence the test modified to perform > seamlessly and along with it, the applet api usage was removed and > have made the test automatic rather than manual one earlier. This test > is moved from closed to open because of the use of the supporting > libraries(ExtendedRobot and SystemTrayIconHelper). > > Thanks and regards, > > Shashi > -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Mon Jul 2 08:43:55 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 2 Jul 2018 01:43:55 -0700 (PDT) Subject: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows In-Reply-To: <1de60a72-92d1-7e1a-5103-33a617144a9e@oracle.com> References: <500f353e-59bb-42c7-94cd-0d4b00861efb@default> <9f688f83-507c-4e80-84f7-a60eae69117d@default> <4b0c2d6b-d778-300b-8a1c-f6ac0379d212@oracle.com> <1ec6901a-34fe-47b6-944e-437855c592cf@default> <0f76bdcf-9481-35d4-6888-a82b208fd960@oracle.com> <3f69a763-d33f-427c-8e7d-a3d7167efd73@default> <6a8723d6-3207-8d09-94f7-95d26af917e7@oracle.com> <1de60a72-92d1-7e1a-5103-33a617144a9e@oracle.com> Message-ID: <95ecbe36-aac1-476c-85d7-b7387bb876d5@default> Hi Krishna, Changes looks fine to me. -Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Sunday, July 1, 2018 4:22 AM To: Krishna Addepalli; awt-dev at openjdk.java.net Subject: Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows Looks fine. On 28/06/2018 04:25, Krishna Addepalli wrote: > Hi Sergey, > > I have changed the logic of the test so that it passes on Windows. > Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8197810/webrev01/ > > PS: I'm working on making the behavior of Choice consistent across platforms - JDK-8014503. > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, June 27, 2018 12:16 PM > To: Krishna Addepalli ; > awt-dev at openjdk.java.net > Subject: Re: [11][JDK-8197810]RFR: Test > java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails > on Windows > >> Thanks for the clarification. So, this means that we should implement the same behavior in Mac and Linux as well - That is no event should be generated if the same item is selected! Correct? > > Yes, correct. > >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, June 27, 2018 9:27 AM >> To: Krishna Addepalli ; >> awt-dev at openjdk.java.net >> Subject: Re: [11][JDK-8197810]RFR: Test >> java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html >> fails on Windows >> >> On 26/06/2018 19:40, Krishna Addepalli wrote: >>> Hi Sergey, >>> >>> The test with my changes will run on Linux and Mac as well, since basically I'm trying to select a different item, so that the event is always generated. >> >> Yes, an event is generated if different items are selected, but the test was created to check a different use-case: when the same item is reselected. Before JDK-7171412 an event was expected, but after the fix no events should be generated, when the same item reselected. So in the test you need to select the same item an check that no events will be generated. >> >>> But, we should answer the question for JDK-8014503, so that the behavior is consistent on all platforms. >>> >>> Thanks, >>> Krishna >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Wednesday, June 27, 2018 6:05 AM >>> To: Krishna Addepalli ; >>> awt-dev at openjdk.java.net >>> Subject: Re: [11][JDK-8197810]RFR: Test >>> java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html >>> fails on Windows >>> >>> If this was done intentionally then I suggest to revert the expectation of the test. But I think that the test will fail on lin/mac, because one more related bug JDK-8014503 was not fixed. >>> So we should run the test on windows only, until JDK-8014503 is not fixed. >>> >>> On 26/06/2018 06:58, Krishna Addepalli wrote: >>>> Hi Sergey, >>>> >>>> I think the current behavior is intentionally implemented in awt in Windows. I don't know how JDK-4902933 is marked as resolved, but there is a linked issue JDK-7171412. Here is the link to the patch that was pushed as fix for this issue, and we can see that there is an explicit suppression of event propagation in case of same index being selected again. Pasting the current code for reference: >>>> MsgRouting AwtChoice::WmNotify(UINT notifyCode) { >>>> if (notifyCode == CBN_SELCHANGE) { >>>> int selectedIndex = (int)SendMessage(CB_GETCURSEL); >>>> >>>> JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); >>>> jobject target = GetTarget(env); >>>> int previousIndex = env->GetIntField(target, >>>> selectedIndexID); >>>> >>>> if (selectedIndex != CB_ERR && selectedIndex != previousIndex){ >>>> DoCallback("handleAction", "(I)V", selectedIndex); >>>> } >>>> >>>> This is the reason why the test is failing. >>>> >>>> Hope this clarifies. >>>> >>>> Thanks, >>>> Krishna >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Tuesday, May 29, 2018 8:48 PM >>>> To: Krishna Addepalli ; >>>> awt-dev at openjdk.java.net >>>> Subject: Re: [11][JDK-8197810]RFR: Test >>>> java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html >>>> fails on Windows >>>> >>>> Hi, Krishna. >>>> On 08/05/2018 02:59, Krishna Addepalli wrote: >>>>> The basic problem is that, the Robot mouse move is moving to >>>>> position where item 0 is located (which is already selected), and selecting it. >>>>> Since this item is already selected, there is no new item >>>>> selection event generated, which is why the test fails. >>>> As far as I understand the usecase which your describe was implemented intentionally in this test to verify the bug: >>>> https://bugs.openjdk.java.net/browse/JDK-4902933 >>>> >>>> Did you check what is the reason of behavior change? >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From krishna.addepalli at oracle.com Mon Jul 2 09:39:51 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 2 Jul 2018 02:39:51 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Message-ID: Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Jul 2 13:36:57 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 2 Jul 2018 06:36:57 -0700 Subject: [11] Review Request: 8205537 Drop of sun.applet package Message-ID: <34205c13-3f3f-cb20-0ebe-68f9598f6a3a@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some code related to implementation of applets and appletviewer. Some of its classes were dropped already: JDK-8204454, JDK-8203308. Now there are only 3 classes, all related to the applet security and we can drop them as well. In the fix this package was removed, and the tests were updated to not use it. I am not sure how "ClassnameCharTest.java" is useful after applets removal, but since this test used subclass of the AppletClassLoader, I have copied some code from the removed class to the test. -- Best regards, Sergey. From philip.race at oracle.com Mon Jul 2 16:10:53 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 2 Jul 2018 09:10:53 -0700 Subject: [11] Review Request: 8205537 Drop of sun.applet package In-Reply-To: <34205c13-3f3f-cb20-0ebe-68f9598f6a3a@oracle.com> References: <34205c13-3f3f-cb20-0ebe-68f9598f6a3a@oracle.com> Message-ID: <39dea342-1fad-121a-2fbb-d67ddd5a2ce0@oracle.com> Sergey, I think at this point, this is not a P3 for 11. So I won't approve it for 11, but will consider it for 12. -phil. On 7/2/2018 6:36 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 > Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ > > sun.applet is an internal package contained some code related to > implementation of applets and appletviewer. Some of its classes were > dropped already: JDK-8204454, JDK-8203308. Now there are only 3 > classes, all related to the applet security and we can drop them as well. > > In the fix this package was removed, and the tests were updated to not > use it. I am not sure how "ClassnameCharTest.java" is useful after > applets removal, but since this test used subclass of the > AppletClassLoader, I have copied some code from the removed class to > the test. > > From Sergey.Bylokhov at oracle.com Mon Jul 2 16:11:25 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 2 Jul 2018 09:11:25 -0700 Subject: [11] Review Request: 8201611 Broken links in java.desktop javadoc Message-ID: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 Some links in the javadoc became broken after modules were added. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jul 2 16:24:52 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 2 Jul 2018 09:24:52 -0700 Subject: [11] Review Request: 8205537 Drop of sun.applet package In-Reply-To: <39dea342-1fad-121a-2fbb-d67ddd5a2ce0@oracle.com> References: <34205c13-3f3f-cb20-0ebe-68f9598f6a3a@oracle.com> <39dea342-1fad-121a-2fbb-d67ddd5a2ce0@oracle.com> Message-ID: <0242de8e-5de3-bc1e-2cd0-9fa4da3a0bbf@oracle.com> I think it is a good thing to drop this api completely in the same release as JDK-8201446. This is not a p4 and so it can be be fixed and integrated in jdk11 if the fix is ready. On 02/07/2018 09:10, Phil Race wrote: > Sergey, > > I think at this point, this is not a P3 for 11. > So I won't approve it for 11, but will consider it for 12. > > -phil. > > On 7/2/2018 6:36 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 >> Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ >> >> sun.applet is an internal package contained some code related to >> implementation of applets and appletviewer. Some of its classes were >> dropped already: JDK-8204454, JDK-8203308. Now there are only 3 >> classes, all related to the applet security and we can drop them as well. >> >> In the fix this package was removed, and the tests were updated to not >> use it. I am not sure how "ClassnameCharTest.java" is useful after >> applets removal, but since this test used subclass of the >> AppletClassLoader, I have copied some code from the removed class to >> the test. >> >> > -- Best regards, Sergey. From philip.race at oracle.com Mon Jul 2 16:29:20 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 2 Jul 2018 09:29:20 -0700 Subject: [11] Review Request: 8201611 Broken links in java.desktop javadoc In-Reply-To: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> Message-ID: > Some links in the javadoc became broken after modules were added Not exactly, it was after javadoc was changed under https://bugs.openjdk.java.net/browse/JDK-8195795 There are lot of broken links. I also have : https://bugs.openjdk.java.net/browse/JDK-8205646 This one seems to be different than the other two .. no mention of the module http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html Why is it correct ? -phil. On 07/02/2018 09:11 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 > Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 > > Some links in the javadoc became broken after modules were added. > From philip.race at oracle.com Mon Jul 2 16:30:44 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 2 Jul 2018 09:30:44 -0700 Subject: [11] Review Request: 8205537 Drop of sun.applet package In-Reply-To: <0242de8e-5de3-bc1e-2cd0-9fa4da3a0bbf@oracle.com> References: <34205c13-3f3f-cb20-0ebe-68f9598f6a3a@oracle.com> <39dea342-1fad-121a-2fbb-d67ddd5a2ce0@oracle.com> <0242de8e-5de3-bc1e-2cd0-9fa4da3a0bbf@oracle.com> Message-ID: It is not necessary and I reject that it is a P3. Let's leave it for 12. -phil. On 07/02/2018 09:24 AM, Sergey Bylokhov wrote: > I think it is a good thing to drop this api completely in the same > release as JDK-8201446. This is not a p4 and so it can be be fixed and > integrated in jdk11 if the fix is ready. > > On 02/07/2018 09:10, Phil Race wrote: >> Sergey, >> >> I think at this point, this is not a P3 for 11. >> So I won't approve it for 11, but will consider it for 12. >> >> -phil. >> >> On 7/2/2018 6:36 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk11. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 >>> Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ >>> >>> sun.applet is an internal package contained some code related to >>> implementation of applets and appletviewer. Some of its classes were >>> dropped already: JDK-8204454, JDK-8203308. Now there are only 3 >>> classes, all related to the applet security and we can drop them as >>> well. >>> >>> In the fix this package was removed, and the tests were updated to >>> not use it. I am not sure how "ClassnameCharTest.java" is useful >>> after applets removal, but since this test used subclass of the >>> AppletClassLoader, I have copied some code from the removed class to >>> the test. >>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon Jul 2 17:09:28 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 2 Jul 2018 10:09:28 -0700 Subject: [11] Review Request: 8201611 Broken links in java.desktop javadoc In-Reply-To: References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> Message-ID: On 02/07/2018 09:29, Phil Race wrote: > Not exactly, it was after javadoc was changed under > https://bugs.openjdk.java.net/browse/JDK-8195795 So modules are added to the path. > This one seems to be different than the other two .. no mention of the > module > http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html The html tag was replaced by the direct javadoc link to the java class. > Why is it correct ? > > -phil. > > > On 07/02/2018 09:11 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 >> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 >> >> Some links in the javadoc became broken after modules were added. >> > -- Best regards, Sergey. From manajit.halder at oracle.com Mon Jul 2 17:12:23 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 2 Jul 2018 22:42:23 +0530 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> Message-ID: <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> Hi Sergey, Thanks for your review comment. Code changed as per your suggestion. Please review the changes: http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ Regards, Manajit > On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov wrote: > > Hi, Manajit > Can you please simplify such new code in the fix: > (!isFocusable || !isResizable) ? false : true > > "false: true" may be omitted. > > Also please split this new long line: > 486 return (target instanceof Frame) ? ((Frame)target).isResizable() : ((target instanceof Dialog) ? ((Dialog)target).isResizable() : false > > On 28/06/2018 05:54, Manajit Halder wrote: >> Hi Sergey, >> Thanks for your review comment. I have modified the fix to incorporate your suggestions. >> Please review the modified webrev: >> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >> Regards, >> Manajit >>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov >> wrote: >>> >>> Hi, Manajit. >>> There is one more inconsistency, I have tested it using the test for teh previous fix: UnfocusableMaximizedFrameResizablity.java >>> >>> In this case the window is zoomable(the green button is active, but does not work as expected): >>> frame.setFocusableWindowState(false); >>> frame.setResizable(true); >>> >>> In this case the window is not zoomable(the green button is inactive): >>> frame.setResizable(true); >>> frame.setFocusableWindowState(false); >>> >>> I suggest to update the testcase to cover all this cases which we found during review. >>> >>> On 21/06/2018 12:26, Manajit Halder wrote: >>>> Hi Phil and Sergey, >>>> I have changed the code as per your suggestions. Now window is resized based on the following condition: >>>> If window is non-focusable OR window is focusable but non-resizable THEN window is made non-resizable. >>>> Otherwise window is made resizable (when window is resizable and focusable). >>>> Please review the changes: >>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>> Note: Fix was verified by running all the java/awt/ jtreg test cases and by executing the reported JCK interactive test case. >>>> Regards, >>>> Manajit >>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder > wrote: >>>>> >>>>> Hi Phil, >>>>> >>>>> Please find my answer inline to your comment. >>>>> >>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race > wrote: >>>>>> >>>>>> I would like to refer back to a comment you made in the previous fix >>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>> >>>>>> > It is not mentioned in the focus spec whether the unfocusable maximized frames should be resizable or not. >>>>>> >>>>>> Yet there seems to be a JCK test that says it should not be resizable ? >>>>>> >>>>>> Can you review the spec. again ? >>>>>> JCK must have based the test on something .. else the test is not valid. >>>>> >>>>> Yes, I checked FocusSpec.html and it doesn?t specify anything about resizable behaviour of non-focusable Frame. >>>>> >>>>> The UnfocusableMaximizedFrameResizablity.java test passes on Window and Linux and fails on Mac OS. >>>>> Fix for issue 7158623 was done accordingly to make sure the behaviour is same on all platforms. >>>>> >>>>> If this behaviour is not correct then Window and Linux code should be changed accordingly so that all three platforms behave same. >>>>> >>>>>> >>>>>> If we want that behaviour specified .. we should be specifying it .. >>>>>> But I am not sure if it is actually enforceable on all window managers / desktops. >>>>>> >>>>>> But I have the same issue with this fix as the previous one. Perhaps not the fix, >>>>>> but the explanation. The code being changed can't be understood without seeing >>>>>> the method it calls, and the native method it in turn calls. >>>>>> >>>>>> Can you provide a detailed explanation as to how this change propagates down >>>>>> and does the right thing ? >>>>>> >>>>> The call flow: >>>>> >>>>> updateFocusableWindowState() calls setStyleBits with style bits to be set on the window. >>>>> setStyleBits() calls native method nativeSetNSWindowStyleBits. nativeSetNSWindowStyleBits passes mask and 0 as the second parameter in our case (for non-focusable windows). >>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>> >>>>> My previous fix for issue 7158623 explains bits set on the window. >>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>> >>>>> >>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>> >>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>> Changed the code as per the suggestion. Please review the modified code. >>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>>>> -phil. >>>>>> >>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Kindly review the fix for JDK11. >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>> >>>>>>> Fix: >>>>>>> Frame is focusable: >>>>>>> Retaining the existing frame resizable behaviour (Fixes the current issue). >>>>>>> Frame is non-focusable: >>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>> >>>>>>> Regards, >>>>>>> Manajit >>>>>> >>>>> >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jul 2 17:15:17 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 2 Jul 2018 10:15:17 -0700 Subject: [11] Review Request: 8189604 possible hang in sun.awt.shell.Win32ShellFolder2$KnownFolderDefinition:: In-Reply-To: References: <0db434a4-6056-3ae0-be55-57a739122bc9@oracle.com> <8d69dca3-901a-449d-b075-d86eebba9fda@default> <84025a55-7e37-2088-2dfc-4f83503d55bd@oracle.com> Message-ID: <77979335-808e-d65c-613b-6389b60c1f30@oracle.com> +1, but the bug is missing an evaluation. Please add it. -phil. On 06/26/2018 02:05 AM, Krishna Addepalli wrote: > Hi Sergey, > > The changes look fine. > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, June 26, 2018 11:12 AM > To: Krishna Addepalli ; awt-dev at openjdk.java.net > Subject: Re: [11] Review Request: 8189604 possible hang in sun.awt.shell.Win32ShellFolder2$KnownFolderDefinition:: > > Hi, Krishna. > > On 25/06/2018 04:52, Krishna Addepalli wrote: >> The fix looks fine. However, I have couple of comments: >> 1. The variable "result" in Java_sun_awt_shell_Win32ShellFolder2_loadKnownFolders at line 1401 is not initialized. Although it is initialized in the following if condition, I'm not sure when it return false, and lead to a return of garbage value to Java. > Yes it should be initialized: > http://cr.openjdk.java.net/~serb/8189604/webrev.01 > >> 2. Could you clarify a bit about the testcase - how it triggers the hang/crash? > The test tries to load all classes using 'Class.forName(name, true, null)" > which will initialize the classes(will call static initialization). > >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, June 25, 2018 2:21 PM >> To: awt-dev at openjdk.java.net >> Subject: [11] Review Request: 8189604 possible hang in >> sun.awt.shell.Win32ShellFolder2$KnownFolderDefinition:: >> >> Hello. >> Please review the fix for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189604 >> Webrev: http://cr.openjdk.java.net/~serb/8189604/webrev.00 >> >> We have a cyclic dependency in >> Win32ShellFolder2$KnownFolderDefinition, >> which can cause a deadlock if this class is initialized on "non-COM" thread. >> >> 1. - Static initialization of Win32ShellFolder2$KnownFolderDefinition >> 2. -- Win32ShellFolder2.getLibraries(); 3. --- invoke >> Win32ShellFolder2.loadKnownFolders() on "COM-thread" and wait 4. ---- >> in the native call >> env->FindClass("sun/awt/shell/Win32ShellFolder2$KnownFolderDefinition" >> env->); >> 5. ---- deadlock. because initialization of KnownFolderDefinition was blocked at step 3. >> >> In the fix this dependency is broken, so the new class KnownLibraries is not depends from its own initialization. >> >> > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jul 2 17:16:21 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 2 Jul 2018 10:16:21 -0700 Subject: [11] Review Request: 8205537 Drop of sun.applet package In-Reply-To: References: <34205c13-3f3f-cb20-0ebe-68f9598f6a3a@oracle.com> <39dea342-1fad-121a-2fbb-d67ddd5a2ce0@oracle.com> <0242de8e-5de3-bc1e-2cd0-9fa4da3a0bbf@oracle.com> Message-ID: <0e94e06a-4465-5e54-6ada-de1c960b2ffd@oracle.com> I can argue that this is not p2 as related JDK-8201446, but it is definitely not p4. On 02/07/2018 09:30, Phil Race wrote: > It is not necessary and I reject that it is a P3. Let's leave it for 12. > > -phil. > > On 07/02/2018 09:24 AM, Sergey Bylokhov wrote: >> I think it is a good thing to drop this api completely in the same >> release as JDK-8201446. This is not a p4 and so it can be be fixed and >> integrated in jdk11 if the fix is ready. >> >> On 02/07/2018 09:10, Phil Race wrote: >>> Sergey, >>> >>> I think at this point, this is not a P3 for 11. >>> So I won't approve it for 11, but will consider it for 12. >>> >>> -phil. >>> >>> On 7/2/2018 6:36 AM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk11. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 >>>> Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ >>>> >>>> sun.applet is an internal package contained some code related to >>>> implementation of applets and appletviewer. Some of its classes were >>>> dropped already: JDK-8204454, JDK-8203308. Now there are only 3 >>>> classes, all related to the applet security and we can drop them as >>>> well. >>>> >>>> In the fix this package was removed, and the tests were updated to >>>> not use it. I am not sure how "ClassnameCharTest.java" is useful >>>> after applets removal, but since this test used subclass of the >>>> AppletClassLoader, I have copied some code from the removed class to >>>> the test. >>>> >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Mon Jul 2 17:16:01 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 2 Jul 2018 10:16:01 -0700 Subject: [11] Review Request: 8201611 Broken links in java.desktop javadoc In-Reply-To: References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> Message-ID: <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com> OK, +1 -phil. On 07/02/2018 10:09 AM, Sergey Bylokhov wrote: > On 02/07/2018 09:29, Phil Race wrote: >> Not exactly, it was after javadoc was changed under >> https://bugs.openjdk.java.net/browse/JDK-8195795 > > So modules are added to the path. > >> This one seems to be different than the other two .. no mention of >> the module >> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html > > > The html tag was replaced by the direct javadoc link to the java > class. > >> Why is it correct ? >> >> -phil. >> >> >> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk11. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 >>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 >>> >>> Some links in the javadoc became broken after modules were added. >>> >> > > From shashidhara.veerabhadraiah at oracle.com Mon Jul 2 18:00:20 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 2 Jul 2018 11:00:20 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: References: Message-ID: <15209466-11db-4269-bfb7-f69b893e3222@default> Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should be initialized to -1. 0 seems to be a valid value. 2. A test may be required to test out the behavior because as per the comment in the bug, the test SelecteCurrentItemTest.html should fail now on all platforms since the passing platforms software was changed. Other than that the changes looks fine. Thanks and regards, shashi From: Krishna Addepalli Sent: Monday, July 2, 2018 3:10 PM To: awt-dev at openjdk.java.net Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jul 2 18:47:16 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 02 Jul 2018 11:47:16 -0700 Subject: [11] Review Request: 8205588 Deprecate for removal com.sun.awt.SecurityWarning In-Reply-To: <6b137088-5026-7074-d00e-a047efe7283e@oracle.com> References: <6b137088-5026-7074-d00e-a047efe7283e@oracle.com> Message-ID: <5B3A7334.3080603@oracle.com> +1 -phil. On 6/24/18, 11:27 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205588 > Webrev: http://cr.openjdk.java.net/~serb/8205588/webrev.00 > CSR: https://bugs.openjdk.java.net/browse/JDK-8205595 > > The client code has an internal "com.sun.awt.SecurityWarning" class > which at some point in the past, JDK 6u10, was used as a kind of > "public" API. Starting jdk9 this class is accessible at runtime, but > is NOT accessible at compile time. > > This class is unused inside a jdk, but before drop it, I would like to > deprecate this class "for-removal=true". This is the similar step > which was done for the "com.sun.awt.AWTUtilities" > https://bugs.openjdk.java.net/browse/JDK-8187253 > > From krishna.addepalli at oracle.com Tue Jul 3 02:07:34 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 2 Jul 2018 19:07:34 -0700 (PDT) Subject: [11] Review Request: 8205588 Deprecate for removal com.sun.awt.SecurityWarning In-Reply-To: <5B3A7334.3080603@oracle.com> References: <6b137088-5026-7074-d00e-a047efe7283e@oracle.com> <5B3A7334.3080603@oracle.com> Message-ID: <8b56654c-4310-4562-94af-533b3eddd7d8@default> +1 -----Original Message----- From: Philip Race Sent: Tuesday, July 3, 2018 12:17 AM To: Sergey Bylokhov Cc: awt-dev at openjdk.java.net Subject: Re: [11] Review Request: 8205588 Deprecate for removal com.sun.awt.SecurityWarning +1 -phil. On 6/24/18, 11:27 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205588 > Webrev: http://cr.openjdk.java.net/~serb/8205588/webrev.00 > CSR: https://bugs.openjdk.java.net/browse/JDK-8205595 > > The client code has an internal "com.sun.awt.SecurityWarning" class > which at some point in the past, JDK 6u10, was used as a kind of > "public" API. Starting jdk9 this class is accessible at runtime, but > is NOT accessible at compile time. > > This class is unused inside a jdk, but before drop it, I would like to > deprecate this class "for-removal=true". This is the similar step > which was done for the "com.sun.awt.AWTUtilities" > https://bugs.openjdk.java.net/browse/JDK-8187253 > > From krishna.addepalli at oracle.com Tue Jul 3 02:30:06 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 2 Jul 2018 19:30:06 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: <15209466-11db-4269-bfb7-f69b893e3222@default> References: <15209466-11db-4269-bfb7-f69b893e3222@default> Message-ID: <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> Hi Shashi, Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev01/ As for the test, it has already been corrected and pushed in JDK-8197810. Thanks, Krishna From: Shashidhara Veerabhadraiah Sent: Monday, July 2, 2018 11:30 PM To: Krishna Addepalli ; awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should be initialized to -1. 0 seems to be a valid value. 2. A test may be required to test out the behavior because as per the comment in the bug, the test SelecteCurrentItemTest.html should fail now on all platforms since the passing platforms software was changed. Other than that the changes looks fine. Thanks and regards, shashi From: Krishna Addepalli Sent: Monday, July 2, 2018 3:10 PM To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Tue Jul 3 03:44:06 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 2 Jul 2018 20:44:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] Review Request: 8201611 Broken links in java.desktop javadoc In-Reply-To: <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com> References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com> Message-ID: <6cc6fb5c-b453-4ad6-b01c-820cc9b78a5b@default> Looks fine -----Original Message----- From: Phil Race Sent: Monday, July 2, 2018 10:46 PM To: Sergey Bylokhov ; awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] Review Request: 8201611 Broken links in java.desktop javadoc OK, +1 -phil. On 07/02/2018 10:09 AM, Sergey Bylokhov wrote: > On 02/07/2018 09:29, Phil Race wrote: >> Not exactly, it was after javadoc was changed under >> https://bugs.openjdk.java.net/browse/JDK-8195795 > > So modules are added to the path. > >> This one seems to be different than the other two .. no mention of >> the module >> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/s >> hare/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html > > > The html tag was replaced by the direct javadoc link to the java > class. > >> Why is it correct ? >> >> -phil. >> >> >> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk11. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 >>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 >>> >>> Some links in the javadoc became broken after modules were added. >>> >> > > From shashidhara.veerabhadraiah at oracle.com Tue Jul 3 06:46:27 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 2 Jul 2018 23:46:27 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> References: <15209466-11db-4269-bfb7-f69b893e3222@default> <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> Message-ID: <4c0f4397-c2e7-44ea-931b-141566682eb5@default> Hi Krishna, The changes looks fine. Please don't forget to add the bug id to the test before the push. And add this bug JDK-8197810 "as relate to" the current bug(in bug db). Thanks and regards, Shashi From: Krishna Addepalli Sent: Tuesday, July 3, 2018 8:00 AM To: Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Shashi, Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev01/ As for the test, it has already been corrected and pushed in JDK-8197810. Thanks, Krishna From: Shashidhara Veerabhadraiah Sent: Monday, July 2, 2018 11:30 PM To: Krishna Addepalli ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should be initialized to -1. 0 seems to be a valid value. 2. A test may be required to test out the behavior because as per the comment in the bug, the test SelecteCurrentItemTest.html should fail now on all platforms since the passing platforms software was changed. Other than that the changes looks fine. Thanks and regards, shashi From: Krishna Addepalli Sent: Monday, July 2, 2018 3:10 PM To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Tue Jul 3 07:44:55 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 3 Jul 2018 00:44:55 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: <4c0f4397-c2e7-44ea-931b-141566682eb5@default> References: <15209466-11db-4269-bfb7-f69b893e3222@default> <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> <4c0f4397-c2e7-44ea-931b-141566682eb5@default> Message-ID: <167f2070-9661-47b8-8161-85fa31a8dc54@default> Can we use existing 'skipPostMessage' member for this check instead of introducing additional member in LWChoicePeer class? From: Shashidhara Veerabhadraiah Sent: Tuesday, July 03, 2018 12:16 PM To: Krishna Addepalli; awt-dev at openjdk.java.net Subject: Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, The changes looks fine. Please don't forget to add the bug id to the test before the push. And add this bug JDK-8197810 "as relate to" the current bug(in bug db). Thanks and regards, Shashi From: Krishna Addepalli Sent: Tuesday, July 3, 2018 8:00 AM To: Shashidhara Veerabhadraiah ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Shashi, Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev01/ As for the test, it has already been corrected and pushed in JDK-8197810. Thanks, Krishna From: Shashidhara Veerabhadraiah Sent: Monday, July 2, 2018 11:30 PM To: Krishna Addepalli ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should be initialized to -1. 0 seems to be a valid value. 2. A test may be required to test out the behavior because as per the comment in the bug, the test SelecteCurrentItemTest.html should fail now on all platforms since the passing platforms software was changed. Other than that the changes looks fine. Thanks and regards, shashi From: Krishna Addepalli Sent: Monday, July 2, 2018 3:10 PM To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Tue Jul 3 07:55:47 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 3 Jul 2018 13:25:47 +0530 Subject: [12] JDK-8195991: [TEST_BUG]:Regression manual Test java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html fails In-Reply-To: References: <66dea529-6931-4ec6-a7ee-7a7a20f14fa8@default> <5e5201f8-25e9-a6be-1e57-70f412fa3792@oracle.com> Message-ID: Hi Shashi, BUTTON1_MASK and BUTTON3_MASK are deprecated. Remaining code changes looks good. Regards, Manajit > On 02-Jul-2018, at 9:43 AM, Shashidhara Veerabhadraiah wrote: > > Thank you Sergey for the review. > > -Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Sunday, July 1, 2018 4:38 AM > To: Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net > Subject: Re: [12] JDK-8195991: [TEST_BUG]:Regression manual Test java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html fails > > Looks fine. > > On 27/06/2018 02:33, Shashidhara Veerabhadraiah wrote: >> Hi All, Please find the test bug fix for the below bug: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8195991 >> >> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195991/webrev.01/ >> >> Change details: The test mostly gets stuck on the windows platform >> after performing a few steps hence the test modified to perform >> seamlessly and along with it, the applet api usage was removed and >> have made the test automatic rather than manual one earlier. This test >> is moved from closed to open because of the use of the supporting >> libraries(ExtendedRobot and SystemTrayIconHelper). >> >> Thanks and regards, >> >> Shashi >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Tue Jul 3 08:26:41 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Tue, 3 Jul 2018 13:56:41 +0530 Subject: [12] JDK-8195991: [TEST_BUG]:Regression manual Test java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html fails In-Reply-To: References: <66dea529-6931-4ec6-a7ee-7a7a20f14fa8@default> <5e5201f8-25e9-a6be-1e57-70f412fa3792@oracle.com> Message-ID: <8eb36b52-9efa-3fff-5b68-802a537325b6@oracle.com> Hi Manajit, Thanks for the review and please find the updated webrev: http://cr.openjdk.java.net/~sveerabhadra/8195991/webrev.02/ Thanks and regards, Shashi On 03/07/18 1:25 PM, Manajit Halder wrote: > Hi Shashi, > > BUTTON1_MASK and BUTTON3_MASK?are deprecated. > Remaining code changes looks good. > > Regards, > Manajit > >> On 02-Jul-2018, at 9:43 AM, Shashidhara Veerabhadraiah >> > > wrote: >> >> Thank you Sergey for the review. >> >> -Shashi >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Sunday, July 1, 2018 4:38 AM >> To: Shashidhara Veerabhadraiah > >; >> awt-dev at openjdk.java.net >> Subject: Re: [12] JDK-8195991: [TEST_BUG]:Regression manual >> Test >> java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html >> fails >> >> Looks fine. >> >> On 27/06/2018 02:33, Shashidhara Veerabhadraiah wrote: >>> Hi All, Please find the test bug fix for the below bug: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195991 >>> >>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195991/webrev.01/ >>> >>> >>> Change details: The test mostly gets stuck on the windows platform >>> after performing a few steps hence the test modified to perform >>> seamlessly and along with it, the applet api usage was removed and >>> have made the test automatic rather than manual one earlier. This test >>> is moved from closed to open because of the use of the supporting >>> libraries(ExtendedRobot and SystemTrayIconHelper). >>> >>> Thanks and regards, >>> >>> Shashi >>> >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Tue Jul 3 08:50:14 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 3 Jul 2018 01:50:14 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: <167f2070-9661-47b8-8161-85fa31a8dc54@default> References: <15209466-11db-4269-bfb7-f69b893e3222@default> <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> <4c0f4397-c2e7-44ea-931b-141566682eb5@default> <167f2070-9661-47b8-8161-85fa31a8dc54@default> Message-ID: <1d5c75d2-27c5-4594-b68e-c2230b42b47a@default> Hi Ajit, I don't think we can use 'skipPostMessage' for this check for the following reasons: 1. 'skipPostMessage' is intended to filter out item unselected messages, which are posted in case of JComboBox. 2. I need to store the previously selected index to compare against the current index, and I'll need to change the skipPostMessage to integer type - although doable, will be a maintenance headache. 3. As much as I have seen, skipPostMessage variable is restored to false in the same function call (select and remove), whereas for selectedIndex, this won't be the case. 4. Also, remove function is not called from here, but from outside. So, the state will clash, when I save the last selected index, and immediately remove gets called. Hope this clarifies. Thanks, Krishna From: Ajit Ghaisas Sent: Tuesday, July 3, 2018 1:15 PM To: Shashidhara Veerabhadraiah ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Can we use existing 'skipPostMessage' member for this check instead of introducing additional member in LWChoicePeer class? From: Shashidhara Veerabhadraiah Sent: Tuesday, July 03, 2018 12:16 PM To: Krishna Addepalli; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, The changes looks fine. Please don't forget to add the bug id to the test before the push. And add this bug JDK-8197810 "as relate to" the current bug(in bug db). Thanks and regards, Shashi From: Krishna Addepalli Sent: Tuesday, July 3, 2018 8:00 AM To: Shashidhara Veerabhadraiah ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Shashi, Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev01/ As for the test, it has already been corrected and pushed in JDK-8197810. Thanks, Krishna From: Shashidhara Veerabhadraiah Sent: Monday, July 2, 2018 11:30 PM To: Krishna Addepalli ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should be initialized to -1. 0 seems to be a valid value. 2. A test may be required to test out the behavior because as per the comment in the bug, the test SelecteCurrentItemTest.html should fail now on all platforms since the passing platforms software was changed. Other than that the changes looks fine. Thanks and regards, shashi From: Krishna Addepalli Sent: Monday, July 2, 2018 3:10 PM To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Tue Jul 3 09:46:57 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 3 Jul 2018 15:16:57 +0530 Subject: [12] JDK-8195991: [TEST_BUG]:Regression manual Test java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html fails In-Reply-To: <8eb36b52-9efa-3fff-5b68-802a537325b6@oracle.com> References: <66dea529-6931-4ec6-a7ee-7a7a20f14fa8@default> <5e5201f8-25e9-a6be-1e57-70f412fa3792@oracle.com> <8eb36b52-9efa-3fff-5b68-802a537325b6@oracle.com> Message-ID: <6B0D95CE-6AB8-49C8-8E76-296ED5A7F008@oracle.com> Looks good. Regards, Manajit > On 03-Jul-2018, at 1:56 PM, shashidhara.veerabhadraiah at oracle.com wrote: > > Hi Manajit, Thanks for the review and please find the updated webrev: > > http://cr.openjdk.java.net/~sveerabhadra/8195991/webrev.02/ > Thanks and regards, > Shashi > > On 03/07/18 1:25 PM, Manajit Halder wrote: >> Hi Shashi, >> >> BUTTON1_MASK and BUTTON3_MASK are deprecated. >> Remaining code changes looks good. >> >> Regards, >> Manajit >> >>> On 02-Jul-2018, at 9:43 AM, Shashidhara Veerabhadraiah > wrote: >>> >>> Thank you Sergey for the review. >>> >>> -Shashi >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Sunday, July 1, 2018 4:38 AM >>> To: Shashidhara Veerabhadraiah >; awt-dev at openjdk.java.net >>> Subject: Re: [12] JDK-8195991: [TEST_BUG]:Regression manual Test java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.html fails >>> >>> Looks fine. >>> >>> On 27/06/2018 02:33, Shashidhara Veerabhadraiah wrote: >>>> Hi All, Please find the test bug fix for the below bug: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195991 >>>> >>>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195991/webrev.01/ >>>> >>>> Change details: The test mostly gets stuck on the windows platform >>>> after performing a few steps hence the test modified to perform >>>> seamlessly and along with it, the applet api usage was removed and >>>> have made the test automatic rather than manual one earlier. This test >>>> is moved from closed to open because of the use of the supporting >>>> libraries(ExtendedRobot and SystemTrayIconHelper). >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Tue Jul 3 10:00:37 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 3 Jul 2018 03:00:37 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: <1d5c75d2-27c5-4594-b68e-c2230b42b47a@default> References: <15209466-11db-4269-bfb7-f69b893e3222@default> <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> <4c0f4397-c2e7-44ea-931b-141566682eb5@default> <167f2070-9661-47b8-8161-85fa31a8dc54@default> <1d5c75d2-27c5-4594-b68e-c2230b42b47a@default> Message-ID: <23e54562-2461-4f6a-818f-4cd2b0efe676@default> Hi Krishna, Thanks for the explanation. Changes look good. You will need a 'R' reviewer to review this though. Regards, Ajit From: Krishna Addepalli Sent: Tuesday, July 03, 2018 2:20 PM To: Ajit Ghaisas; Shashidhara Veerabhadraiah; awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Ajit, I don't think we can use 'skipPostMessage' for this check for the following reasons: 1. 'skipPostMessage' is intended to filter out item unselected messages, which are posted in case of JComboBox. 2. I need to store the previously selected index to compare against the current index, and I'll need to change the skipPostMessage to integer type - although doable, will be a maintenance headache. 3. As much as I have seen, skipPostMessage variable is restored to false in the same function call (select and remove), whereas for selectedIndex, this won't be the case. 4. Also, remove function is not called from here, but from outside. So, the state will clash, when I save the last selected index, and immediately remove gets called. Hope this clarifies. Thanks, Krishna From: Ajit Ghaisas Sent: Tuesday, July 3, 2018 1:15 PM To: Shashidhara Veerabhadraiah ; Krishna Addepalli ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Can we use existing 'skipPostMessage' member for this check instead of introducing additional member in LWChoicePeer class? From: Shashidhara Veerabhadraiah Sent: Tuesday, July 03, 2018 12:16 PM To: Krishna Addepalli; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, The changes looks fine. Please don't forget to add the bug id to the test before the push. And add this bug JDK-8197810 "as relate to" the current bug(in bug db). Thanks and regards, Shashi From: Krishna Addepalli Sent: Tuesday, July 3, 2018 8:00 AM To: Shashidhara Veerabhadraiah ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Shashi, Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev01/ As for the test, it has already been corrected and pushed in JDK-8197810. Thanks, Krishna From: Shashidhara Veerabhadraiah Sent: Monday, July 2, 2018 11:30 PM To: Krishna Addepalli ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should be initialized to -1. 0 seems to be a valid value. 2. A test may be required to test out the behavior because as per the comment in the bug, the test SelecteCurrentItemTest.html should fail now on all platforms since the passing platforms software was changed. Other than that the changes looks fine. Thanks and regards, shashi From: Krishna Addepalli Sent: Monday, July 2, 2018 3:10 PM To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Wed Jul 4 10:48:14 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 4 Jul 2018 03:48:14 -0700 (PDT) Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: <23e54562-2461-4f6a-818f-4cd2b0efe676@default> References: <15209466-11db-4269-bfb7-f69b893e3222@default> <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> <4c0f4397-c2e7-44ea-931b-141566682eb5@default> <167f2070-9661-47b8-8161-85fa31a8dc54@default> <1d5c75d2-27c5-4594-b68e-c2230b42b47a@default> <23e54562-2461-4f6a-818f-4cd2b0efe676@default> Message-ID: <17ddc416-4d9d-4e1c-b3df-3601905fbccd@default> Hi Prasanta/Sergey, Could you review this ? @Ajit, Shashi - Thanks for your review. Thanks, Krishna From: Ajit Ghaisas Sent: Tuesday, July 3, 2018 3:31 PM To: Krishna Addepalli ; Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Thanks for the explanation. Changes look good. You will need a 'R' reviewer to review this though. Regards, Ajit From: Krishna Addepalli Sent: Tuesday, July 03, 2018 2:20 PM To: Ajit Ghaisas; Shashidhara Veerabhadraiah; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Ajit, I don't think we can use 'skipPostMessage' for this check for the following reasons: 1. 'skipPostMessage' is intended to filter out item unselected messages, which are posted in case of JComboBox. 2. I need to store the previously selected index to compare against the current index, and I'll need to change the skipPostMessage to integer type - although doable, will be a maintenance headache. 3. As much as I have seen, skipPostMessage variable is restored to false in the same function call (select and remove), whereas for selectedIndex, this won't be the case. 4. Also, remove function is not called from here, but from outside. So, the state will clash, when I save the last selected index, and immediately remove gets called. Hope this clarifies. Thanks, Krishna From: Ajit Ghaisas Sent: Tuesday, July 3, 2018 1:15 PM To: Shashidhara Veerabhadraiah ; Krishna Addepalli ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Can we use existing 'skipPostMessage' member for this check instead of introducing additional member in LWChoicePeer class? From: Shashidhara Veerabhadraiah Sent: Tuesday, July 03, 2018 12:16 PM To: Krishna Addepalli; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, The changes looks fine. Please don't forget to add the bug id to the test before the push. And add this bug JDK-8197810 "as relate to" the current bug(in bug db). Thanks and regards, Shashi From: Krishna Addepalli Sent: Tuesday, July 3, 2018 8:00 AM To: Shashidhara Veerabhadraiah ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Shashi, Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev01/ As for the test, it has already been corrected and pushed in JDK-8197810. Thanks, Krishna From: Shashidhara Veerabhadraiah Sent: Monday, July 2, 2018 11:30 PM To: Krishna Addepalli ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should be initialized to -1. 0 seems to be a valid value. 2. A test may be required to test out the behavior because as per the comment in the bug, the test SelecteCurrentItemTest.html should fail now on all platforms since the passing platforms software was changed. Other than that the changes looks fine. Thanks and regards, shashi From: Krishna Addepalli Sent: Monday, July 2, 2018 3:10 PM To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was not changed for Mac and Linux. This fix changes that behavior, and makes it consistent for all the three platforms. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Jul 4 12:22:21 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 4 Jul 2018 15:22:21 +0300 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> Message-ID: <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> Hi, Manajit. Can you please recheck the usage of setCanFullscreen() method at line 691. Is it possible to make the window "FULLSCREENABLE" when it is not focusable? I guess it can be checked by something like this: frame.setFocusableWindowState(false); frame.setResizable(true); v1 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); frame.setVisible(false); frame.setVisible(true); v2 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); if(!v1.equals(v2)) Error(); On 02/07/2018 20:12, Manajit Halder wrote: > Hi Sergey, > > Thanks for your review comment. Code changed as per your suggestion. > Please review the changes: > http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ > > Regards, > Manajit > >> On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov >> > wrote: >> >> Hi, Manajit >> Can you please simplify such new code in the fix: >> (!isFocusable || !isResizable) ? false : true >> >> "false: true" may be omitted. >> >> Also please split this new long line: >> 486 return (target instanceof Frame) ? ((Frame)target).isResizable() : >> ((target instanceof Dialog) ? ((Dialog)target).isResizable() : false >> >> On 28/06/2018 05:54, Manajit Halder wrote: >>> Hi Sergey, >>> Thanks for your review comment. I have modified the fix to >>> incorporate your suggestions. >>> Please review the modified webrev: >>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >>> Regards, >>> Manajit >>>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov >>>> >>> > >>>> wrote: >>>> >>>> Hi, Manajit. >>>> There is one more inconsistency, I have tested it using the test for >>>> teh previous fix: UnfocusableMaximizedFrameResizablity.java >>>> >>>> In this case the window is zoomable(the green button is active, but >>>> does not work as expected): >>>> ???????frame.setFocusableWindowState(false); >>>> ???????frame.setResizable(true); >>>> >>>> In this case the window is not zoomable(the green button is inactive): >>>> ???????frame.setResizable(true); >>>> ???????frame.setFocusableWindowState(false); >>>> >>>> I suggest to update the testcase to cover all this cases which we >>>> found during review. >>>> >>>> On 21/06/2018 12:26, Manajit Halder wrote: >>>>> Hi Phil and Sergey, >>>>> I have changed the code as per your suggestions. Now window is >>>>> resized based on the following condition: >>>>> If window is non-focusable OR window is focusable but non-resizable >>>>> THEN window is made non-resizable. >>>>> Otherwise window is made resizable (when window is resizable and >>>>> focusable). >>>>> Please review the changes: >>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>>> Note: Fix was verified by running all the java/awt/ jtreg test >>>>> cases and by executing the reported JCK interactive test case. >>>>> Regards, >>>>> Manajit >>>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder >>>>>> > wrote: >>>>>> >>>>>> Hi Phil, >>>>>> >>>>>> Please find my answer inline to your comment. >>>>>> >>>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race >>>>>> > wrote: >>>>>>> >>>>>>> I would like to refer back to a comment you made in the previous fix >>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>>> >>>>>>> > It is not mentioned in the focus spec whether the unfocusable >>>>>>> maximized frames should be resizable or not. >>>>>>> >>>>>>> Yet there seems to be a JCK test that says it should not be >>>>>>> resizable ? >>>>>>> >>>>>>> Can you review the spec. again ? >>>>>>> JCK must have based the test on something .. else the test is not >>>>>>> valid. >>>>>> >>>>>> Yes, I checked FocusSpec.html and it?doesn?t specify anything >>>>>> about resizable behaviour of non-focusable Frame. >>>>>> >>>>>> The UnfocusableMaximizedFrameResizablity.java? test passes on >>>>>> Window and Linux and fails on Mac OS. >>>>>> Fix for issue?7158623 was done accordingly to make sure the >>>>>> behaviour is same on all platforms. >>>>>> >>>>>> If this behaviour is not correct then Window and Linux code should >>>>>> be changed accordingly so that all three platforms behave same. >>>>>> >>>>>>> >>>>>>> If we want that behaviour specified .. we should be specifying it .. >>>>>>> But I am not sure if it is actually enforceable on all window >>>>>>> managers / desktops. >>>>>>> >>>>>>> But I have the same issue with this fix as the previous one. >>>>>>> Perhaps not the fix, >>>>>>> but the explanation. The code being changed can't be understood >>>>>>> without seeing >>>>>>> the method it calls, and the native method it in turn calls. >>>>>>> >>>>>>> Can you provide a detailed explanation as to how this change >>>>>>> propagates down >>>>>>> and does the right thing ? >>>>>>> >>>>>> The call flow: >>>>>> >>>>>> updateFocusableWindowState() calls setStyleBits with style bits to >>>>>> be set on the window. >>>>>> setStyleBits() calls native method nativeSetNSWindowStyleBits. >>>>>> nativeSetNSWindowStyleBits passes mask and 0 as the second >>>>>> parameter in our case (for non-focusable windows). >>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits >>>>>> in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>>> >>>>>> My previous fix for issue 7158623 explains bits set on the window. >>>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>>> >>>>>> >>>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>>> >>>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | >>>>>>> ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>>> Changed the code as per the suggestion. Please review the modified >>>>>> code. >>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Kindly review the fix for JDK11. >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Fix: >>>>>>>> Frame is focusable: >>>>>>>> Retaining the existing frame resizable behaviour (Fixes the >>>>>>>> current issue). >>>>>>>> Frame is non-focusable: >>>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Jul 5 14:40:26 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 5 Jul 2018 17:40:26 +0300 Subject: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. In-Reply-To: <17ddc416-4d9d-4e1c-b3df-3601905fbccd@default> References: <15209466-11db-4269-bfb7-f69b893e3222@default> <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default> <4c0f4397-c2e7-44ea-931b-141566682eb5@default> <167f2070-9661-47b8-8161-85fa31a8dc54@default> <1d5c75d2-27c5-4594-b68e-c2230b42b47a@default> <23e54562-2461-4f6a-818f-4cd2b0efe676@default> <17ddc416-4d9d-4e1c-b3df-3601905fbccd@default> Message-ID: <67531de8-9c8f-c31e-9e88-23d8483593da@oracle.com> Hi, Krishna If I read the code in LWChoicePeer.java file correctly, then you can fix the problem by dropping the method below in JComboBoxDelegate class: /** * We should post ITEM_STATE_CHANGED event when the same element is * reselected. */ @Override public void setSelectedItem(final Object anObject) { Are you sure that storing the index of the selected element in XChoicePeer class is enough? Because the element itself at this index may change. On 04/07/2018 13:48, Krishna Addepalli wrote: > Hi Prasanta/Sergey, > > Could you review this ? > > @Ajit, Shashi ? Thanks for your review. > > Thanks, > > Krishna > > *From:* Ajit Ghaisas > *Sent:* Tuesday, July 3, 2018 3:31 PM > *To:* Krishna Addepalli ; Shashidhara > Veerabhadraiah ; > awt-dev at openjdk.java.net > *Subject:* RE: [12]RFR : JDK-8014503: AWT Choice > implementation should be made consistent across platforms. > > Hi Krishna, > > Thanks for the explanation. Changes look good. > > You will need a ?R? reviewer to review this though. > > Regards, > > Ajit > > *From:* Krishna Addepalli > *Sent:* Tuesday, July 03, 2018 2:20 PM > *To:* Ajit Ghaisas; Shashidhara Veerabhadraiah; awt-dev at openjdk.java.net > > *Subject:* RE: [12]RFR : JDK-8014503: AWT Choice > implementation should be made consistent across platforms. > > Hi Ajit, > > I don?t think we can use ?skipPostMessage? for this check for the > following reasons: > > 1.?skipPostMessage? is intended to filter out item unselected messages, > which are posted in case of JComboBox. > > 2.I need to store the previously selected index to compare against the > current index, and I?ll need to change the skipPostMessage to integer > type ? although doable, will be a maintenance headache. > > 3.As much as I have seen, skipPostMessage variable is restored to false > in the same function call (select and remove), whereas for > selectedIndex, this won?t be the case. > > 4.Also, remove function is not called from here, but from outside. So, > the state will clash, when I save the last selected index, and > immediately remove gets called. > > Hope this clarifies. > > Thanks, > > Krishna > > *From:* Ajit Ghaisas > *Sent:* Tuesday, July 3, 2018 1:15 PM > *To:* Shashidhara Veerabhadraiah >; Krishna Addepalli > >; > awt-dev at openjdk.java.net > *Subject:* RE: [12]RFR : JDK-8014503: AWT Choice > implementation should be made consistent across platforms. > > Can we use existing ?skipPostMessage? member for this check instead of > introducing additional member in LWChoicePeer class? > > *From:* Shashidhara Veerabhadraiah > *Sent:* Tuesday, July 03, 2018 12:16 PM > *To:* Krishna Addepalli; awt-dev at openjdk.java.net > > *Subject:* Re: [12]RFR : JDK-8014503: AWT Choice > implementation should be made consistent across platforms. > > Hi Krishna, The changes looks fine. > > Please don?t forget to add the bug id to the test before the push. And > add this bug JDK-8197810 ?as relate to? the current bug(in bug db). > > Thanks and regards, > > Shashi > > *From:* Krishna Addepalli > *Sent:* Tuesday, July 3, 2018 8:00 AM > *To:* Shashidhara Veerabhadraiah >; > awt-dev at openjdk.java.net > *Subject:* RE: [12]RFR : JDK-8014503: AWT Choice > implementation should be made consistent across platforms. > > Hi Shashi, > > Thanks for the review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8014503/webrev01/ > > As for the test, it has already been corrected and pushed in JDK-8197810. > > Thanks, > > Krishna > > *From:* Shashidhara Veerabhadraiah > *Sent:* Monday, July 2, 2018 11:30 PM > *To:* Krishna Addepalli >; awt-dev at openjdk.java.net > > *Subject:* RE: [12]RFR : JDK-8014503: AWT Choice > implementation should be made consistent across platforms. > > Hi Krishna, Below are the comments on the fix that you made. > > 1.Based on the getSelectedIndex(), I think the selectedIndex should be > initialized to -1. 0 seems to be a valid value. > > 2.A test may be required to test out the behavior because as per the > comment in the bug, the test SelecteCurrentItemTest.html should fail now > on all platforms since the passing platforms software was changed. > > Other than that the changes looks fine. > > Thanks and regards, > shashi > > *From:* Krishna Addepalli > *Sent:* Monday, July 2, 2018 3:10 PM > *To:* awt-dev at openjdk.java.net > *Subject:* [12]RFR : JDK-8014503: AWT Choice implementation > should be made consistent across platforms. > > Hi All, > > Please review a fix for JDK-8014503: > https://bugs.openjdk.java.net/browse/JDK-8014503 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ > > On Windows, the default behavior has been changed to not send an > ItemEvent, if the same item is selected again, whereas this was not > changed for Mac and Linux. > > This fix changes that behavior, and makes it consistent for all the > three platforms. > > Thanks, > > Krishna > -- Best regards, Sergey. From philip.race at oracle.com Thu Jul 5 22:13:00 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 5 Jul 2018 15:13:00 -0700 Subject: [11] Review Request: 8201611 Broken links in java.desktop javadoc In-Reply-To: <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com> References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com> Message-ID: <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com> Actually .. I've found that Component.java uses a relative link for doc-files in all other cases. I think that you should actually just remove the usage of @docRoot to make it consistent. It is more logical for this case. -phil. On 07/02/2018 10:16 AM, Phil Race wrote: > > OK, +1 > > -phil. > > On 07/02/2018 10:09 AM, Sergey Bylokhov wrote: >> On 02/07/2018 09:29, Phil Race wrote: >>> Not exactly, it was after javadoc was changed under >>> https://bugs.openjdk.java.net/browse/JDK-8195795 >> >> So modules are added to the path. >> >>> This one seems to be different than the other two .. no mention of >>> the module >>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html >> >> >> >> The html tag was replaced by the direct javadoc link to the java >> class. >> >>> Why is it correct ? >>> >>> -phil. >>> >>> >>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk11. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 >>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 >>>> >>>> Some links in the javadoc became broken after modules were added. >>>> >>> >> >> > From philip.race at oracle.com Thu Jul 5 22:18:00 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 5 Jul 2018 15:18:00 -0700 Subject: RFR: 8205646: Broken link in jdk.jsobject Message-ID: A simple doc bug caused by javadoc now requiring uses of docRoot to include the module. bug : https://bugs.openjdk.java.net/browse/JDK-8205646 Fix : diff --git a/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java b/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java --- a/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java +++ b/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java @@ -151,7 +151,7 @@ * JavaScript engine or if applet is {@code null} * * @deprecated The Applet API is deprecated. See the - * + * * java.applet package documentation for further information. */ -phil. From manajit.halder at oracle.com Fri Jul 6 13:37:58 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 6 Jul 2018 19:07:58 +0530 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> Message-ID: Hi Sergey, Checked the behaviour of setCanFullscreen() and found the test was failing. The window was "FULLSCREENABLE? when it was not focusable. Changed the code to fix this issue. After fix the window (JFrame) is not ?FULLSCREENABLE? when it is not resizable and non-focusable. Please review the changes: http://cr.openjdk.java.net/~mhalder/8204860/webrev.05/ Regards, Manajit > On 04-Jul-2018, at 5:52 PM, Sergey Bylokhov wrote: > > Hi, Manajit. > Can you please recheck the usage of setCanFullscreen() method at line 691. Is it possible to make the window "FULLSCREENABLE" when it is not focusable? I guess it can be checked by something like this: > > > frame.setFocusableWindowState(false); > frame.setResizable(true); > v1 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); > frame.setVisible(false); > frame.setVisible(true); > v2 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); > if(!v1.equals(v2)) Error(); > > > On 02/07/2018 20:12, Manajit Halder wrote: >> Hi Sergey, >> Thanks for your review comment. Code changed as per your suggestion. >> Please review the changes: >> http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ >> Regards, >> Manajit >>> On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov >> wrote: >>> >>> Hi, Manajit >>> Can you please simplify such new code in the fix: >>> (!isFocusable || !isResizable) ? false : true >>> >>> "false: true" may be omitted. >>> >>> Also please split this new long line: >>> 486 return (target instanceof Frame) ? ((Frame)target).isResizable() : ((target instanceof Dialog) ? ((Dialog)target).isResizable() : false >>> >>> On 28/06/2018 05:54, Manajit Halder wrote: >>>> Hi Sergey, >>>> Thanks for your review comment. I have modified the fix to incorporate your suggestions. >>>> Please review the modified webrev: >>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >>>> Regards, >>>> Manajit >>>>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov >>> wrote: >>>>> >>>>> Hi, Manajit. >>>>> There is one more inconsistency, I have tested it using the test for teh previous fix: UnfocusableMaximizedFrameResizablity.java >>>>> >>>>> In this case the window is zoomable(the green button is active, but does not work as expected): >>>>> frame.setFocusableWindowState(false); >>>>> frame.setResizable(true); >>>>> >>>>> In this case the window is not zoomable(the green button is inactive): >>>>> frame.setResizable(true); >>>>> frame.setFocusableWindowState(false); >>>>> >>>>> I suggest to update the testcase to cover all this cases which we found during review. >>>>> >>>>> On 21/06/2018 12:26, Manajit Halder wrote: >>>>>> Hi Phil and Sergey, >>>>>> I have changed the code as per your suggestions. Now window is resized based on the following condition: >>>>>> If window is non-focusable OR window is focusable but non-resizable THEN window is made non-resizable. >>>>>> Otherwise window is made resizable (when window is resizable and focusable). >>>>>> Please review the changes: >>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>>>> Note: Fix was verified by running all the java/awt/ jtreg test cases and by executing the reported JCK interactive test case. >>>>>> Regards, >>>>>> Manajit >>>>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder > wrote: >>>>>>> >>>>>>> Hi Phil, >>>>>>> >>>>>>> Please find my answer inline to your comment. >>>>>>> >>>>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race > wrote: >>>>>>>> >>>>>>>> I would like to refer back to a comment you made in the previous fix >>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>>>> >>>>>>>> > It is not mentioned in the focus spec whether the unfocusable maximized frames should be resizable or not. >>>>>>>> >>>>>>>> Yet there seems to be a JCK test that says it should not be resizable ? >>>>>>>> >>>>>>>> Can you review the spec. again ? >>>>>>>> JCK must have based the test on something .. else the test is not valid. >>>>>>> >>>>>>> Yes, I checked FocusSpec.html and it doesn?t specify anything about resizable behaviour of non-focusable Frame. >>>>>>> >>>>>>> The UnfocusableMaximizedFrameResizablity.java test passes on Window and Linux and fails on Mac OS. >>>>>>> Fix for issue 7158623 was done accordingly to make sure the behaviour is same on all platforms. >>>>>>> >>>>>>> If this behaviour is not correct then Window and Linux code should be changed accordingly so that all three platforms behave same. >>>>>>> >>>>>>>> >>>>>>>> If we want that behaviour specified .. we should be specifying it .. >>>>>>>> But I am not sure if it is actually enforceable on all window managers / desktops. >>>>>>>> >>>>>>>> But I have the same issue with this fix as the previous one. Perhaps not the fix, >>>>>>>> but the explanation. The code being changed can't be understood without seeing >>>>>>>> the method it calls, and the native method it in turn calls. >>>>>>>> >>>>>>>> Can you provide a detailed explanation as to how this change propagates down >>>>>>>> and does the right thing ? >>>>>>>> >>>>>>> The call flow: >>>>>>> >>>>>>> updateFocusableWindowState() calls setStyleBits with style bits to be set on the window. >>>>>>> setStyleBits() calls native method nativeSetNSWindowStyleBits. nativeSetNSWindowStyleBits passes mask and 0 as the second parameter in our case (for non-focusable windows). >>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>>>> >>>>>>> My previous fix for issue 7158623 explains bits set on the window. >>>>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>>>> >>>>>>> >>>>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>>>> >>>>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>>>> Changed the code as per the suggestion. Please review the modified code. >>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>>>> >>>>>>> Regards, >>>>>>> Manajit >>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Kindly review the fix for JDK11. >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>>>> >>>>>>>>> Fix: >>>>>>>>> Frame is focusable: >>>>>>>>> Retaining the existing frame resizable behaviour (Fixes the current issue). >>>>>>>>> Frame is non-focusable: >>>>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Manajit >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 6 15:00:56 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Jul 2018 18:00:56 +0300 Subject: [11] Review Request: 8201611 Broken links in java.desktop javadoc In-Reply-To: <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com> References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com> <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com> Message-ID: <5b2933c2-2b28-cbc9-31db-83374123062e@oracle.com> On 06/07/2018 01:13, Phil Race wrote: > Actually .. I've found that Component.java uses a relative link for > doc-files in all other cases. > I think that you should actually just remove the usage of @docRoot to > make it consistent. > It is more logical for this case. In this method the "@docRoot" cannot be removed(it was added there intentionally), because this method is overridden by some of our classes where the relative link does not work. > > -phil. > > On 07/02/2018 10:16 AM, Phil Race wrote: >> >> OK, +1 >> >> -phil. >> >> On 07/02/2018 10:09 AM, Sergey Bylokhov wrote: >>> On 02/07/2018 09:29, Phil Race wrote: >>>> Not exactly, it was after javadoc was changed under >>>> https://bugs.openjdk.java.net/browse/JDK-8195795 >>> >>> So modules are added to the path. >>> >>>> This one seems to be different than the other two .. no mention of >>>> the module >>>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html >>> >>> >>> >>> >>> The html tag was replaced by the direct javadoc link to the java >>> class. >>> >>>> Why is it correct ? >>>> >>>> -phil. >>>> >>>> >>>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk11. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 >>>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 >>>>> >>>>> Some links in the javadoc became broken after modules were added. >>>>> >>>> >>> >>> >> > -- Best regards, Sergey. From philip.race at oracle.com Fri Jul 6 15:28:26 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 6 Jul 2018 08:28:26 -0700 Subject: [11] Review Request: 8201611 Broken links in java.desktop javadoc In-Reply-To: <5b2933c2-2b28-cbc9-31db-83374123062e@oracle.com> References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com> <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com> <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com> <5b2933c2-2b28-cbc9-31db-83374123062e@oracle.com> Message-ID: <8535476D-33AD-497F-A819-B58AB06B40B7@oracle.com> Oh. Ok. Tricky! -Phil. > On Jul 6, 2018, at 8:00 AM, Sergey Bylokhov wrote: > >> On 06/07/2018 01:13, Phil Race wrote: >> Actually .. I've found that Component.java uses a relative link for doc-files in all other cases. >> I think that you should actually just remove the usage of @docRoot to make it consistent. >> It is more logical for this case. > > In this method the "@docRoot" cannot be removed(it was added there intentionally), because this method is overridden by some of our classes where the relative link does not work. > >> -phil. >>> On 07/02/2018 10:16 AM, Phil Race wrote: >>> >>> OK, +1 >>> >>> -phil. >>> >>>> On 07/02/2018 10:09 AM, Sergey Bylokhov wrote: >>>>> On 02/07/2018 09:29, Phil Race wrote: >>>>> Not exactly, it was after javadoc was changed under >>>>> https://bugs.openjdk.java.net/browse/JDK-8195795 >>>> >>>> So modules are added to the path. >>>> >>>>> This one seems to be different than the other two .. no mention of the module >>>>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html >>>> >>>> >>>> >>>> >>>> The html tag was replaced by the direct javadoc link to the java class. >>>> >>>>> Why is it correct ? >>>>> >>>>> -phil. >>>>> >>>>> >>>>>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for jdk11. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611 >>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00 >>>>>> >>>>>> Some links in the javadoc became broken after modules were added. >>>>>> >>>>> >>>> >>>> >>> > > > -- > Best regards, Sergey. From philip.race at oracle.com Fri Jul 6 20:37:50 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 6 Jul 2018 13:37:50 -0700 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> Message-ID: <8752d347-c887-204c-0c84-5e25f099e37b@oracle.com> +1 from me. -phil. On 07/06/2018 06:37 AM, Manajit Halder wrote: > Hi Sergey, > > Checked the behaviour of setCanFullscreen() and found the test was > failing. The window was "FULLSCREENABLE? when it was not focusable. > Changed the code to fix this issue. After fix the window (JFrame) is > not ?FULLSCREENABLE? when it is not resizable and non-focusable. > > Please review the changes: > http://cr.openjdk.java.net/~mhalder/8204860/webrev.05/ > > > Regards, > Manajit > >> On 04-Jul-2018, at 5:52 PM, Sergey Bylokhov >> > wrote: >> >> Hi, Manajit. >> Can you please recheck the usage of setCanFullscreen() method at line >> 691. Is it possible to make the window "FULLSCREENABLE" when it is >> not focusable? I guess it can be checked by something like this: >> >> >> frame.setFocusableWindowState(false); >> frame.setResizable(true); >> v1 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >> frame.setVisible(false); >> frame.setVisible(true); >> v2 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >> if(!v1.equals(v2)) Error(); >> >> >> On 02/07/2018 20:12, Manajit Halder wrote: >>> Hi Sergey, >>> Thanks for your review comment. Code changed as per your suggestion. >>> Please review the changes: >>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ >>> >>> Regards, >>> Manajit >>>> On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov >>>> >>> > >>>> wrote: >>>> >>>> Hi, Manajit >>>> Can you please simplify such new code in the fix: >>>> (!isFocusable || !isResizable) ? false : true >>>> >>>> "false: true" may be omitted. >>>> >>>> Also please split this new long line: >>>> 486 return (target instanceof Frame) ? >>>> ((Frame)target).isResizable() : ((target instanceof Dialog) ? >>>> ((Dialog)target).isResizable() : false >>>> >>>> On 28/06/2018 05:54, Manajit Halder wrote: >>>>> Hi Sergey, >>>>> Thanks for your review comment. I have modified the fix to >>>>> incorporate your suggestions. >>>>> Please review the modified webrev: >>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >>>>> >>>>> Regards, >>>>> Manajit >>>>>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, Manajit. >>>>>> There is one more inconsistency, I have tested it using the test >>>>>> for teh previous fix: UnfocusableMaximizedFrameResizablity.java >>>>>> >>>>>> In this case the window is zoomable(the green button is active, >>>>>> but does not work as expected): >>>>>> frame.setFocusableWindowState(false); >>>>>> frame.setResizable(true); >>>>>> >>>>>> In this case the window is not zoomable(the green button is >>>>>> inactive): >>>>>> frame.setResizable(true); >>>>>> frame.setFocusableWindowState(false); >>>>>> >>>>>> I suggest to update the testcase to cover all this cases which we >>>>>> found during review. >>>>>> >>>>>> On 21/06/2018 12:26, Manajit Halder wrote: >>>>>>> Hi Phil and Sergey, >>>>>>> I have changed the code as per your suggestions. Now window is >>>>>>> resized based on the following condition: >>>>>>> If window is non-focusable OR window is focusable but >>>>>>> non-resizable THEN window is made non-resizable. >>>>>>> Otherwise window is made resizable (when window is resizable and >>>>>>> focusable). >>>>>>> Please review the changes: >>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>>>>> >>>>>>> Note: Fix was verified by running all the java/awt/ jtreg test >>>>>>> cases and by executing the reported JCK interactive test case. >>>>>>> Regards, >>>>>>> Manajit >>>>>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> Please find my answer inline to your comment. >>>>>>>> >>>>>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> I would like to refer back to a comment you made in the >>>>>>>>> previous fix >>>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>>>>> >>>>>>>>> > It is not mentioned in the focus spec whether the >>>>>>>>> unfocusable maximized frames should be resizable or not. >>>>>>>>> >>>>>>>>> Yet there seems to be a JCK test that says it should not be >>>>>>>>> resizable ? >>>>>>>>> >>>>>>>>> Can you review the spec. again ? >>>>>>>>> JCK must have based the test on something .. else the test is >>>>>>>>> not valid. >>>>>>>> >>>>>>>> Yes, I checked FocusSpec.html and it doesn?t specify anything >>>>>>>> about resizable behaviour of non-focusable Frame. >>>>>>>> >>>>>>>> The UnfocusableMaximizedFrameResizablity.java test passes on >>>>>>>> Window and Linux and fails on Mac OS. >>>>>>>> Fix for issue 7158623 was done accordingly to make sure the >>>>>>>> behaviour is same on all platforms. >>>>>>>> >>>>>>>> If this behaviour is not correct then Window and Linux code >>>>>>>> should be changed accordingly so that all three platforms >>>>>>>> behave same. >>>>>>>> >>>>>>>>> >>>>>>>>> If we want that behaviour specified .. we should be specifying >>>>>>>>> it .. >>>>>>>>> But I am not sure if it is actually enforceable on all window >>>>>>>>> managers / desktops. >>>>>>>>> >>>>>>>>> But I have the same issue with this fix as the previous one. >>>>>>>>> Perhaps not the fix, >>>>>>>>> but the explanation. The code being changed can't be >>>>>>>>> understood without seeing >>>>>>>>> the method it calls, and the native method it in turn calls. >>>>>>>>> >>>>>>>>> Can you provide a detailed explanation as to how this change >>>>>>>>> propagates down >>>>>>>>> and does the right thing ? >>>>>>>>> >>>>>>>> The call flow: >>>>>>>> >>>>>>>> updateFocusableWindowState() calls setStyleBits with style bits >>>>>>>> to be set on the window. >>>>>>>> setStyleBits() calls native method nativeSetNSWindowStyleBits. >>>>>>>> nativeSetNSWindowStyleBits passes mask and 0 as the second >>>>>>>> parameter in our case (for non-focusable windows). >>>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits >>>>>>>> in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>>>>> >>>>>>>> My previous fix for issue 7158623 explains bits set on the window. >>>>>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>>>>> >>>>>>>> >>>>>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>>>>> >>>>>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | >>>>>>>>> ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>>>>> Changed the code as per the suggestion. Please review the >>>>>>>> modified code. >>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Kindly review the fix for JDK11. >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fix: >>>>>>>>>> Frame is focusable: >>>>>>>>>> Retaining the existing frame resizable behaviour (Fixes the >>>>>>>>>> current issue). >>>>>>>>>> Frame is non-focusable: >>>>>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Manajit >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Jul 9 12:44:38 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Jul 2018 15:44:38 +0300 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> Message-ID: <46b3a600-e111-5f9e-91de-5c296be7c160@oracle.com> Hi, Manajit. Did you run the test on other platforms? I am not sure, but look like the line below can throw npe: if(!prop1.equals(prop2)) { On 06/07/2018 16:37, Manajit Halder wrote: > Hi Sergey, > > Checked the behaviour of setCanFullscreen() and found the test was > failing. The window was "FULLSCREENABLE? when it was not focusable. > Changed the code to fix this issue. After fix the window (JFrame) is not > ?FULLSCREENABLE? when it is not resizable and non-focusable. > > Please review the changes: > http://cr.openjdk.java.net/~mhalder/8204860/webrev.05/ > > > Regards, > Manajit > >> On 04-Jul-2018, at 5:52 PM, Sergey Bylokhov >> > wrote: >> >> Hi, Manajit. >> Can you please recheck the usage of setCanFullscreen() method at line >> 691. Is it possible to make the window "FULLSCREENABLE" when it is not >> focusable? I guess it can be checked by something like this: >> >> >> frame.setFocusableWindowState(false); >> frame.setResizable(true); >> v1 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >> frame.setVisible(false); >> frame.setVisible(true); >> v2 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >> if(!v1.equals(v2)) Error(); >> >> >> On 02/07/2018 20:12, Manajit Halder wrote: >>> Hi Sergey, >>> Thanks for your review comment. Code changed as per your suggestion. >>> Please review the changes: >>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ >>> >>> Regards, >>> Manajit >>>> On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov >>>> >>> > >>>> wrote: >>>> >>>> Hi, Manajit >>>> Can you please simplify such new code in the fix: >>>> (!isFocusable || !isResizable) ? false : true >>>> >>>> "false: true" may be omitted. >>>> >>>> Also please split this new long line: >>>> 486 return (target instanceof Frame) ? ((Frame)target).isResizable() >>>> : ((target instanceof Dialog) ? ((Dialog)target).isResizable() : false >>>> >>>> On 28/06/2018 05:54, Manajit Halder wrote: >>>>> Hi Sergey, >>>>> Thanks for your review comment. I have modified the fix to >>>>> incorporate your suggestions. >>>>> Please review the modified webrev: >>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >>>>> >>>>> Regards, >>>>> Manajit >>>>>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, Manajit. >>>>>> There is one more inconsistency, I have tested it using the test >>>>>> for teh previous fix: UnfocusableMaximizedFrameResizablity.java >>>>>> >>>>>> In this case the window is zoomable(the green button is active, >>>>>> but does not work as expected): >>>>>> ???????frame.setFocusableWindowState(false); >>>>>> ???????frame.setResizable(true); >>>>>> >>>>>> In this case the window is not zoomable(the green button is inactive): >>>>>> ???????frame.setResizable(true); >>>>>> ???????frame.setFocusableWindowState(false); >>>>>> >>>>>> I suggest to update the testcase to cover all this cases which we >>>>>> found during review. >>>>>> >>>>>> On 21/06/2018 12:26, Manajit Halder wrote: >>>>>>> Hi Phil and Sergey, >>>>>>> I have changed the code as per your suggestions. Now window is >>>>>>> resized based on the following condition: >>>>>>> If window is non-focusable OR window is focusable but >>>>>>> non-resizable THEN window is made non-resizable. >>>>>>> Otherwise window is made resizable (when window is resizable and >>>>>>> focusable). >>>>>>> Please review the changes: >>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>>>>> >>>>>>> Note: Fix was verified by running all the java/awt/ jtreg test >>>>>>> cases and by executing the reported JCK interactive test case. >>>>>>> Regards, >>>>>>> Manajit >>>>>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> Please find my answer inline to your comment. >>>>>>>> >>>>>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> I would like to refer back to a comment you made in the >>>>>>>>> previous fix >>>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>>>>> >>>>>>>>> > It is not mentioned in the focus spec whether the unfocusable >>>>>>>>> maximized frames should be resizable or not. >>>>>>>>> >>>>>>>>> Yet there seems to be a JCK test that says it should not be >>>>>>>>> resizable ? >>>>>>>>> >>>>>>>>> Can you review the spec. again ? >>>>>>>>> JCK must have based the test on something .. else the test is >>>>>>>>> not valid. >>>>>>>> >>>>>>>> Yes, I checked FocusSpec.html and it?doesn?t specify anything >>>>>>>> about resizable behaviour of non-focusable Frame. >>>>>>>> >>>>>>>> The UnfocusableMaximizedFrameResizablity.java? test passes on >>>>>>>> Window and Linux and fails on Mac OS. >>>>>>>> Fix for issue?7158623 was done accordingly to make sure the >>>>>>>> behaviour is same on all platforms. >>>>>>>> >>>>>>>> If this behaviour is not correct then Window and Linux code >>>>>>>> should be changed accordingly so that all three platforms behave >>>>>>>> same. >>>>>>>> >>>>>>>>> >>>>>>>>> If we want that behaviour specified .. we should be specifying >>>>>>>>> it .. >>>>>>>>> But I am not sure if it is actually enforceable on all window >>>>>>>>> managers / desktops. >>>>>>>>> >>>>>>>>> But I have the same issue with this fix as the previous one. >>>>>>>>> Perhaps not the fix, >>>>>>>>> but the explanation. The code being changed can't be understood >>>>>>>>> without seeing >>>>>>>>> the method it calls, and the native method it in turn calls. >>>>>>>>> >>>>>>>>> Can you provide a detailed explanation as to how this change >>>>>>>>> propagates down >>>>>>>>> and does the right thing ? >>>>>>>>> >>>>>>>> The call flow: >>>>>>>> >>>>>>>> updateFocusableWindowState() calls setStyleBits with style bits >>>>>>>> to be set on the window. >>>>>>>> setStyleBits() calls native method nativeSetNSWindowStyleBits. >>>>>>>> nativeSetNSWindowStyleBits passes mask and 0 as the second >>>>>>>> parameter in our case (for non-focusable windows). >>>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits >>>>>>>> in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>>>>> >>>>>>>> My previous fix for issue 7158623 explains bits set on the window. >>>>>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>>>>> >>>>>>>> >>>>>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>>>>> >>>>>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | >>>>>>>>> ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>>>>> Changed the code as per the suggestion. Please review the >>>>>>>> modified code. >>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Kindly review the fix for JDK11. >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fix: >>>>>>>>>> Frame is focusable: >>>>>>>>>> Retaining the existing frame resizable behaviour (Fixes the >>>>>>>>>> current issue). >>>>>>>>>> Frame is non-focusable: >>>>>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Manajit >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Jul 9 13:03:08 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 9 Jul 2018 18:33:08 +0530 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: <46b3a600-e111-5f9e-91de-5c296be7c160@oracle.com> References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> <46b3a600-e111-5f9e-91de-5c296be7c160@oracle.com> Message-ID: Also, I guess JFrame handling should be in EDT. Regards Prasanta On 7/9/2018 6:14 PM, Sergey Bylokhov wrote: > Hi, Manajit. > Did you run the test on other platforms? > I am not sure, but look like the line below can throw npe: > if(!prop1.equals(prop2)) { > > On 06/07/2018 16:37, Manajit Halder wrote: >> Hi Sergey, >> >> Checked the behaviour of setCanFullscreen() and found the test was >> failing. The window was "FULLSCREENABLE? when it was not focusable. >> Changed the code to fix this issue. After fix the window (JFrame) is >> not ?FULLSCREENABLE? when it is not resizable and non-focusable. >> >> Please review the changes: >> http://cr.openjdk.java.net/~mhalder/8204860/webrev.05/ >> >> >> Regards, >> Manajit >> >>> On 04-Jul-2018, at 5:52 PM, Sergey Bylokhov >>> > wrote: >>> >>> Hi, Manajit. >>> Can you please recheck the usage of setCanFullscreen() method at >>> line 691. Is it possible to make the window "FULLSCREENABLE" when it >>> is not focusable? I guess it can be checked by something like this: >>> >>> >>> frame.setFocusableWindowState(false); >>> frame.setResizable(true); >>> v1 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >>> frame.setVisible(false); >>> frame.setVisible(true); >>> v2 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >>> if(!v1.equals(v2)) Error(); >>> >>> >>> On 02/07/2018 20:12, Manajit Halder wrote: >>>> Hi Sergey, >>>> Thanks for your review comment. Code changed as per your suggestion. >>>> Please review the changes: >>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ >>>> >>>> Regards, >>>> Manajit >>>>> On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi, Manajit >>>>> Can you please simplify such new code in the fix: >>>>> (!isFocusable || !isResizable) ? false : true >>>>> >>>>> "false: true" may be omitted. >>>>> >>>>> Also please split this new long line: >>>>> 486 return (target instanceof Frame) ? >>>>> ((Frame)target).isResizable() : ((target instanceof Dialog) ? >>>>> ((Dialog)target).isResizable() : false >>>>> >>>>> On 28/06/2018 05:54, Manajit Halder wrote: >>>>>> Hi Sergey, >>>>>> Thanks for your review comment. I have modified the fix to >>>>>> incorporate your suggestions. >>>>>> Please review the modified webrev: >>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>>>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, Manajit. >>>>>>> There is one more inconsistency, I have tested it using the test >>>>>>> for teh previous fix: UnfocusableMaximizedFrameResizablity.java >>>>>>> >>>>>>> In this case the window is zoomable(the green button is active, >>>>>>> but does not work as expected): >>>>>>> ???????frame.setFocusableWindowState(false); >>>>>>> ???????frame.setResizable(true); >>>>>>> >>>>>>> In this case the window is not zoomable(the green button is >>>>>>> inactive): >>>>>>> ???????frame.setResizable(true); >>>>>>> ???????frame.setFocusableWindowState(false); >>>>>>> >>>>>>> I suggest to update the testcase to cover all this cases which >>>>>>> we found during review. >>>>>>> >>>>>>> On 21/06/2018 12:26, Manajit Halder wrote: >>>>>>>> Hi Phil and Sergey, >>>>>>>> I have changed the code as per your suggestions. Now window is >>>>>>>> resized based on the following condition: >>>>>>>> If window is non-focusable OR window is focusable but >>>>>>>> non-resizable THEN window is made non-resizable. >>>>>>>> Otherwise window is made resizable (when window is resizable >>>>>>>> and focusable). >>>>>>>> Please review the changes: >>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>>>>>> >>>>>>>> Note: Fix was verified by running all the java/awt/ jtreg test >>>>>>>> cases and by executing the reported JCK interactive test case. >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> Please find my answer inline to your comment. >>>>>>>>> >>>>>>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> I would like to refer back to a comment you made in the >>>>>>>>>> previous fix >>>>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > It is not mentioned in the focus spec whether the >>>>>>>>>> unfocusable maximized frames should be resizable or not. >>>>>>>>>> >>>>>>>>>> Yet there seems to be a JCK test that says it should not be >>>>>>>>>> resizable ? >>>>>>>>>> >>>>>>>>>> Can you review the spec. again ? >>>>>>>>>> JCK must have based the test on something .. else the test is >>>>>>>>>> not valid. >>>>>>>>> >>>>>>>>> Yes, I checked FocusSpec.html and it?doesn?t specify anything >>>>>>>>> about resizable behaviour of non-focusable Frame. >>>>>>>>> >>>>>>>>> The UnfocusableMaximizedFrameResizablity.java test passes on >>>>>>>>> Window and Linux and fails on Mac OS. >>>>>>>>> Fix for issue?7158623 was done accordingly to make sure the >>>>>>>>> behaviour is same on all platforms. >>>>>>>>> >>>>>>>>> If this behaviour is not correct then Window and Linux code >>>>>>>>> should be changed accordingly so that all three platforms >>>>>>>>> behave same. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we want that behaviour specified .. we should be >>>>>>>>>> specifying it .. >>>>>>>>>> But I am not sure if it is actually enforceable on all window >>>>>>>>>> managers / desktops. >>>>>>>>>> >>>>>>>>>> But I have the same issue with this fix as the previous one. >>>>>>>>>> Perhaps not the fix, >>>>>>>>>> but the explanation. The code being changed can't be >>>>>>>>>> understood without seeing >>>>>>>>>> the method it calls, and the native method it in turn calls. >>>>>>>>>> >>>>>>>>>> Can you provide a detailed explanation as to how this change >>>>>>>>>> propagates down >>>>>>>>>> and does the right thing ? >>>>>>>>>> >>>>>>>>> The call flow: >>>>>>>>> >>>>>>>>> updateFocusableWindowState() calls setStyleBits with style >>>>>>>>> bits to be set on the window. >>>>>>>>> setStyleBits() calls native method nativeSetNSWindowStyleBits. >>>>>>>>> nativeSetNSWindowStyleBits passes mask and 0 as the second >>>>>>>>> parameter in our case (for non-focusable windows). >>>>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits >>>>>>>>> in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>>>>>> >>>>>>>>> My previous fix for issue 7158623 explains bits set on the >>>>>>>>> window. >>>>>>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>>>>>> >>>>>>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | >>>>>>>>>> ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>>>>>> Changed the code as per the suggestion. Please review the >>>>>>>>> modified code. >>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Manajit >>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Kindly review the fix for JDK11. >>>>>>>>>>> >>>>>>>>>>> Bug: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fix: >>>>>>>>>>> Frame is focusable: >>>>>>>>>>> Retaining the existing frame resizable behaviour (Fixes the >>>>>>>>>>> current issue). >>>>>>>>>>> Frame is non-focusable: >>>>>>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Manajit >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> >>> -- >>> Best regards, Sergey. >> > > From Sergey.Bylokhov at oracle.com Mon Jul 9 13:53:07 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Jul 2018 16:53:07 +0300 Subject: RFR: 8205646: Broken link in jdk.jsobject In-Reply-To: References: Message-ID: Looks fine. On 06/07/2018 01:18, Phil Race wrote: > A simple doc bug caused by javadoc now requiring uses of docRoot to > include the module. > > bug : https://bugs.openjdk.java.net/browse/JDK-8205646 > > Fix : > diff --git > a/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java > b/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java > --- a/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java > +++ b/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java > @@ -151,7 +151,7 @@ > ????? * JavaScript engine or if applet is {@code null} > ????? * > ????? * @deprecated? The Applet API is deprecated. See the > -???? * > +???? * > ????? * java.applet package documentation for further information. > ????? */ > > -phil. -- Best regards, Sergey. From manajit.halder at oracle.com Tue Jul 10 11:33:13 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 10 Jul 2018 17:03:13 +0530 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> <46b3a600-e111-5f9e-91de-5c296be7c160@oracle.com> Message-ID: <890E542C-CA76-4FCC-8497-B61E65F9863F@oracle.com> Hi Sergey and Prasanta, Thanks for your comment. The fullscreen test (i.e. case 3 in the test) is made to run only on Mac as the full screen property (?apple.awt.fullscreenable?) is specific to Mac OS. Please review the updated webrev: http://cr.openjdk.java.net/~mhalder/8204860/webrev.06/ Regards, Manajit > On 09-Jul-2018, at 6:33 PM, Prasanta Sadhukhan wrote: > > Also, I guess JFrame handling should be in EDT. > > Regards > Prasanta > On 7/9/2018 6:14 PM, Sergey Bylokhov wrote: >> Hi, Manajit. >> Did you run the test on other platforms? >> I am not sure, but look like the line below can throw npe: >> if(!prop1.equals(prop2)) { >> >> On 06/07/2018 16:37, Manajit Halder wrote: >>> Hi Sergey, >>> >>> Checked the behaviour of setCanFullscreen() and found the test was failing. The window was "FULLSCREENABLE? when it was not focusable. >>> Changed the code to fix this issue. After fix the window (JFrame) is not ?FULLSCREENABLE? when it is not resizable and non-focusable. >>> >>> Please review the changes: >>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.05/ >>> >>> Regards, >>> Manajit >>> >>>> On 04-Jul-2018, at 5:52 PM, Sergey Bylokhov > wrote: >>>> >>>> Hi, Manajit. >>>> Can you please recheck the usage of setCanFullscreen() method at line 691. Is it possible to make the window "FULLSCREENABLE" when it is not focusable? I guess it can be checked by something like this: >>>> >>>> >>>> frame.setFocusableWindowState(false); >>>> frame.setResizable(true); >>>> v1 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >>>> frame.setVisible(false); >>>> frame.setVisible(true); >>>> v2 = frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >>>> if(!v1.equals(v2)) Error(); >>>> >>>> >>>> On 02/07/2018 20:12, Manajit Halder wrote: >>>>> Hi Sergey, >>>>> Thanks for your review comment. Code changed as per your suggestion. >>>>> Please review the changes: >>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ >>>>> Regards, >>>>> Manajit >>>>>> On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov > wrote: >>>>>> >>>>>> Hi, Manajit >>>>>> Can you please simplify such new code in the fix: >>>>>> (!isFocusable || !isResizable) ? false : true >>>>>> >>>>>> "false: true" may be omitted. >>>>>> >>>>>> Also please split this new long line: >>>>>> 486 return (target instanceof Frame) ? ((Frame)target).isResizable() : ((target instanceof Dialog) ? ((Dialog)target).isResizable() : false >>>>>> >>>>>> On 28/06/2018 05:54, Manajit Halder wrote: >>>>>>> Hi Sergey, >>>>>>> Thanks for your review comment. I have modified the fix to incorporate your suggestions. >>>>>>> Please review the modified webrev: >>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >>>>>>> Regards, >>>>>>> Manajit >>>>>>>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov > wrote: >>>>>>>> >>>>>>>> Hi, Manajit. >>>>>>>> There is one more inconsistency, I have tested it using the test for teh previous fix: UnfocusableMaximizedFrameResizablity.java >>>>>>>> >>>>>>>> In this case the window is zoomable(the green button is active, but does not work as expected): >>>>>>>> frame.setFocusableWindowState(false); >>>>>>>> frame.setResizable(true); >>>>>>>> >>>>>>>> In this case the window is not zoomable(the green button is inactive): >>>>>>>> frame.setResizable(true); >>>>>>>> frame.setFocusableWindowState(false); >>>>>>>> >>>>>>>> I suggest to update the testcase to cover all this cases which we found during review. >>>>>>>> >>>>>>>> On 21/06/2018 12:26, Manajit Halder wrote: >>>>>>>>> Hi Phil and Sergey, >>>>>>>>> I have changed the code as per your suggestions. Now window is resized based on the following condition: >>>>>>>>> If window is non-focusable OR window is focusable but non-resizable THEN window is made non-resizable. >>>>>>>>> Otherwise window is made resizable (when window is resizable and focusable). >>>>>>>>> Please review the changes: >>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>>>>>>> Note: Fix was verified by running all the java/awt/ jtreg test cases and by executing the reported JCK interactive test case. >>>>>>>>> Regards, >>>>>>>>> Manajit >>>>>>>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder > wrote: >>>>>>>>>> >>>>>>>>>> Hi Phil, >>>>>>>>>> >>>>>>>>>> Please find my answer inline to your comment. >>>>>>>>>> >>>>>>>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race > wrote: >>>>>>>>>>> >>>>>>>>>>> I would like to refer back to a comment you made in the previous fix >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>>>>>>> >>>>>>>>>>> > It is not mentioned in the focus spec whether the unfocusable maximized frames should be resizable or not. >>>>>>>>>>> >>>>>>>>>>> Yet there seems to be a JCK test that says it should not be resizable ? >>>>>>>>>>> >>>>>>>>>>> Can you review the spec. again ? >>>>>>>>>>> JCK must have based the test on something .. else the test is not valid. >>>>>>>>>> >>>>>>>>>> Yes, I checked FocusSpec.html and it doesn?t specify anything about resizable behaviour of non-focusable Frame. >>>>>>>>>> >>>>>>>>>> The UnfocusableMaximizedFrameResizablity.java test passes on Window and Linux and fails on Mac OS. >>>>>>>>>> Fix for issue 7158623 was done accordingly to make sure the behaviour is same on all platforms. >>>>>>>>>> >>>>>>>>>> If this behaviour is not correct then Window and Linux code should be changed accordingly so that all three platforms behave same. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If we want that behaviour specified .. we should be specifying it .. >>>>>>>>>>> But I am not sure if it is actually enforceable on all window managers / desktops. >>>>>>>>>>> >>>>>>>>>>> But I have the same issue with this fix as the previous one. Perhaps not the fix, >>>>>>>>>>> but the explanation. The code being changed can't be understood without seeing >>>>>>>>>>> the method it calls, and the native method it in turn calls. >>>>>>>>>>> >>>>>>>>>>> Can you provide a detailed explanation as to how this change propagates down >>>>>>>>>>> and does the right thing ? >>>>>>>>>>> >>>>>>>>>> The call flow: >>>>>>>>>> >>>>>>>>>> updateFocusableWindowState() calls setStyleBits with style bits to be set on the window. >>>>>>>>>> setStyleBits() calls native method nativeSetNSWindowStyleBits. nativeSetNSWindowStyleBits passes mask and 0 as the second parameter in our case (for non-focusable windows). >>>>>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>>>>>>> >>>>>>>>>> My previous fix for issue 7158623 explains bits set on the window. >>>>>>>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>>>>>>> >>>>>>>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>>>>>>> Changed the code as per the suggestion. Please review the modified code. >>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Manajit >>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Kindly review the fix for JDK11. >>>>>>>>>>>> >>>>>>>>>>>> Bug: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Fix: >>>>>>>>>>>> Frame is focusable: >>>>>>>>>>>> Retaining the existing frame resizable behaviour (Fixes the current issue). >>>>>>>>>>>> Frame is non-focusable: >>>>>>>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Manajit >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Jul 10 20:46:17 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Jul 2018 23:46:17 +0300 Subject: [11] Review Request: 8205973 Client jtreg ProblemList cleanup Message-ID: Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205973 Webrev: http://cr.openjdk.java.net/~serb/8205973/webrev.00 Non-existent tests were removed from the problem list + one typo fixed. -- Best regards, Sergey. From philip.race at oracle.com Tue Jul 10 21:35:40 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 10 Jul 2018 14:35:40 -0700 Subject: [11] Review Request: 8205973 Client jtreg ProblemList cleanup In-Reply-To: References: Message-ID: <23ce221c-1494-358e-8000-e300946c207a@oracle.com> +1 -phil On 07/10/2018 01:46 PM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205973 > Webrev: http://cr.openjdk.java.net/~serb/8205973/webrev.00 > > Non-existent tests were removed from the problem list > + one typo fixed. > From prasanta.sadhukhan at oracle.com Wed Jul 11 10:46:40 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 11 Jul 2018 16:16:40 +0530 Subject: [11] Review request for JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse In-Reply-To: <890E542C-CA76-4FCC-8497-B61E65F9863F@oracle.com> References: <6B14FB04-42F7-4344-80BA-67FF2EF3918A@oracle.com> <136c7a93-6753-247c-e52d-aef59293cd61@oracle.com> <327C83F7-8283-4A42-A329-80CF38F6ACBE@oracle.com> <0d5eda8c-45ea-84aa-4e87-7870b0403d0d@oracle.com> <2B4B97F2-00D3-4631-952B-7A5F9E3AC27B@oracle.com> <7833c760-319d-1b2b-3bf7-8d280731dc84@oracle.com> <46b3a600-e111-5f9e-91de-5c296be7c160@oracle.com> <890E542C-CA76-4FCC-8497-B61E65F9863F@oracle.com> Message-ID: <8b480696-2bc8-3c8f-f896-18313d58813a@oracle.com> +1 Regards Prasanta On 7/10/2018 5:03 PM, Manajit Halder wrote: > Hi Sergey and Prasanta, > > Thanks for your comment. The fullscreen test (i.e. case 3 in the test) > is made to run only on Mac as the full screen property > (?apple.awt.fullscreenable?) is specific to Mac OS. > Please review the updated webrev: > http://cr.openjdk.java.net/~mhalder/8204860/webrev.06/ > > > Regards, > Manajit > >> On 09-Jul-2018, at 6:33 PM, Prasanta Sadhukhan >> > > wrote: >> >> Also, I guess JFrame handling should be in EDT. >> >> Regards >> Prasanta >> On 7/9/2018 6:14 PM, Sergey Bylokhov wrote: >>> Hi, Manajit. >>> Did you run the test on other platforms? >>> I am not sure, but look like the line below can throw npe: >>> if(!prop1.equals(prop2)) { >>> >>> On 06/07/2018 16:37, Manajit Halder wrote: >>>> Hi Sergey, >>>> >>>> Checked the behaviour of setCanFullscreen() and found the test was >>>> failing. The window was "FULLSCREENABLE? when it was not focusable. >>>> Changed the code to fix this issue. After fix the window (JFrame) >>>> is not ?FULLSCREENABLE? when it is not resizable and non-focusable. >>>> >>>> Please review the changes: >>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.05/ >>>> >>>> >>>> >>>> Regards, >>>> Manajit >>>> >>>>> On 04-Jul-2018, at 5:52 PM, Sergey Bylokhov >>>>> >>>>> > wrote: >>>>> >>>>> Hi, Manajit. >>>>> Can you please recheck the usage of setCanFullscreen() method at >>>>> line 691. Is it possible to make the window "FULLSCREENABLE" when >>>>> it is not focusable? I guess it can be checked by something like this: >>>>> >>>>> >>>>> frame.setFocusableWindowState(false); >>>>> frame.setResizable(true); >>>>> v1 = >>>>> frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >>>>> frame.setVisible(false); >>>>> frame.setVisible(true); >>>>> v2 = >>>>> frame.getRootPane().getClientProperty("apple.awt.fullscreenable"); >>>>> if(!v1.equals(v2)) Error(); >>>>> >>>>> >>>>> On 02/07/2018 20:12, Manajit Halder wrote: >>>>>> Hi Sergey, >>>>>> Thanks for your review comment. Code changed as per your suggestion. >>>>>> Please review the changes: >>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.04/ >>>>>> >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>>>> On 01-Jul-2018, at 4:45 AM, Sergey Bylokhov >>>>>>> >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, Manajit >>>>>>> Can you please simplify such new code in the fix: >>>>>>> (!isFocusable || !isResizable) ? false : true >>>>>>> >>>>>>> "false: true" may be omitted. >>>>>>> >>>>>>> Also please split this new long line: >>>>>>> 486 return (target instanceof Frame) ? >>>>>>> ((Frame)target).isResizable() : ((target instanceof Dialog) ? >>>>>>> ((Dialog)target).isResizable() : false >>>>>>> >>>>>>> On 28/06/2018 05:54, Manajit Halder wrote: >>>>>>>> Hi Sergey, >>>>>>>> Thanks for your review comment. I have modified the fix to >>>>>>>> incorporate your suggestions. >>>>>>>> Please review the modified webrev: >>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.03/ >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>>>> On 26-Jun-2018, at 4:59 AM, Sergey Bylokhov >>>>>>>>> >>>>>>>> >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, Manajit. >>>>>>>>> There is one more inconsistency, I have tested it using the >>>>>>>>> test for teh previous fix: >>>>>>>>> UnfocusableMaximizedFrameResizablity.java >>>>>>>>> >>>>>>>>> In this case the window is zoomable(the green button is >>>>>>>>> active, but does not work as expected): >>>>>>>>> ???????frame.setFocusableWindowState(false); >>>>>>>>> ???????frame.setResizable(true); >>>>>>>>> >>>>>>>>> In this case the window is not zoomable(the green button is >>>>>>>>> inactive): >>>>>>>>> ???????frame.setResizable(true); >>>>>>>>> ???????frame.setFocusableWindowState(false); >>>>>>>>> >>>>>>>>> I suggest to update the testcase to cover all this cases which >>>>>>>>> we found during review. >>>>>>>>> >>>>>>>>> On 21/06/2018 12:26, Manajit Halder wrote: >>>>>>>>>> Hi Phil and Sergey, >>>>>>>>>> I have changed the code as per your suggestions. Now window >>>>>>>>>> is resized based on the following condition: >>>>>>>>>> If window is non-focusable OR window is focusable but >>>>>>>>>> non-resizable THEN window is made non-resizable. >>>>>>>>>> Otherwise window is made resizable (when window is resizable >>>>>>>>>> and focusable). >>>>>>>>>> Please review the changes: >>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.02/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note: Fix was verified by running all the java/awt/ jtreg >>>>>>>>>> test cases and by executing the reported JCK interactive test >>>>>>>>>> case. >>>>>>>>>> Regards, >>>>>>>>>> Manajit >>>>>>>>>>> On 20-Jun-2018, at 6:27 PM, Manajit Halder >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Phil, >>>>>>>>>>> >>>>>>>>>>> Please find my answer inline to your comment. >>>>>>>>>>> >>>>>>>>>>>> On 15-Jun-2018, at 11:24 PM, Phil Race >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> I would like to refer back to a comment you made in the >>>>>>>>>>>> previous fix >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-February/013626.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > It is not mentioned in the focus spec whether the >>>>>>>>>>>> unfocusable maximized frames should be resizable or not. >>>>>>>>>>>> >>>>>>>>>>>> Yet there seems to be a JCK test that says it should not be >>>>>>>>>>>> resizable ? >>>>>>>>>>>> >>>>>>>>>>>> Can you review the spec. again ? >>>>>>>>>>>> JCK must have based the test on something .. else the test >>>>>>>>>>>> is not valid. >>>>>>>>>>> >>>>>>>>>>> Yes, I checked FocusSpec.html and it?doesn?t specify >>>>>>>>>>> anything about resizable behaviour of non-focusable Frame. >>>>>>>>>>> >>>>>>>>>>> The UnfocusableMaximizedFrameResizablity.java test passes on >>>>>>>>>>> Window and Linux and fails on Mac OS. >>>>>>>>>>> Fix for issue?7158623 was done accordingly to make sure the >>>>>>>>>>> behaviour is same on all platforms. >>>>>>>>>>> >>>>>>>>>>> If this behaviour is not correct then Window and Linux code >>>>>>>>>>> should be changed accordingly so that all three platforms >>>>>>>>>>> behave same. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If we want that behaviour specified .. we should be >>>>>>>>>>>> specifying it .. >>>>>>>>>>>> But I am not sure if it is actually enforceable on all >>>>>>>>>>>> window managers / desktops. >>>>>>>>>>>> >>>>>>>>>>>> But I have the same issue with this fix as the previous >>>>>>>>>>>> one. Perhaps not the fix, >>>>>>>>>>>> but the explanation. The code being changed can't be >>>>>>>>>>>> understood without seeing >>>>>>>>>>>> the method it calls, and the native method it in turn calls. >>>>>>>>>>>> >>>>>>>>>>>> Can you provide a detailed explanation as to how this >>>>>>>>>>>> change propagates down >>>>>>>>>>>> and does the right thing ? >>>>>>>>>>>> >>>>>>>>>>> The call flow: >>>>>>>>>>> >>>>>>>>>>> updateFocusableWindowState() calls setStyleBits with style >>>>>>>>>>> bits to be set on the window. >>>>>>>>>>> setStyleBits() calls native method >>>>>>>>>>> nativeSetNSWindowStyleBits. nativeSetNSWindowStyleBits >>>>>>>>>>> passes mask and 0 as the second parameter in our case (for >>>>>>>>>>> non-focusable windows). >>>>>>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits >>>>>>>>>>> in AWTWindow.m generates newBits and applies it on the NSWindow. >>>>>>>>>>> >>>>>>>>>>> My previous fix for issue 7158623 explains bits set on the >>>>>>>>>>> window. >>>>>>>>>>> http://openjdk.5641.n7.nabble.com/lt-AWT-Dev-gt-Subject-lt-AWT-dev-gt-11-Review-request-for-JDK-7158623-macosx-Should-an-unfocusable-m-td326691.html#a329071 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> BTW stylistically - if this is the right fix - you could do : >>>>>>>>>>>> >>>>>>>>>>>> setStyleBits(SHOULD_BECOME_KEY | SHOULD_BECOME_MAIN | >>>>>>>>>>>> ((isFocusable) ? RESIZABLE : 0), isFocusable); >>>>>>>>>>> Changed the code as per the suggestion. Please review the >>>>>>>>>>> modified code. >>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Manajit >>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 06/14/2018 11:37 PM, Manajit Halder wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> Kindly review the fix for JDK11. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204860 >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8204860/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Fix: >>>>>>>>>>>>> Frame is focusable: >>>>>>>>>>>>> Retaining the existing frame resizable behaviour (Fixes >>>>>>>>>>>>> the current issue). >>>>>>>>>>>>> Frame is non-focusable: >>>>>>>>>>>>> Making the Frame non-resizable (Fix for issue 7158623). >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Manajit >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Jul 13 10:54:35 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Jul 2018 10:54:35 +0000 Subject: RFR(S): 8207233: Minor improvements of jdk C-coding Message-ID: <34185929affa44fa838a61ac26b1cfdb@sap.com> Hi, I ran coverity on the jdk11 jdk sources and want to propose the following fixes. I scanned the linux x86_64 build. Some issues are similar to previous parfait fixes (check for NULL). I also identified some issues I consider real problems. If you think some are tooo conservative, I'm happy to remove them. I posted this to core-libs-dev and awt-dev, if you think this should be discussed on other lists please tell me. http://cr.openjdk.java.net/~goetz/wr18/8207233-covJDK/01/ In detail: Real issues: ------------ transport.c Loop overruns the array, it iterates to 8. Only two iterations are intended. Unix.c getgroups can return -1. This is handled below, but not here. Return as for other errors. Useful code improvements. ------------------------- zip_util.c pmsg is compared to null above. Thus, don't dereference it unconditionally below. I would assume pmsg is always != NULL, so that the check above could as well be turned into a guarantee. This fix is more safe, though. fontpath.c This is a real error, but harmless as the same size is returned. pcsc.c If size is 0, mszReaders is not allocated, but accessed below. return if size is 0. Here, too, I would assume that one could turn the if(size) check into a guarantee, but this way it's more safe. ecl_muilt.c This block calls point_mul, which requires the kt.flag is initialized. unpack.cpp lo is checked for null. If it is null, the dereference below fails. Return if lo == Null similar as above. Alternatively, one could turn the if (lo != null) check into a guarantee. From joe.darcy at oracle.com Wed Jul 18 00:01:09 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 17 Jul 2018 17:01:09 -0700 Subject: JDK 12 RFR of JDK-8203263: Remove unnecessary throws clauses from serialization-related methods Message-ID: <5B4E8345.1010201@oracle.com> Hello, A few classes in awt and beans have writeObject methods declared to throw extra exception types. The serialization spec requires the following declaration for a writeObject method: private void writeObject(ObjectOutputStream stream) throws IOException; https://docs.oracle.com/javase/10/docs/specs/serialization/output.html#the-writeobject-method Declaring writeObject to throw additional exceptions is improper. Please review the change below to remove the extraneous throws clauses: http://cr.openjdk.java.net/~darcy/8203263.0/ Patch below. Thanks, -Joe --- old/src/java.desktop/share/classes/java/awt/Font.java 2018-07-17 16:45:12.772011569 -0700 +++ new/src/java.desktop/share/classes/java/awt/Font.java 2018-07-17 16:45:11.415333527 -0700 @@ -1895,8 +1895,7 @@ * @see #readObject(java.io.ObjectInputStream) */ private void writeObject(java.io.ObjectOutputStream s) - throws java.lang.ClassNotFoundException, - java.io.IOException + throws java.io.IOException { if (values != null) { synchronized(values) { --- old/src/java.desktop/share/classes/java/awt/MenuBar.java 2018-07-17 16:45:15.997623670 -0700 +++ new/src/java.desktop/share/classes/java/awt/MenuBar.java 2018-07-17 16:45:14.576913625 -0700 @@ -432,8 +432,7 @@ * @see #readObject(java.io.ObjectInputStream) */ private void writeObject(java.io.ObjectOutputStream s) - throws java.lang.ClassNotFoundException, - java.io.IOException + throws java.io.IOException { s.defaultWriteObject(); } --- old/src/java.desktop/share/classes/java/awt/font/TransformAttribute.java 2018-07-17 16:45:19.063155766 -0700 +++ new/src/java.desktop/share/classes/java/awt/font/TransformAttribute.java 2018-07-17 16:45:17.686467723 -0700 @@ -100,8 +100,7 @@ public static final TransformAttribute IDENTITY = new TransformAttribute(null); private void writeObject(java.io.ObjectOutputStream s) - throws java.lang.ClassNotFoundException, - java.io.IOException + throws java.io.IOException { // sigh -- 1.3 expects transform is never null, so we need to always write one out if (this.transform == null) { --- old/src/java.desktop/share/classes/java/awt/geom/AffineTransform.java 2018-07-17 16:45:22.040643859 -0700 +++ new/src/java.desktop/share/classes/java/awt/geom/AffineTransform.java 2018-07-17 16:45:20.635941814 -0700 @@ -3943,7 +3943,7 @@ private static final long serialVersionUID = 1330973210523860834L; private void writeObject(java.io.ObjectOutputStream s) - throws java.lang.ClassNotFoundException, java.io.IOException + throws java.io.IOException { s.defaultWriteObject(); } --- old/src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java 2018-07-17 16:45:25.334289961 -0700 +++ new/src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java 2018-07-17 16:45:23.973609919 -0700 @@ -998,7 +998,7 @@ * @param oos the ObjectOutputStream */ - private synchronized void writeObject(ObjectOutputStream oos) throws IOException, ClassNotFoundException { + private synchronized void writeObject(ObjectOutputStream oos) throws IOException { serializing = true; synchronized (BeanContext.globalHierarchyLock) { From philip.race at oracle.com Wed Jul 18 21:28:53 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 18 Jul 2018 14:28:53 -0700 Subject: [OpenJDK 2D-Dev] Request for re-reviewl: Backport of JDK-8150954: Taking screenshots on x11 composite desktop produce wrong result In-Reply-To: References: Message-ID: <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com> The review for the original fix was actually on awt-dev which probably was correct and so this should be there too. I hadn't seen the thread so had to go read it .. but it was so long ago I'd probably have had to re-read it anyway. But it was not so easy to find since it did not have the bug ID in the subject ! http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010742.html http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010996.html http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011370.html Since it is changed, yes, being able to point to this review thread is likely something the 8u-dev maintainers would ask you for. It looks OK to me although I don't grok why the order here in 8u 302 if (isXCompositeDisplay(awt_display, adata->awt_visInfo.screen) && 303 hasXCompositeOverlayExtension(awt_display)) is reversed from what you had in 9 : 309 if (hasXCompositeOverlayExtension(awt_display) && 310 isXCompositeDisplay(awt_display, adata->awt_visInfo.screen)) which looks more logical to me. -phil. On 07/18/2018 04:06 AM, Mario Torre wrote: > Hi all, > > I would like to backport the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8150954 > > To OpenJDK8 updates dev: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > The fix is mostly the same as the version that was committed in 9, > with the exception of the GTK path which is not available in 8. > > http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.00/ > > I'm not sure if this change needs a re-review from the 2d team, as I > think is trivial, but I would like some feedback nonetheless before > proposing to the updates mailing list, especially in regards to > testing the patch on some OS variant without the necessary libraries. > > Cheers, > Mario > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jul 18 22:17:39 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 18 Jul 2018 15:17:39 -0700 Subject: JDK 12 RFR of JDK-8203263: Remove unnecessary throws clauses from serialization-related methods In-Reply-To: <5B4E8345.1010201@oracle.com> References: <5B4E8345.1010201@oracle.com> Message-ID: <9464cb88-2bd2-155a-4b73-13176ca0ff1c@oracle.com> Looks fine to me. I checked Font and MenuBar in JDK 1.x sources and they were like that way back then, so why they declare the additional exception is lost in time .. -phil. On 07/17/2018 05:01 PM, Joseph D. Darcy wrote: > Hello, > > A few classes in awt and beans have writeObject methods declared to > throw extra exception types. The serialization spec requires the > following declaration for a writeObject method: > > private void writeObject(ObjectOutputStream stream) > throws IOException; > https://docs.oracle.com/javase/10/docs/specs/serialization/output.html#the-writeobject-method > > > Declaring writeObject to throw additional exceptions is improper. > > Please review the change below to remove the extraneous throws clauses: > > http://cr.openjdk.java.net/~darcy/8203263.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/src/java.desktop/share/classes/java/awt/Font.java 2018-07-17 > 16:45:12.772011569 -0700 > +++ new/src/java.desktop/share/classes/java/awt/Font.java 2018-07-17 > 16:45:11.415333527 -0700 > @@ -1895,8 +1895,7 @@ > * @see #readObject(java.io.ObjectInputStream) > */ > private void writeObject(java.io.ObjectOutputStream s) > - throws java.lang.ClassNotFoundException, > - java.io.IOException > + throws java.io.IOException > { > if (values != null) { > synchronized(values) { > --- old/src/java.desktop/share/classes/java/awt/MenuBar.java > 2018-07-17 16:45:15.997623670 -0700 > +++ new/src/java.desktop/share/classes/java/awt/MenuBar.java > 2018-07-17 16:45:14.576913625 -0700 > @@ -432,8 +432,7 @@ > * @see #readObject(java.io.ObjectInputStream) > */ > private void writeObject(java.io.ObjectOutputStream s) > - throws java.lang.ClassNotFoundException, > - java.io.IOException > + throws java.io.IOException > { > s.defaultWriteObject(); > } > --- > old/src/java.desktop/share/classes/java/awt/font/TransformAttribute.java > 2018-07-17 16:45:19.063155766 -0700 > +++ > new/src/java.desktop/share/classes/java/awt/font/TransformAttribute.java > 2018-07-17 16:45:17.686467723 -0700 > @@ -100,8 +100,7 @@ > public static final TransformAttribute IDENTITY = new > TransformAttribute(null); > > private void writeObject(java.io.ObjectOutputStream s) > - throws java.lang.ClassNotFoundException, > - java.io.IOException > + throws java.io.IOException > { > // sigh -- 1.3 expects transform is never null, so we need to > always write one out > if (this.transform == null) { > --- > old/src/java.desktop/share/classes/java/awt/geom/AffineTransform.java > 2018-07-17 16:45:22.040643859 -0700 > +++ > new/src/java.desktop/share/classes/java/awt/geom/AffineTransform.java > 2018-07-17 16:45:20.635941814 -0700 > @@ -3943,7 +3943,7 @@ > private static final long serialVersionUID = 1330973210523860834L; > > private void writeObject(java.io.ObjectOutputStream s) > - throws java.lang.ClassNotFoundException, java.io.IOException > + throws java.io.IOException > { > s.defaultWriteObject(); > } > --- > old/src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java > 2018-07-17 16:45:25.334289961 -0700 > +++ > new/src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java > 2018-07-17 16:45:23.973609919 -0700 > @@ -998,7 +998,7 @@ > * @param oos the ObjectOutputStream > */ > > - private synchronized void writeObject(ObjectOutputStream oos) > throws IOException, ClassNotFoundException { > + private synchronized void writeObject(ObjectOutputStream oos) > throws IOException { > serializing = true; > > synchronized (BeanContext.globalHierarchyLock) { > From joe.darcy at oracle.com Wed Jul 18 22:59:49 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 18 Jul 2018 15:59:49 -0700 Subject: JDK 12 RFR of JDK-8203263: Remove unnecessary throws clauses from serialization-related methods In-Reply-To: <9464cb88-2bd2-155a-4b73-13176ca0ff1c@oracle.com> References: <5B4E8345.1010201@oracle.com> <9464cb88-2bd2-155a-4b73-13176ca0ff1c@oracle.com> Message-ID: <5B4FC665.1020403@oracle.com> I suspect it might have been a copy-and-paste issue since the declaration for readObject has those two exception types: private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException; and (to date) we haven't have programmatic checks of this aspect of the serial-related declarations. Thanks, -Joe On 7/18/2018 3:17 PM, Phil Race wrote: > Looks fine to me. I checked Font and MenuBar in JDK 1.x sources and > they were > like that way back then, so why they declare the additional exception > is lost in time .. > > -phil. > > From neugens at redhat.com Thu Jul 19 12:33:32 2018 From: neugens at redhat.com (Mario Torre) Date: Thu, 19 Jul 2018 14:33:32 +0200 Subject: [OpenJDK 2D-Dev] Request for re-reviewl: Backport of JDK-8150954: Taking screenshots on x11 composite desktop produce wrong result In-Reply-To: <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com> References: <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com> Message-ID: On Wed, Jul 18, 2018 at 11:28 PM, Phil Race wrote: > The review for the original fix was actually on awt-dev which probably was > correct > and so this should be there too. Hi Phil, Thanks for the review, and I apologise for posting it to 2d-dev, that was out of habit :) > I hadn't seen the thread so had to go read it .. but it was so long ago I'd > probably have had to re-read it anyway. But it was not so easy to find > since it did not have the bug ID in the subject ! > http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010742.html > http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010996.html > http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011370.html Right, thanks again for linking the relevant thread information, I didn't post it as it was in the bug description, but indeed is a nice courtesy for the reviewer, I'll make sure to have it linked next time in the email request too. > Since it is changed, yes, being able to point to this review thread is > likely > something the 8u-dev maintainers would ask you for. > > It looks OK to me although I don't grok why the order here in 8u > > 302 if (isXCompositeDisplay(awt_display, adata->awt_visInfo.screen) && > 303 hasXCompositeOverlayExtension(awt_display)) > > is reversed from what you had in 9 : > 309 if (hasXCompositeOverlayExtension(awt_display) && > 310 isXCompositeDisplay(awt_display, > adata->awt_visInfo.screen)) > Eh.. This is because the current patch is based on what I had on the RPM, which is an older version of the patch I pushed for 9, before the additional gtk code, for some reason the line was inverted initially, I changed this in the 9 patch as it is indeed more logical. Thanks for spotting this as I completely missed it (good that we have reviews for backports too!). It's fixed in this new webrev: http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.01/jdk.patch Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From philip.race at oracle.com Thu Jul 19 20:43:44 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 19 Jul 2018 13:43:44 -0700 Subject: [OpenJDK 2D-Dev] Request for re-reviewl: Backport of JDK-8150954: Taking screenshots on x11 composite desktop produce wrong result In-Reply-To: References: <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com> Message-ID: <94afc6e3-5b46-552e-c53a-da86a6dd6a95@oracle.com> +1 -phil. On 07/19/2018 05:33 AM, Mario Torre wrote: > On Wed, Jul 18, 2018 at 11:28 PM, Phil Race wrote: >> The review for the original fix was actually on awt-dev which probably was >> correct >> and so this should be there too. > Hi Phil, > > Thanks for the review, and I apologise for posting it to 2d-dev, that > was out of habit :) > >> I hadn't seen the thread so had to go read it .. but it was so long ago I'd >> probably have had to re-read it anyway. But it was not so easy to find >> since it did not have the bug ID in the subject ! >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010742.html >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010996.html >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011370.html > Right, thanks again for linking the relevant thread information, I > didn't post it as it was in the bug description, but indeed is a nice > courtesy for the reviewer, I'll make sure to have it linked next time > in the email request too. > >> Since it is changed, yes, being able to point to this review thread is >> likely >> something the 8u-dev maintainers would ask you for. >> >> It looks OK to me although I don't grok why the order here in 8u >> >> 302 if (isXCompositeDisplay(awt_display, adata->awt_visInfo.screen) && >> 303 hasXCompositeOverlayExtension(awt_display)) >> >> is reversed from what you had in 9 : >> 309 if (hasXCompositeOverlayExtension(awt_display) && >> 310 isXCompositeDisplay(awt_display, >> adata->awt_visInfo.screen)) >> > Eh.. This is because the current patch is based on what I had on the > RPM, which is an older version of the patch I pushed for 9, before the > additional gtk code, for some reason the line was inverted initially, > I changed this in the 9 patch as it is indeed more logical. Thanks for > spotting this as I completely missed it (good that we have reviews for > backports too!). > > It's fixed in this new webrev: > > http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.01/jdk.patch > > Cheers, > Mario > From shashidhara.veerabhadraiah at oracle.com Fri Jul 20 06:32:58 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 19 Jul 2018 23:32:58 -0700 (PDT) Subject: [12] JDK-8182043: Access to Windows Large Icons Message-ID: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default> Hi All, Please review a fix for the below bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8182043 Webrev: http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.00/ History: This fix is derived from an earlier fix proposed under this mail thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013016.html. Thanks to Semyon for that trial and part of this solution is continued from where it was left off. Solution details: Large system icons were not able to be extracted because of sun package internal classes are not exposed anymore. This change adds a new api to get access to those icons. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Jul 20 07:51:18 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 20 Jul 2018 07:51:18 +0000 Subject: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] Message-ID: <25b47b2aa9ea45a791f2d5702ffd59e9@sap.com> Hello, the test javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java does not work on some of our Linux and AIX machines . Reason is that the test in case of absence of font "Arial" on the system , chooses just the first font from the AvailableFontFamilyNames . 280 private static Font getFont() { 281 GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); 282 String[] fontNames = ge.getAvailableFontFamilyNames(); 283 String fontName = fontNames[0]; 284 for (String name : fontNames) { 285 if ("Arial".equals(name)) { 286 fontName = name; 287 break; 288 } 289 } 290 return new Font(fontName, Font.PLAIN, 30); 291 } 292 However this first font might not be a good choice that works with the tests in bug8132119.java . So we better provide some reasonable fallbacks that were available and working on our test systems . Please review this adjustment : http://cr.openjdk.java.net/~mbaesken/webrevs/8207941.0/ https://bugs.openjdk.java.net/browse/JDK-8207941 Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 20 08:56:58 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Jul 2018 14:26:58 +0530 Subject: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] In-Reply-To: <25b47b2aa9ea45a791f2d5702ffd59e9@sap.com> References: <25b47b2aa9ea45a791f2d5702ffd59e9@sap.com> Message-ID: <25860b12-f0f2-40bb-1630-6d4b3e6c7778@oracle.com> Looks good to me. BTW, did you test on latest ubuntu and solaris? Please add the bugid to the test. Regards Prasanta On 7/20/2018 1:21 PM, Baesken, Matthias wrote: > > Hello,? the test > javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java > > does not work on some of our? Linux and AIX machines . > > Reason is that the test in case of absence of font ?Arial?? on the > system , ?chooses ?just the first font? from ?the > ?AvailableFontFamilyNames? . > > 280???? private static Font getFont() { > > 281 ????GraphicsEnvironment ge = > GraphicsEnvironment.getLocalGraphicsEnvironment(); > > 282???????? String[] fontNames = ge.getAvailableFontFamilyNames(); > > 283???????? String fontName = fontNames[0]; > > 284???????? for (String name : fontNames) { > 285???????????? if ("Arial".equals(name)) { > 286???????????????? fontName = name; > 287???????????????? break; > 288???????????? } > 289???????? } > 290???????? return new Font(fontName, Font.PLAIN, 30); > 291???? } > 292 > > However? this first font might not be a good choice? that works? with > the tests? in?? bug8132119.java? . > > So? we better? provide some ?reasonable ?fallbacks ?that? were? > available and ?working on?? our? test systems . > > Please review this adjustment : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8207941.0/ > > > https://bugs.openjdk.java.net/browse/JDK-8207941 > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Jul 20 09:10:48 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 20 Jul 2018 09:10:48 +0000 Subject: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] In-Reply-To: <25860b12-f0f2-40bb-1630-6d4b3e6c7778@oracle.com> References: <25b47b2aa9ea45a791f2d5702ffd59e9@sap.com> <25860b12-f0f2-40bb-1630-6d4b3e6c7778@oracle.com> Message-ID: Thanks for looking into it . * BTW, did you test on latest ubuntu and solaris? I tested on Ubuntu 16 / Linux ppc64le (test chooses Bitstream Charter) and on Solaris 11 (tests chooses Arial) . The test was fine on both test machines . Best regards, Matthias From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com] Sent: Freitag, 20. Juli 2018 10:57 To: Baesken, Matthias ; awt-dev at openjdk.java.net Subject: Re: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] Looks good to me. BTW, did you test on latest ubuntu and solaris? Please add the bugid to the test. Regards Prasanta On 7/20/2018 1:21 PM, Baesken, Matthias wrote: Hello, the test javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java does not work on some of our Linux and AIX machines . Reason is that the test in case of absence of font "Arial" on the system , chooses just the first font from the AvailableFontFamilyNames . 280 private static Font getFont() { 281 GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); 282 String[] fontNames = ge.getAvailableFontFamilyNames(); 283 String fontName = fontNames[0]; 284 for (String name : fontNames) { 285 if ("Arial".equals(name)) { 286 fontName = name; 287 break; 288 } 289 } 290 return new Font(fontName, Font.PLAIN, 30); 291 } 292 However this first font might not be a good choice that works with the tests in bug8132119.java . So we better provide some reasonable fallbacks that were available and working on our test systems . Please review this adjustment : http://cr.openjdk.java.net/~mbaesken/webrevs/8207941.0/ https://bugs.openjdk.java.net/browse/JDK-8207941 Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 20 10:11:57 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Jul 2018 15:41:57 +0530 Subject: [12] JDK-8182043: Access to Windows Large Icons In-Reply-To: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default> References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default> Message-ID: <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com> Hi Shashi, The previous review thread is too long so probably need the original reviewer to take a look. But here are my 2 cents * Can you please explain how the new API is supposed to be used? It says "Scaled icon for a file, directory, or folder as it would be displayed ina system file browser" ??? ??? ??? ??? getSystemIcon(File f, int width, int height) ??? ??? ??? If the specified width, height is not available, then it will be scaled to available icon size, is it? I do not think the javadoc captures the essence of the api thoroughly. ??? ??? ??? For example, if width/height asked for is 100 and we have icon of 96/96 and 128/128, then what it will return, the closest size 96/96 or the next positive one 128/128. * As per fix of /JDK-8151385 /, /MAX_ICON_SIZE=128 /was added so even if you accept width/height as 256 (by your check it will still restrict icon size to 128)... 287 if((width > 256 || width < 1) || (height > 256 || height < 1)) { 288 System.err.println("Warning: Icon scaling may be distorted"); 289 throw new IllegalArgumentException("unexpected icon scaling size"); 290 } ??? ??? ??? so maybe either increase MAX_ICON_SIZE or adjust your check accordingly. * We normally do not throw unchecked exception (RuntimeException) from public API, so you should consider throwing checked exception instead. * Also, you need to change javadoc to have @throws instead of @exception * Also, it was asked, IIUC that the public API used MutliResolutionImage and uses |getResolutionVariants () to select appropriate icon image or let user select it (for case mentioned above, if we are not sure ourselves)| * scaleIconImage, scaleIcon uses lot of common code so we can have a common method * makeIcon(long hIcon, int bsize).. I guess parameter name bsize does not convey meaning, is it "bestsize"? * int size = getLargeIcon ? 32 : 16; and also in Win32ShellFolderManager2. java probably you can have constants for these 2 number * Win32ShellFolderManager2 1118 return getShell32Icon(4, size); 1119 } else { 1120 return getShell32Icon(1, size); You should use constant to be more readable FILE_ICON_ID = 1;FOLDER_ICON_ID = 4; Regards Prasanta || On 7/20/2018 12:02 PM, Shashidhara Veerabhadraiah wrote: > > Hi All, Please review a fix for the below bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8182043 > > Webrev: http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.00/ > > > History: This fix is derived from an earlier fix proposed under this > mail thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013016.html. > Thanks to Semyon for that trial and part of this solution is continued > from where it was left off. > > Solution details: Large system icons were not able to be extracted > because of sun package internal classes are not exposed anymore. This > change adds a new api to get access to those icons. > > Thanks and regards, > > Shashi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Mon Jul 23 12:24:53 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 23 Jul 2018 21:24:53 +0900 Subject: [12] Proposal: Memory leak issue on awt_InputMethod.c In-Reply-To: References: Message-ID: <5d0494712cee97fcf0e310d0ec330b46@linux.vnet.ibm.com> Hello. I'd like to change target to "JDK12". I'd like to obtain a sponsor for this patch. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-06-28 22:13, Ichiroh Takiguchi wrote: > Hello. > In my investigation, this issue only happens on 64 bit build only... > > On 2018-06-28 06:06, Phil Race wrote: >> On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote: >>> Hello, >>> >>> I should post this mail before starting JDK11 RDP1. >> >> Already too too late for that, but although this looks like a bug - >> and the correct fix - >> the bug has been there forever .. since JDK 1.2 in 1998 ! >> That makes it a 20 year old bug, so I don't think we need to treat it >> as urgent >> for JDK 11. >> >> -phil. >> >>> >>> I found memory leak issue on awt_InputMethod.c. >>> >>> See src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c. >>> On line 1117, memory area was allocated by malloc(), but free() is >>> missing >>> =========================================== >>> 1099 if (text->feedback != NULL) { >>> 1100 int cnt; >>> 1101 jint *tmpstyle; >>> 1102 >>> 1103 style = (*env)->NewIntArray(env, text->length); >>> 1104 if (JNU_IsNull(env, style)) { >>> 1105 (*env)->ExceptionClear(env); >>> 1106 THROW_OUT_OF_MEMORY_ERROR(); >>> 1107 goto finally; >>> 1108 } >>> 1109 >>> 1110 if (sizeof(XIMFeedback) == sizeof(jint)) { >>> 1111 /* >>> 1112 * Optimization to avoid copying the array >>> 1113 */ >>> 1114 (*env)->SetIntArrayRegion(env, style, 0, >>> 1115 text->length, (jint >>> *)text->feedback); >>> 1116 } else { >>> 1117 tmpstyle = (jint >>> *)malloc(sizeof(jint)*(text->length)); >>> 1118 if (tmpstyle == (jint *) NULL) { >>> 1119 THROW_OUT_OF_MEMORY_ERROR(); >>> 1120 goto finally; >>> 1121 } >>> 1122 for (cnt = 0; cnt < (int)text->length; cnt++) >>> 1123 tmpstyle[cnt] = text->feedback[cnt]; >>> 1124 (*env)->SetIntArrayRegion(env, style, 0, >>> 1125 text->length, (jint >>> *)tmpstyle); >>> 1126 } >>> 1127 } >>> =========================================== >>> In my investigation, malloc() was called on RHEL7 x86_64 with >>> Japanese Input Method. >>> >>> I'd like to obtain a sponsor for this patch. >>> -------- >>> --- old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >>> 2018-06-27 02:03:48.134991703 +0900 >>> +++ new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >>> 2018-06-27 02:03:47.493005265 +0900 >>> @@ -1148,6 +1148,7 @@ >>> tmpstyle[cnt] = text->feedback[cnt]; >>> (*env)->SetIntArrayRegion(env, style, 0, >>> text->length, (jint >>> *)tmpstyle); >>> + free(tmpstyle); >>> } >>> } >>> } >>> --- >>> old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> 2018-06-27 02:03:49.040972563 +0900 >>> +++ >>> new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> 2018-06-27 02:03:48.391986274 +0900 >>> @@ -1123,6 +1123,7 @@ >>> tmpstyle[cnt] = text->feedback[cnt]; >>> (*env)->SetIntArrayRegion(env, style, 0, >>> text->length, (jint >>> *)tmpstyle); >>> + free(tmpstyle); >>> } >>> } >>> } >>> -------- >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> From matthias.baesken at sap.com Tue Jul 24 07:11:20 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 24 Jul 2018 07:11:20 +0000 Subject: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] In-Reply-To: References: <25b47b2aa9ea45a791f2d5702ffd59e9@sap.com> <25860b12-f0f2-40bb-1630-6d4b3e6c7778@oracle.com> Message-ID: <22473ae0bed544619bae613c82d1e73b@sap.com> Hi, could I have a second review please so that I can push it ? Thanks, Matthias From: Baesken, Matthias Sent: Freitag, 20. Juli 2018 11:11 To: 'Prasanta Sadhukhan' ; awt-dev at openjdk.java.net Subject: RE: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] Thanks for looking into it . * BTW, did you test on latest ubuntu and solaris? I tested on Ubuntu 16 / Linux ppc64le (test chooses Bitstream Charter) and on Solaris 11 (tests chooses Arial) . The test was fine on both test machines . Best regards, Matthias From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com] Sent: Freitag, 20. Juli 2018 10:57 To: Baesken, Matthias >; awt-dev at openjdk.java.net Subject: Re: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] Looks good to me. BTW, did you test on latest ubuntu and solaris? Please add the bugid to the test. Regards Prasanta On 7/20/2018 1:21 PM, Baesken, Matthias wrote: Hello, the test javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java does not work on some of our Linux and AIX machines . Reason is that the test in case of absence of font "Arial" on the system , chooses just the first font from the AvailableFontFamilyNames . 280 private static Font getFont() { 281 GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); 282 String[] fontNames = ge.getAvailableFontFamilyNames(); 283 String fontName = fontNames[0]; 284 for (String name : fontNames) { 285 if ("Arial".equals(name)) { 286 fontName = name; 287 break; 288 } 289 } 290 return new Font(fontName, Font.PLAIN, 30); 291 } 292 However this first font might not be a good choice that works with the tests in bug8132119.java . So we better provide some reasonable fallbacks that were available and working on our test systems . Please review this adjustment : http://cr.openjdk.java.net/~mbaesken/webrevs/8207941.0/ https://bugs.openjdk.java.net/browse/JDK-8207941 Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Jul 24 07:18:37 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Jul 2018 07:18:37 +0000 Subject: RFR [XS] : 8207941 : javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on machines without Arial font [testbug] In-Reply-To: <22473ae0bed544619bae613c82d1e73b@sap.com> References: <25b47b2aa9ea45a791f2d5702ffd59e9@sap.com> <25860b12-f0f2-40bb-1630-6d4b3e6c7778@oracle.com> <22473ae0bed544619bae613c82d1e73b@sap.com> Message-ID: <9309ebb3599e45a2ae7f21276e568bf6@sap.com> Hi Matthias, The fix looks good. Thanks for addressing this. Could you please capitalize the sentences in the comment? Don't need a webrev for this. Best regards, Goetz. > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 24. Juli 2018 09:11 > To: Prasanta Sadhukhan ; awt- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: RFR [XS] : 8207941 : > javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on > machines without Arial font [testbug] > > Hi, could I have a second review please so that I can push it ? > > > > Thanks, Matthias > > > > > > From: Baesken, Matthias > Sent: Freitag, 20. Juli 2018 11:11 > To: 'Prasanta Sadhukhan' ; awt- > dev at openjdk.java.net > Subject: RE: RFR [XS] : 8207941 : > javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on > machines without Arial font [testbug] > > > > Thanks for looking into it . > > > > * BTW, did you test on latest ubuntu and solaris? > > > > I tested on Ubuntu 16 / Linux ppc64le (test chooses Bitstream Charter) and > on Solaris 11 (tests chooses Arial) . > > The test was fine on both test machines . > > > > Best regards, Matthias > > > > > > From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com] > Sent: Freitag, 20. Juli 2018 10:57 > To: Baesken, Matthias >; awt-dev at openjdk.java.net > > Subject: Re: RFR [XS] : 8207941 : > javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails on > machines without Arial font [testbug] > > > > Looks good to me. BTW, did you test on latest ubuntu and solaris? > > Please add the bugid to the test. > > Regards > Prasanta > > On 7/20/2018 1:21 PM, Baesken, Matthias wrote: > > Hello, the test > javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java > > does not work on some of our Linux and AIX machines . > > > > Reason is that the test in case of absence of font "Arial" on the > system , chooses just the first font from the AvailableFontFamilyNames . > > 280 private static Font getFont() { > > 281 GraphicsEnvironment ge = > GraphicsEnvironment.getLocalGraphicsEnvironment(); > > 282 String[] fontNames = ge.getAvailableFontFamilyNames(); > > 283 String fontName = fontNames[0]; > > 284 for (String name : fontNames) { > 285 if ("Arial".equals(name)) { > 286 fontName = name; > 287 break; > 288 } > 289 } > 290 return new Font(fontName, Font.PLAIN, 30); > 291 } > 292 > > > > > > However this first font might not be a good choice that works with > the tests in bug8132119.java . > > So we better provide some reasonable fallbacks that were > available and working on our test systems . > > > > > > Please review this adjustment : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8207941.0/ > > > > > https://bugs.openjdk.java.net/browse/JDK-8207941 > > > > > > Thanks, Matthias > > > > > > > > From philip.race at oracle.com Fri Jul 27 03:43:42 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 26 Jul 2018 20:43:42 -0700 Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 Message-ID: <5B5A94EE.6080002@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8208353 Webrev : http://cr.openjdk.java.net/~prr/8208353/ We need to update libpng, used only by splashscreen, and only for reading to the new release from 10 days ago Built on all platforms. Splashscreen tests still pass. -phil. From manajit.halder at oracle.com Fri Jul 27 12:06:29 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 27 Jul 2018 17:36:29 +0530 Subject: [11] Review request for JDK-8208394: [macosx] test java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java compilation fail Message-ID: <00EFB39D-5713-410E-96B7-D4EABD4562C7@oracle.com> Hi All, Kindly review the fix for JDK11. Bug: https://bugs.openjdk.java.net/browse/JDK-8208394 Webrev: http://cr.openjdk.java.net/~mhalder/8208394/webrev.00/ Regards, Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jul 27 12:11:36 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 27 Jul 2018 17:41:36 +0530 Subject: [11] Review request for JDK-8208394: [macosx] test java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java compilation fail In-Reply-To: <00EFB39D-5713-410E-96B7-D4EABD4562C7@oracle.com> References: <00EFB39D-5713-410E-96B7-D4EABD4562C7@oracle.com> Message-ID: <81e7a84e-7615-af61-aa48-e72be241660e@oracle.com> +1 On 7/27/2018 5:36 PM, Manajit Halder wrote: > Hi All, > > Kindly review the fix for JDK11. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8208394 > > Webrev: > http://cr.openjdk.java.net/~mhalder/8208394/webrev.00/ > > > Regards, > Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Fri Jul 27 12:16:21 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 27 Jul 2018 05:16:21 -0700 (PDT) Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 In-Reply-To: <5B5A94EE.6080002@oracle.com> References: <5B5A94EE.6080002@oracle.com> Message-ID: <6c5710b8-8795-4d16-81dc-87dbf7204487@default> Hi Phil, The changes look fine to me. Great to see the steps that need to be followed for updating png library into UPDATING.txt. I see a small typo on line 19: "handiling". Don?t need a new webrev for this. Thanks, Krishna -----Original Message----- From: Philip Race Sent: Friday, July 27, 2018 9:14 AM To: awt-dev at openjdk.java.net Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 Bug: https://bugs.openjdk.java.net/browse/JDK-8208353 Webrev : http://cr.openjdk.java.net/~prr/8208353/ We need to update libpng, used only by splashscreen, and only for reading to the new release from 10 days ago Built on all platforms. Splashscreen tests still pass. -phil. From krishna.addepalli at oracle.com Fri Jul 27 12:19:28 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 27 Jul 2018 05:19:28 -0700 (PDT) Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 In-Reply-To: <6c5710b8-8795-4d16-81dc-87dbf7204487@default> References: <5B5A94EE.6080002@oracle.com> <6c5710b8-8795-4d16-81dc-87dbf7204487@default> Message-ID: One more thing, in the UPDATING.txt: In the first line: "TING libpng in OpenJDK". I guess it should have been "UPDATING" ... -----Original Message----- From: Krishna Addepalli Sent: Friday, July 27, 2018 5:46 PM To: Philip Race ; awt-dev at openjdk.java.net Subject: Re: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 Hi Phil, The changes look fine to me. Great to see the steps that need to be followed for updating png library into UPDATING.txt. I see a small typo on line 19: "handiling". Don?t need a new webrev for this. Thanks, Krishna -----Original Message----- From: Philip Race Sent: Friday, July 27, 2018 9:14 AM To: awt-dev at openjdk.java.net Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 Bug: https://bugs.openjdk.java.net/browse/JDK-8208353 Webrev : http://cr.openjdk.java.net/~prr/8208353/ We need to update libpng, used only by splashscreen, and only for reading to the new release from 10 days ago Built on all platforms. Splashscreen tests still pass. -phil. From shashidhara.veerabhadraiah at oracle.com Fri Jul 27 14:49:58 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Fri, 27 Jul 2018 07:49:58 -0700 (PDT) Subject: [11] Review request for JDK-8208394: [macosx] test java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java compilation fail In-Reply-To: <81e7a84e-7615-af61-aa48-e72be241660e@oracle.com> References: <00EFB39D-5713-410E-96B7-D4EABD4562C7@oracle.com> <81e7a84e-7615-af61-aa48-e72be241660e@oracle.com> Message-ID: <1ddf0ae6-fbf3-4ff7-8db3-a362b9d9626c@default> +1 From: Prasanta Sadhukhan Sent: Friday, July 27, 2018 5:42 PM To: Manajit Halder ; awt-dev at openjdk.java.net Subject: Re: [11] Review request for JDK-8208394: [macosx] test java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java compilation fail +1 On 7/27/2018 5:36 PM, Manajit Halder wrote: Hi All, Kindly review the fix for JDK11. Bug: https://bugs.openjdk.java.net/browse/JDK-8208394 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emhalder/8208394/webrev.00/"http://cr.openjdk.java.net/~mhalder/8208394/webrev.00/ Regards, Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 27 15:10:56 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 27 Jul 2018 08:10:56 -0700 Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 In-Reply-To: References: <5B5A94EE.6080002@oracle.com> <6c5710b8-8795-4d16-81dc-87dbf7204487@default> Message-ID: <5B5B3600.4010301@oracle.com> I'll fix such typos before I push. The updating file is not critical but something I started with freetype and would like to add for each of the 3rd party libs. -phil. On 7/27/18, 5:19 AM, Krishna Addepalli wrote: > One more thing, in the UPDATING.txt: > In the first line: "TING libpng in OpenJDK". I guess it should have been "UPDATING" ... > > -----Original Message----- > From: Krishna Addepalli > Sent: Friday, July 27, 2018 5:46 PM > To: Philip Race; awt-dev at openjdk.java.net > Subject: Re: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 > > Hi Phil, > > The changes look fine to me. > Great to see the steps that need to be followed for updating png library into UPDATING.txt. I see a small typo on line 19: "handiling". > Don?t need a new webrev for this. > > Thanks, > Krishna > > -----Original Message----- > From: Philip Race > Sent: Friday, July 27, 2018 9:14 AM > To: awt-dev at openjdk.java.net > Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208353 > Webrev : http://cr.openjdk.java.net/~prr/8208353/ > > We need to update libpng, used only by splashscreen, and only for reading to the new release from 10 days ago > > Built on all platforms. Splashscreen tests still pass. > > -phil. From philip.race at oracle.com Fri Jul 27 16:35:01 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 27 Jul 2018 09:35:01 -0700 Subject: [11] Review request for JDK-8208394: [macosx] test java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java compilation fail In-Reply-To: <00EFB39D-5713-410E-96B7-D4EABD4562C7@oracle.com> References: <00EFB39D-5713-410E-96B7-D4EABD4562C7@oracle.com> Message-ID: <5B5B49B5.9060805@oracle.com> If it wasn't for being related to the TCK failures, I'd say to push this to 12 instead. But it probably would have been better to focus on the TCK bugs first, and you may even need to update the test anyway. And whilst this is OK to fix per the RDP 2 rules remember to add appropriate labels else it will cause consternation .. Test and documentation bugs Bugs of any priority whose fixes only affect tests, or test-problem lists, or documentation may be fixed in RDP 1 and RDP 2. If you have a fix for such a bug then you don't need to request approval in order to integrate it, but please do make sure that the issue has a |noreg-self| or |noreg-doc| label , as appropriate. .. I added them for you .. -phil. On 7/27/18, 5:06 AM, Manajit Halder wrote: > Hi All, > > Kindly review the fix for JDK11. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8208394 > > Webrev: > http://cr.openjdk.java.net/~mhalder/8208394/webrev.00/ > > > Regards, > Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Sun Jul 29 04:55:55 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sat, 28 Jul 2018 21:55:55 -0700 (PDT) Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 In-Reply-To: <5B5A94EE.6080002@oracle.com> References: <5B5A94EE.6080002@oracle.com> Message-ID: Hi Phil, Change looks good to me. Thanks, Jay -----Original Message----- From: Philip Race Sent: Friday, July 27, 2018 9:14 AM To: awt-dev at openjdk.java.net Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 Bug: https://bugs.openjdk.java.net/browse/JDK-8208353 Webrev : http://cr.openjdk.java.net/~prr/8208353/ We need to update libpng, used only by splashscreen, and only for reading to the new release from 10 days ago Built on all platforms. Splashscreen tests still pass. -phil. From shashidhara.veerabhadraiah at oracle.com Mon Jul 30 08:01:32 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 30 Jul 2018 01:01:32 -0700 (PDT) Subject: [12] JDK-8182043: Access to Windows Large Icons In-Reply-To: <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com> References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default> <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com> Message-ID: <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default> Hi Prashanta, Thanks for your review. Below are my replies: http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.01/ Thanks and regards, Shashi From: Prasanta Sadhukhan Sent: Friday, July 20, 2018 3:42 PM To: Shashidhara Veerabhadraiah ; swing-dev at openjdk.java.net; awt-dev at openjdk.java.net Subject: Re: [12] JDK-8182043: Access to Windows Large Icons Hi Shashi, The previous review thread is too long so probably need the original reviewer to take a look. But here are my 2 cents Can you please explain how the new API is supposed to be used? It says "Scaled icon for a file, directory, or folder as it would be displayed in a system file browser" getSystemIcon(File f, int width, int height) If the specified width, height is not available, then it will be scaled to available icon size, is it? I do not think the javadoc captures the essence of the api thoroughly. For example, if width/height asked for is 100 and we have icon of 96/96 and 128/128, then what it will return, the closest size 96/96 or the next positive one 128/128. [Shashi] Yes. It will be scaled to the requested size. For the example that you mentioned, it is OS dependent. Typically it will pick up the higher resolution if available and scales it down to the requested level. If the higher resolution icon is not available then it will pick the lower one and scales it up. Hence I just happened to mention it as 'scaled icon' in the explanation. As per fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8151385"JDK-8151385, MAX_ICON_SIZE=128 was added so even if you accept width/height as 256 (by your check it will still restrict icon size to 128)... 287 if((width > 256 || width < 1) || (height > 256 || height < 1)) { 288 System.err.println("Warning: Icon scaling may be distorted"); 289 throw new IllegalArgumentException("unexpected icon scaling size"); 290 } so maybe either increase MAX_ICON_SIZE or adjust your check accordingly. [Shashi] The size I have kept is in a similar scale that is available with the OS. Though there is an internal limit of 128, code is present to scale it to 256 if the user wants in such a way. We normally do not throw unchecked exception (RuntimeException) from public API, so you should consider throwing checked exception instead. [Shashi] Fixed this. Also, you need to change javadoc to have @throws instead of @exception [Shashi] Fixed this. Also, it was asked, IIUC that the public API used MutliResolutionImage and uses HYPERLINK "https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html#getResolutionVariants%28%29"getResolutionVariants() to select appropriate icon image or let user select it (for case mentioned above, if we are not sure ourselves) [Shashi] Since the icon is scaled to the levels that was requested and limits are mentioned as part of Javadoc comments. Fixed in the updated Webrev. . scaleIconImage, scaleIcon uses lot of common code so we can have a common method [Shashi] Fixed this. makeIcon(long hIcon, int bsize).. I guess parameter name bsize does not convey meaning, is it "bestsize"? [Shashi] Just an alternative and no meaning for that. . int size = getLargeIcon ? 32 : 16; and also in Win32ShellFolderManager2. java probably you can have constants for these 2 number . Win32ShellFolderManager2 . 1118 return getShell32Icon(4, size); . 1119 } else { . 1120 return getShell32Icon(1, size); You should use constant to be more readable FILE_ICON_ID = 1; FOLDER_ICON_ID = 4; [Shashi] For the constants, I have newly added some comments explaining that magic number. Adding a new constant is not worth as it is used only once!! Regards Prasanta On 7/20/2018 12:02 PM, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for the below bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8182043 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.00/ History: This fix is derived from an earlier fix proposed under this mail thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013016.html. Thanks to Semyon for that trial and part of this solution is continued from where it was left off. Solution details: Large system icons were not able to be extracted because of sun package internal classes are not exposed anymore. This change adds a new api to get access to those icons. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jul 30 22:12:07 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 30 Jul 2018 15:12:07 -0700 Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 In-Reply-To: References: <5B5A94EE.6080002@oracle.com> Message-ID: <628788ed-197a-195d-ddf1-8633e79012f7@oracle.com> http://cr.openjdk.java.net/~prr/8208353.1 I've made a minor tweak to restore the ifdef at line 287 of pngpriv.h which hopefully will avoid regressing the PPC fix discussed here http://mail.openjdk.java.net/pipermail/2d-dev/2018-January/008834.html But it was almost entirely luck I just remembered about this ... and I have no way to verify it on PPC. -phil. On 07/28/2018 09:55 PM, Jayathirth D V wrote: > Hi Phil, > > Change looks good to me. > > Thanks, > Jay > > -----Original Message----- > From: Philip Race > Sent: Friday, July 27, 2018 9:14 AM > To: awt-dev at openjdk.java.net > Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208353 > Webrev : http://cr.openjdk.java.net/~prr/8208353/ > > We need to update libpng, used only by splashscreen, and only for reading to the new release from 10 days ago > > Built on all platforms. Splashscreen tests still pass. > > -phil. From matthias.baesken at sap.com Tue Jul 31 07:53:30 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 31 Jul 2018 07:53:30 +0000 Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 In-Reply-To: <628788ed-197a-195d-ddf1-8633e79012f7@oracle.com> References: <5B5A94EE.6080002@oracle.com> <628788ed-197a-195d-ddf1-8633e79012f7@oracle.com> Message-ID: <856dfdb5d6584e5a8fec72f8024e2979@sap.com> Hi Phil, thanks for handling PPC64 as well ! Best regards, Matthias > -----Original Message----- > From: Phil Race > Sent: Dienstag, 31. Juli 2018 00:12 > To: Jayathirth D V ; awt-dev at openjdk.java.net; > Baesken, Matthias ; Lindenmaier, Goetz > ; Volker Simonis > Subject: Re: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 > > http://cr.openjdk.java.net/~prr/8208353.1 > > I've made a minor tweak to restore the ifdef at line 287 of pngpriv.h > which hopefully will avoid regressing the PPC fix discussed here > > http://mail.openjdk.java.net/pipermail/2d-dev/2018-January/008834.html > > But it was almost entirely luck I just remembered about this ... and I > have no way to verify it on PPC. > > -phil. > > On 07/28/2018 09:55 PM, Jayathirth D V wrote: > > Hi Phil, > > > > Change looks good to me. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Philip Race > > Sent: Friday, July 27, 2018 9:14 AM > > To: awt-dev at openjdk.java.net > > Subject: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35 > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208353 > > Webrev : http://cr.openjdk.java.net/~prr/8208353/ > > > > We need to update libpng, used only by splashscreen, and only for reading > to the new release from 10 days ago > > > > Built on all platforms. Splashscreen tests still pass. > > > > -phil. From Sergey.Bylokhov at oracle.com Tue Jul 31 23:39:59 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 31 Jul 2018 16:39:59 -0700 Subject: [12] Review Request: 8205537 Drop of sun.applet package Message-ID: Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some code related to implementation of applets and appletviewer. Some of its classes were dropped already: JDK-8204454, JDK-8203308. Now there are only 3 classes, all related to the applet security and we can drop them as well. In the fix this package was removed, and the tests were updated to not use it. I am not sure how "ClassnameCharTest.java" is useful after applets removal, but since this test used subclass of the AppletClassLoader, I have copied some code from the removed class to the test. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 31 23:55:31 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 31 Jul 2018 16:55:31 -0700 Subject: [12] Review Request: 8205537 Drop of sun.applet package In-Reply-To: References: Message-ID: <862c094a-1d53-fca6-9a7b-123dbd45af0e@oracle.com> On 31/07/2018 16:39, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. typo, I meant jdk12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 > Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ > > sun.applet is an internal package contained some code related to > implementation of applets and appletviewer. Some of its classes were > dropped already: JDK-8204454, JDK-8203308. Now there are only 3 classes, > all related to the applet security and we can drop them as well. > > In the fix this package was removed, and the tests were updated to not > use it. I am not sure how "ClassnameCharTest.java" is useful after > applets removal, but since this test used subclass of the > AppletClassLoader, I have copied some code from the removed class to the > test. > -- Best regards, Sergey.