From prasanta.sadhukhan at oracle.com Mon Mar 2 11:47:52 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 2 Mar 2020 17:17:52 +0530 Subject: [15] RFR JDK-8231042: [macos] JFileChooser creates new folder on ESC In-Reply-To: <1ab83dd5-4f7b-4356-aa45-501ab270497f@default> References: <644bb91d-5b4b-4cb5-b0d0-08ecae8a12f6@default> <7fa3c030-9bd6-50e7-9610-923b40ce17f2@oracle.com> <1ab83dd5-4f7b-4356-aa45-501ab270497f@default> Message-ID: +1 Regards Prasanta On 27-Feb-20 5:52 PM, Pankaj Bansal wrote: > Hi Sergey, > > Thanks for the review. > > << It would be good to filter out the test on non-mac systems by the "@requires" tag. > I added the filter in main method, so if someone is running this as standalone test, even then the test is filtered out. But yes, adding the tag is useful when using jtreg to stop the test from running altogether. I have added the tag "@requires". Please have a look. > webrev: http://cr.openjdk.java.net/~pbansal/8231042/webrev01/ > > Regards, > Pankaj > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, February 27, 2020 4:32 PM > To: Pankaj Bansal ; swing-dev at openjdk.java.net > Subject: Re: [15] RFR JDK-8231042: [macos] JFileChooser creates new folder on ESC > > Hi, Pankaj. > > It would be good to filter out the test on non-mac systems by the "@requires" tag. > > On 2/25/20 8:43 am, Pankaj Bansal wrote: >> Hi All, >> >> Please review the following fix for jdk15. >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8231042 >> >> webrev: >> >> http://cr.openjdk.java.net/~pbansal/8231042/webrev00/ >> >> Issue: >> >> In case of AquaLookAndFeel, if a JFileChooser is created and if we try to abort the "New Folder" create action by pressing "ESC" key, there is a new folder created named "uninitializedValue". If the new folder creation is aborted, it should not create any folder as pressing "ESC" key is equivalent to cancelling the folder creation. >> >> Cause: >> >> In JFileChooser, the check if the JOptionPane is cancelled is missing. This issue is specific to AquaLookAndFeel. >> >> Fix: >> >> The fix is to add the required check in JFileChoose create NewFolder Action for a Cancelled JOptionPane. I this case, no folder should be created. >> >> >> Regards, >> Pankaj Bansal >> > From bhawesh.choudhary at oracle.com Wed Mar 4 10:43:21 2020 From: bhawesh.choudhary at oracle.com (Bhawesh Choudhary) Date: Wed, 4 Mar 2020 16:13:21 +0530 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF Message-ID: Hi, Please review this fix, JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ Issue: In Windows LookAndFeel, When navigating Combobox's list of JFileChooser via keys, the contents of JFileChooser changes. Fix: Set flag "JComboBox.isTableCellEditor" to True which prohibits JCombobox from sending selection change event when JCombobox's list selection change happens via keys. Verification: Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as well as BasicLookAndFeel with keys navigation. also added a test case to verify the same. Did not find any misbehavior with the fix. Regards Bhawesh From Sergey.Bylokhov at oracle.com Thu Mar 5 00:51:12 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 4 Mar 2020 16:51:12 -0800 Subject: RFR: 8219578 No associated icon for the leaf node of Jtree Message-ID: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8219578 CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00 The fix clarifies the status of the links to external resources in the documentation -- Best regards, Sergey. From philip.race at oracle.com Thu Mar 5 01:07:22 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 04 Mar 2020 17:07:22 -0800 Subject: RFR: 8219578 No associated icon for the leaf node of Jtree In-Reply-To: References: Message-ID: <5E6050CA.2050904@oracle.com> I suggest changing + * The documentation in this module includes links to overviews, tutorials, + * examples, guides, and other documentation. This is done for convenience. + * Information at these external resources is not part of JavaSE API + * Specification. to + * The documentation in this module includes links to external overviews, tutorials, + * examples, guides, media format specifications, and other similar documentation. + * These links are meant to be informative to the reader and nothing more. + * Information at these external resources, no matter the hosting or the author, + * is not part of Java Platform API specification unless explicitly stated to be so. I wouldn't be surprised if the CSR process generates some more tweaks. -phil. On 3/4/20, 4:51 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk/client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219578 > CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 > Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00 > > The fix clarifies the status of the links to external > resources in the documentation > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Mar 5 01:37:09 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 4 Mar 2020 17:37:09 -0800 Subject: RFR: 8219578 No associated icon for the leaf node of Jtree In-Reply-To: <5E6050CA.2050904@oracle.com> References: <5E6050CA.2050904@oracle.com> Message-ID: <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com> webrev and CSR are updated: Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01 CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 On 3/4/20 5:07 pm, Philip Race wrote: > I suggest changing + * The documentation in this module includes links to overviews, tutorials, > + * examples, guides, and other documentation. This is done for convenience. > + * Information at these external resources is not part of JavaSE API > + * Specification. > > to > > + * The documentation in this module includes links to external overviews, tutorials, > + * examples, guides, media format specifications, and other similar documentation. > + * These links are meant to be informative to the reader and nothing more. > + * Information at these external resources, no matter the hosting or the author, + * is not part of Java Platform APIspecification unless explicitly stated to be so. I wouldn't be surprised if the CSR process generates some more tweaks. > > -phil. > > On 3/4/20, 4:51 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk/client. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219578 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 >> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00 >> >> The fix clarifies the status of the links to external >> resources in the documentation >> -- Best regards, Sergey. From philip.race at oracle.com Thu Mar 5 01:55:50 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 04 Mar 2020 17:55:50 -0800 Subject: RFR: 8219578 No associated icon for the leaf node of Jtree In-Reply-To: <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com> References: <5E6050CA.2050904@oracle.com> <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com> Message-ID: <5E605C26.3060104@oracle.com> OK. CSR is reviewed. -phil. On 3/4/20, 5:37 PM, Sergey Bylokhov wrote: > webrev and CSR are updated: > > Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01 > CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 > > On 3/4/20 5:07 pm, Philip Race wrote: >> I suggest changing + * The documentation in this module includes >> links to overviews, tutorials, >> + * examples, guides, and other documentation. This is done for >> convenience. >> + * Information at these external resources is not part of JavaSE API >> + * Specification. >> >> to >> >> + * The documentation in this module includes links to external >> overviews, tutorials, >> + * examples, guides, media format specifications, and other similar >> documentation. >> + * These links are meant to be informative to the reader and nothing >> more. >> + * Information at these external resources, no matter the hosting or >> the author, + * is not part of Java Platform APIspecification unless >> explicitly stated to be so. I wouldn't be surprised if the CSR >> process generates some more tweaks. >> >> -phil. >> >> On 3/4/20, 4:51 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk/client. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219578 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 >>> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00 >>> >>> The fix clarifies the status of the links to external >>> resources in the documentation >>> > > From jayathirth.d.v at oracle.com Thu Mar 5 09:17:58 2020 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 5 Mar 2020 01:17:58 -0800 (PST) Subject: RFR: 8219578 No associated icon for the leaf node of Jtree In-Reply-To: <5E605C26.3060104@oracle.com> References: <5E6050CA.2050904@oracle.com> <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com> <5E605C26.3060104@oracle.com> Message-ID: <446d6a93-b6d9-42b4-8790-9bc613bda3f6@default> Change looks good to me. Thanks, Jay -----Original Message----- From: Philip Race Sent: Thursday, March 5, 2020 7:26 AM To: Sergey Bylokhov Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; swing-dev at openjdk.java.net Subject: Re: RFR: 8219578 No associated icon for the leaf node of Jtree OK. CSR is reviewed. -phil. On 3/4/20, 5:37 PM, Sergey Bylokhov wrote: > webrev and CSR are updated: > > Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01 > CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 > > On 3/4/20 5:07 pm, Philip Race wrote: >> I suggest changing + * The documentation in this module includes >> links to overviews, tutorials, >> + * examples, guides, and other documentation. This is done for >> convenience. >> + * Information at these external resources is not part of JavaSE API >> + * Specification. >> >> to >> >> + * The documentation in this module includes links to external >> overviews, tutorials, >> + * examples, guides, media format specifications, and other similar >> documentation. >> + * These links are meant to be informative to the reader and nothing >> more. >> + * Information at these external resources, no matter the hosting or >> the author, + * is not part of Java Platform APIspecification unless >> explicitly stated to be so. I wouldn't be surprised if the CSR >> process generates some more tweaks. >> >> -phil. >> >> On 3/4/20, 4:51 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk/client. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219578 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 >>> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00 >>> >>> The fix clarifies the status of the links to external resources in >>> the documentation >>> > > From tejpal.rebari at oracle.com Thu Mar 5 10:56:08 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Thu, 5 Mar 2020 16:26:08 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() Message-ID: Hi All, Please review the following fix for jdk15. Bug : https://bugs.openjdk.java.net/browse/JDK-8146330 Webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev0/ Issue : The two Methods UIDefaults.keys() and UIDefault.keySet() returns different size. Keys() returns Enumeration of keys in the Hashtable and keySet() returns set view of keys. For AquaLookAndFeel UIDefaults.keys() returns 719 keys while UIDefault.keySet() returns 0 keys. For other LookAndFeel UIDefaults.keys() returns different values but the UIDefault.keySet() returns 0. Fix : There is a keys() method in MultiUIDefaults class which returns the enumeration of the keys but there is no such method for keySet(). Fix is to add the keySet() method in MultiUIDefaults which will return the keySet of uiDefaults. Test : Tested on Mac,Windows and Linux. Added a test to test on all installed look and feels Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at whitemail.net Thu Mar 5 11:08:23 2020 From: alan at whitemail.net (Alan White) Date: Thu, 5 Mar 2020 11:08:23 +0000 Subject: MultiResolutionImage unusable with Buttons Message-ID: Hi Folks I'd like to help move https://bugs.openjdk.java.net/browse/JDK-8212226 this along, or ask if anyone has a workaround to the issue. To recap MultiResolutionImages work perfectly with JButton, until you disable it, then you get the exception as per the bug above. There is no way (unless you know better) to set a disabled icon on a JButton via an Action, and in a large Swing app using actions, architecturally finding a way to have to set images in both the Action and the Button becomes challenging, as well as error prone. Any other workarounds plse? I'd like to investigate and maybe contribute to fixing 8212226 , I've not contributed before, so any rules of the road docs you can point me at, anybody I can work with on this, not really sure how this whole process works so any pointers gladly appreciated! Thanks Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Mar 5 16:10:38 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Mar 2020 16:10:38 +0000 Subject: Remove System.out.println from ImageIcon.loadImage In-Reply-To: References: <2310F0FD-DAA6-4E24-85AD-776D6F979CC0@sap.com> <549622d0-fe72-f267-c105-53b1399471dc@oracle.com>, , , <6CA1C9A2-3FE1-445D-93B7-57DC8818F0FB@sap.com>, , , , , , , Message-ID: Hi Vlad, I just had a look at your change. The effective change to ImageIcon.java looks correct at a glance. But it would be good if some Reviewer from the swing area, e.g. Sergey, can have a look. Then, I think, the import reordering is not quite correct. Packages in the java namespace should be first, then javax.*, then sun.*, all ordered alphabetically. I suggest this (e.g. spell out all imports): import java.awt.Component; import java.awt.Graphics; import java.awt.IllegalComponentStateException; import java.awt.Image; import java.awt.MediaTracker; import java.awt.Toolkit; import java.awt.image.ColorModel; import java.awt.image.ImageObserver; import java.awt.image.MemoryImageSource; import java.awt.image.PixelGrabber; import java.beans.BeanProperty; import java.beans.ConstructorProperties; import java.beans.Transient; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; import java.net.URL; import java.security.AccessControlContext; import java.security.AccessController; import java.security.PrivilegedAction; import java.security.ProtectionDomain; import java.util.Locale; import javax.accessibility.Accessible; import javax.accessibility.AccessibleContext; import javax.accessibility.AccessibleIcon; import javax.accessibility.AccessibleRole; import javax.accessibility.AccessibleState; import javax.accessibility.AccessibleStateSet; import sun.awt.AWTAccessor; import sun.awt.AppContext; But feel free to keep the wildcards, like java.awt.*. You'll also have to update the copyright year. As for the test, I'm wondering if there's an explicit reason to use main/othervm? Best regards Christoph -----Original Message----- From: swing-dev On Behalf Of Jason Mehrens Sent: Freitag, 28. Februar 2020 02:47 To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage Looks good to me. ________________________________________ From: Volodin, Vladislav Sent: Saturday, February 22, 2020 4:38 AM To: Jason Mehrens Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage Hello Jason and everyone else, here is my webrev that my colleague published http://cr.openjdk.java.net/~clanger/webrevs/6421373.0/ Can you please review it and let me know if I should change anything? Currently I am OOO, but I will do the changes in March. Kind regards, Vlad Get Outlook for iOS ________________________________ From: Jason Mehrens Sent: Tuesday, February 11, 2020 9:13:41 PM To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage Vlad, Yea that looks good. Jason ________________________________________ From: Volodin, Vladislav Sent: Wednesday, February 5, 2020 9:59 AM To: Jason Mehrens Cc: swing-dev at openjdk.java.net Subject: RE: Remove System.out.println from ImageIcon.loadImage Hi Jason, thank you for your advice. I have changed my code, now it simulates the behavior of the interrupted thread. Can you please check my patch? I don't have the "bug" ticket, so in my test case "@bug JDK-123456" should be adjusted. I will appreciate if you and somebody else can review my patch and submit it to JDK. Thanks, Vlad -----Original Message----- From: Jason Mehrens Sent: Mittwoch, 29. Januar 2020 17:55 To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage 1. Agreed. 2. I was just pulling from the jdk8 source (because I'm lazy) to express the idea. Feel free to adjust. 3. Reasserting in the finally ensure we are not forcefully setting the interrupted status on the current thread and calling 'statusID' and 'removeImage'. It also ensures that the interrupt is set even if an unexpected exception is thrown. Reasserting at the end of 'e1' and never in 'e2' should work too. The main issue that I'm trying to convey to you is that your test is incomplete in that it does check that the interrupt was swallowed. Swallowing interrupts is bad practice. Reasserting in e2 only means that we swallow interrupts from e1. Change your test to this and retest: === public static void main(String[] args) throws Exception { Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); Thread.currentThread().interrupt(); ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { throw new RuntimeException("Couldn't load GIF from bytes after interruption"); } if (!Thread.currentThread().isInterrupted()) { throw new RuntimeException("Interrupt was swallowed"); } } } === ________________________________________ From: Volodin, Vladislav Sent: Wednesday, January 29, 2020 9:52 AM To: Jason Mehrens Cc: swing-dev at openjdk.java.net Subject: RE: Remove System.out.println from ImageIcon.loadImage Hi Jason, I have few questions: 1. The second assignment is probably redundant: } catch (InterruptedException e1) { wasInterrupted = true; // line #2, see comment below try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; wasInterrupted = true; // <-- this is redundant, because of the line #2 } } finally { 2. I think the first call of "addImage" is not necessary: boolean wasInterrupted = false; mTracker.addImage(image, id); // maybe I should remove this, because of another comment down below. try { loadStatus = 0; mTracker.addImage(image, id); // because of that May I also ask you a question? What is the purpose of interrupting the current thread in the finally block, instead of doing it in the second catch block (where e2 is created)? I assume that since we were able to handle the exception properly, and plus the entire block is in the synchronization area, in theory we have only one importer at the time. Kind regards, Vlad -----Original Message----- From: Jason Mehrens Sent: Mittwoch, 29. Januar 2020 16:35 To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage Bug in that last version: Thread.currentThread().isInterrupted(); -> Thread.currentThread().interrupt(); === protected void loadImage(Image image) { MediaTracker mTracker = getTracker(); synchronized (mTracker) { int id = getNextID(); boolean wasInterrupted = false; mTracker.addImage(image, id); try { loadStatus = 0; mTracker.addImage(image, id); mTracker.waitForID(id, 0); } catch (InterruptedException e1) { wasInterrupted = true; try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; wasInterrupted = true; } } finally { if (loadStatus == 0) { loadStatus = mTracker.statusID(id, false); } mTracker.removeImage(image, id); if (wasInterrupted) { Thread.currentThread().interrupt(); } } } } === ________________________________________ From: swing-dev on behalf of Jason Mehrens Sent: Wednesday, January 29, 2020 9:33 AM To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage A shorter version is just to reassert at the end of catch e1. It is safer to just reassert as the last statement in the finally. === protected void loadImage(Image image) { MediaTracker mTracker = getTracker(); synchronized (mTracker) { int id = getNextID(); boolean wasInterrupted = false; mTracker.addImage(image, id); try { loadStatus = 0; mTracker.addImage(image, id); mTracker.waitForID(id, 0); } catch (InterruptedException e1) { wasInterrupted = true; try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; } } finally { if (loadStatus == 0) { loadStatus = mTracker.statusID(id, false); } mTracker.removeImage(image, id); if (wasInterrupted) { Thread.currentThread().isInterrupted(); } } } } === Jason ________________________________________ From: Volodin, Vladislav Sent: Tuesday, January 28, 2020 4:02 PM To: Jason Mehrens Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage This is a valid point, because I wasn?t sure that when the thread is interrupted, I handled the first exception, and my thought was that all other ?wait? calls (maybe in other threads) should get the same exception as well. And since I handled this exceptional case, I am restoring the interrupted status in case if I don?t know how to handle this exception the second time. } catch (InterruptedException e1) { try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; Thread.currentThread().interrupt(); } If I restore the interrupted status BEFORE waitForID call, then this thread will immoderately fail. Should I restore it AFTER, e.g. } catch (InterruptedException e1) { try { mTracker.waitForID(id, 0); Thread.currentThread().interrupt(); // On 28. Jan 2020, at 22:27, Jason Mehrens wrote: > > ?I see. Well I would have to do some more digging and testing to make myself more knowledgeable on MediaTracker. > > Then the only bug in your current code is that you are not reasserting interrupted status of the current thread in the case e1 is raised and e2 is not. It is usually best to reassert the interrupted state at the end of the method. > > Jason > > ________________________________________ > From: Volodin, Vladislav > Sent: Tuesday, January 28, 2020 2:54 PM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > Hi Jason, > > I am not sure about the loop, because I don?t know if we can trust results from mTracker.statusID at the moment when an exceptional case occurs. For example, I was experimenting with the code and found out that the MediaTracker can spawn a thread to load the image, or might use the current thread, and the ABORTED state is never returned (I don?t even know how to raise this state). That is why I don?t even know if your loop will ever stop. > > In my solution, I give the second chance only, and in case if the execution was interrupted the second time, I explicitly assign the ABORTED state to loadStatus. If the user wants to load this image once again, he can create ImageIcon again (or even do this in a loop), or reinitialize it with a single method (I don?t remember its name). > > What do you think? > > Kind regards, > Vlad > > Sent from myPad > >> On 28. Jan 2020, at 21:34, Jason Mehrens wrote: >> >> ?Vlad, >> >> I assume you would want to wait in a loop and reassert the interrupt at the end. >> >> === >> protected void loadImage(Image image) { >> MediaTracker mTracker = getTracker(); >> synchronized(mTracker) { >> int id = getNextID(); >> >> mTracker.addImage(image, id); >> boolean wasInterrupted = false; >> try { >> do { >> try { >> mTracker.waitForID(id, 0); >> } catch (InterruptedException e) { >> wasInterrupted = true; >> } >> loadStatus = mTracker.statusID(id, false); >> } while (loadStatus == MediaTracker.LOADING); >> mTracker.removeImage(image, id); >> >> width = image.getWidth(imageObserver); >> height = image.getHeight(imageObserver); >> } finally { >> if (wasInterrupted) { >> Thread.currentThread().interrupt(); >> } >> } >> } >> } >> === >> >> Jason >> ________________________________________ >> From: swing-dev on behalf of Volodin, Vladislav >> Sent: Monday, January 27, 2020 11:11 AM >> To: Sergey Bylokhov >> Cc: swing-dev at openjdk.java.net >> Subject: Re: Remove System.out.println from ImageIcon.loadImage >> >> Hello Sergey, and others, >> >> here is the patch (made with "git diff") in the attachment. I have read that sometimes the attachments are lost. So here is my version with few comments regarding my code. I decided to use your approach with a small improvement. There is an excerpt of my patch. >> >> The idea is pretty simple: >> 1. I create an empty gif 1x1; >> 2. Initialize DefaultToolkit (I plan to interrupt the main thread, and if I do not initialize the toolkit in advance, my test will fail at the beginning >> 3. Interrupt the main thread >> 4. Try to load the icon: >> >> import javax.swing.*; >> import java.awt.*; >> >> public class imageIconInterrupted { >> static byte[] EMPTY_GIF = new byte[]{ >> (byte) 0x47, (byte) 0x49, (byte) 0x46, (byte) 0x38, (byte) 0x39, (byte) 0x61, (byte) 0x01, (byte) 0x00, >> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x21, (byte) 0xF9, (byte) 0x04, >> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x2C, (byte) 0x00, (byte) 0x00, >> (byte) 0x00, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x02 >> }; >> >> public static void main(String[] args) throws Exception { >> Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); >> >> Thread.currentThread().interrupt(); >> ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); >> if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { >> throw new RuntimeException("Couldn't load GIF from bytes after interruption"); >> } >> } >> } >> >> The code of loadImage I have changed as follows: >> 1. I clear loadStatus for "finally" part; >> 2. Check the interruption according to your comments; >> 3. Change the status to ABORTED, if the interruption happened again (this part I cannot test, because I cannot properly interrupt the thread whenever I want. Multithreading is quite fragile there :( ) >> 4. update the status "interrupted" again; >> 5. and then - finally block. >> >> protected void loadImage(Image image) { >> ... >> try { >> loadStatus = 0; >> mTracker.addImage(image, id); >> mTracker.waitForID(id, 0); >> } catch (InterruptedException e1) { >> try { >> mTracker.waitForID(id, 0); >> } catch (InterruptedException e2) { >> loadStatus = MediaTracker.ABORTED; >> Thread.currentThread().interrupt(); >> } >> } finally { >> if (loadStatus == 0) { >> loadStatus = mTracker.statusID(id, false); >> } >> mTracker.removeImage(image, id); >> } >> >> P.S. if you think that my patch sounds fine, I will find a sponsor for the bug report and the patch preparation, so you can review it later. >> After the second attempt, my EMPTY_GIF was loaded successfully. The ABORTED part it seems that I don't know if it has ever worked. My patch (in the attachment) checks also the state ERROR for the URL that doesn't exist. Something like: >> >> ImageIcon iconNotExist = new ImageIcon(new URL("http://doesnt.exist.anywhere/1.gif")); // I am not sure if I spelled this URL grammatically correct >> if (iconNotExist.getImageLoadStatus() != MediaTracker.ERRORED) { >> throw new RuntimeException("Got unexpected status from non-existing GIF"); >> } >> >> Thanks to everyone. >> >> Kind regards, >> Vlad >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Dienstag, 21. Januar 2020 22:26 >> To: Volodin, Vladislav >> Cc: Jason Mehrens ; swing-dev at openjdk.java.net >> Subject: Re: Remove System.out.println from ImageIcon.loadImage >> >>>> On 1/21/20 1:14 pm, Volodin, Vladislav wrote: >>> Hi all, >>> >>> If I am not mistaken, this method is called from the constructor and other methods. How long should we try loading the icon using the unmanaged (by any thread pool, but I am not sure about this statement) thread? >>> >>> We don?t even have the flag ?interrupted?. So technically this icon has to be loaded. >> >> I think it is necessary to save the "interrupted" state in the catch >> block and try to call waitForID() again. It will be necessary to set >> "interrupted" flag for the Thread after that(when the waitForID will >> return without exception). >> >> >>> Sent from myFone >>> >>>>> On 21. Jan 2020, at 21:55, Sergey Bylokhov wrote: >>>> >>>> ?On 1/21/20 12:26 pm, Jason Mehrens wrote: >>>>> +1 for Sergey suggestion. >>>> >>>> Or probably we need to try to load the image again because of the spec of the method state this: >>>> "Loads the image, returning only when the image is loaded." >>>> >>>>> ________________________________________ >>>>> From: Sergey Bylokhov >>>>> Sent: Sunday, January 19, 2020 9:31 PM >>>>> To: Volodin, Vladislav; Jason Mehrens >>>>> Cc: swing-dev at openjdk.java.net >>>>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>>>> I guess there are no objections, probably the best way to fix >>>>> it is to drop the System.out.println and set interrupted flag. >>>>> On 1/16/20 7:05 am, Volodin, Vladislav wrote: >>>>>> If people in this distribution list agree, I can start working on a simple fix and either remove the logging (System.out.println), or replace it with PlatformLogger. I guess the second solution sounds better, but I don't know what is the better way to write a test-case for it. >>>>> -- >>>>> Best regards, Sergey. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. From pankaj.b.bansal at oracle.com Fri Mar 6 07:40:45 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 6 Mar 2020 13:10:45 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: References: Message-ID: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> Hello Tejpal, I think you need to iterate over the full "tables" array instead of just using the tables[0] as is being done in entrySet function in same class. Also, you need to create a copy of the key set like entrySet function instead of returning the original handle. Also, please follow the 80 chars max per line convention in testcase added. Regards, Pankaj On 05/03/20 4:26 PM, Tejpal Rebari wrote: > Hi All, > Please review the following fix for jdk15. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146330 > Webrev :http://cr.openjdk.java.net/~trebari/swing/8146330/webrev0/ > > > Issue :?The?two Methods UIDefaults.keys() and > UIDefault.keySet()?returns different size. > Keys() returns Enumeration of keys in the Hashtable and > keySet() returns set view of keys. > > For AquaLookAndFeel UIDefaults.keys()?returns 719 keys while > UIDefault.keySet()?returns 0 keys. > For other LookAndFeel UIDefaults.keys()?returns different values but > the UIDefault.keySet() returns 0. > > Fix : There is a keys() method in MultiUIDefaults class?which returns > the?enumeration of the keys but there is no?such method for keySet(). > Fix is to add the keySet() method in?MultiUIDefaults?which will return > the keySet of uiDefaults. > > Test : Tested on?Mac,Windows and Linux. > Added a test to test on all installed look and feels > > Regards > Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Mar 6 23:48:49 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Mar 2020 15:48:49 -0800 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> Message-ID: <655aac62-7338-812e-8ddd-1418b7187bda@oracle.com> On 3/5/20 11:40 pm, Pankaj Bansal wrote: > Hello Tejpal, > > I think you need to iterate over the full "tables" array instead of just using the tables[0] as is being done in entrySet function in same class. Also, you need to create a copy of the key set like entrySet function instead of returning the original handle. I suggest to update the test, so it will handle the comments above. > > Also, please follow the 80 chars max per line convention in testcase added. > > > Regards, > > Pankaj > > > On 05/03/20 4:26 PM, Tejpal Rebari wrote: >> Hi All, >> Please review the following fix for jdk15. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146330 >> Webrev :http://cr.openjdk.java.net/~trebari/swing/8146330/webrev0/ >> >> Issue :?The?two Methods UIDefaults.keys() and UIDefault.keySet()?returns different size. >> Keys() returns Enumeration of keys in the Hashtable and >> keySet() returns set view of keys. >> >> For AquaLookAndFeel UIDefaults.keys()?returns 719 keys while UIDefault.keySet()?returns 0 keys. >> For other LookAndFeel UIDefaults.keys()?returns different values but the UIDefault.keySet() returns 0. >> >> Fix : There is a keys() method in MultiUIDefaults class?which returns the?enumeration of the keys but there is no?such method for keySet(). >> Fix is to add the keySet() method in?MultiUIDefaults?which will return the keySet of uiDefaults. >> >> Test : Tested on?Mac,Windows and Linux. >> Added a test to test on all installed look and feels >> >> Regards >> Tejpal > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Mar 7 22:20:38 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 7 Mar 2020 14:20:38 -0800 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI Message-ID: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8240633 Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00 Our tests in mach5 for JFileChooser sometime fails with different suspicious exceptions. The root cause is that the Aqua UI delegates add various listeners to the JFileChooser, and never delete them. So these Aqua related listeners may fail if current L&F was changed. In the fix we will "uninstall" all child components for the AquaFileChooserUI. Also in the AquaFileChooserUI we had added model as a PropertyChangeListener twice, and never removed the filterComboBoxModel. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sun Mar 8 10:07:59 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 8 Mar 2020 03:07:59 -0700 Subject: MultiResolutionImage unusable with Buttons In-Reply-To: References: Message-ID: Hi, Alan. You are welcome! Please see http://openjdk.java.net/contribute on how to get started. Here is some information on how to build OpenJDK: https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html And run the tests: https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/testing.html On 3/5/20 3:08 am, Alan White wrote: > Hi Folks > > I'd like to help move https://bugs.openjdk.java.net/browse/JDK-8212226 this along, or ask if anyone has a workaround to the issue. > > To recap MultiResolutionImages work perfectly with JButton, until you disable it, then you get the exception as per the bug above. > > There is no way (unless you know better) to set a disabled icon on a JButton via an Action, and in a large Swing app using actions, architecturally finding a way to have to set images in both the Action and the Button becomes challenging, as well as error prone. Any other workarounds plse? > > I'd like to investigate and maybe contribute to fixing 8212226 , I've not contributed before, so any rules of the road docs you can point me at, anybody I can work with on this, not really sure how this whole process works so any pointers gladly appreciated! > > Thanks > Alan -- Best regards, Sergey. From philip.race at oracle.com Sun Mar 8 22:56:20 2020 From: philip.race at oracle.com (Philip Race) Date: Sun, 08 Mar 2020 15:56:20 -0700 Subject: Remove System.out.println from ImageIcon.loadImage In-Reply-To: References: , <6CA1C9A2-3FE1-445D-93B7-57DC8818F0FB@sap.com>, , , , , , Message-ID: <5E657814.6020806@oracle.com> 1) That bug is still closed. Did you want it re-opened ? I've just done so. BTW I don't know why, but it was closed less than 3 months ago by an engineer from the hotspot team (!?) I have NO idea why since there is no comment. 2) If you are starting a review thread for a bug, the email subject line should have the bug id and its synopsis thus : RFR: 6421373: ImageIcon does not reassert interrupt status. Although depending on what we end up doing the synopsis may need to change (see 6 + 7 below). 3) The test has very long lines. Please curtail them to 80 chars. 4) What Christoph said. 5) I know where it was coming from, but I wish the docs said "Returns when the image is loaded, or loading has failed. Call getImageLoadStatus()" to check this." Also a whole bunch of other questions arise like what should happen if you call setImage() twice for different images. If the first image succeeded, but the second failed, then what ? 6) I am not completely sold on reasserting the interrupted status since it is a change of behaviour and you will need an approved CSR to push this. Not sure if you need to update the javadoc as well ... 7) Now .. if all you really wanted was to get rid of the print statement this is a lot of effort with some compatibility impact. -phil. On 2/22/20, 2:38 AM, Volodin, Vladislav wrote: > Hello Jason and everyone else, > > here is my webrev that my colleague published > http://cr.openjdk.java.net/~clanger/webrevs/6421373.0/ > > Can you please review it and let me know if I should change anything? > Currently I am OOO, but I will do the changes in March. > > Kind regards, > Vlad > > Get Outlook for iOS > ------------------------------------------------------------------------ > *From:* Jason Mehrens > *Sent:* Tuesday, February 11, 2020 9:13:41 PM > *To:* Volodin, Vladislav > *Cc:* swing-dev at openjdk.java.net > *Subject:* Re: Remove System.out.println from > ImageIcon.loadImage > Vlad, > > Yea that looks good. > > Jason > > ________________________________________ > From: Volodin, Vladislav > Sent: Wednesday, February 5, 2020 9:59 AM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: RE: Remove System.out.println from > ImageIcon.loadImage > > Hi Jason, > > thank you for your advice. I have changed my code, now it simulates > the behavior of the interrupted thread. Can you please check my patch? > I don't have the "bug" ticket, so in my test case "@bug JDK-123456" > should be adjusted. > > I will appreciate if you and somebody else can review my patch and > submit it to JDK. > > Thanks, > Vlad > > -----Original Message----- > From: Jason Mehrens > Sent: Mittwoch, 29. Januar 2020 17:55 > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from > ImageIcon.loadImage > > 1. Agreed. > 2. I was just pulling from the jdk8 source (because I'm lazy) to > express the idea. Feel free to adjust. > 3. Reasserting in the finally ensure we are not forcefully setting the > interrupted status on the current thread and calling 'statusID' and > 'removeImage'. It also ensures that the interrupt is set even if an > unexpected exception is thrown. Reasserting at the end of 'e1' and > never in 'e2' should work too. > > The main issue that I'm trying to convey to you is that your test is > incomplete in that it does check that the interrupt was swallowed. > Swallowing interrupts is bad practice. Reasserting in e2 only means > that we swallow interrupts from e1. > > Change your test to this and retest: > === > public static void main(String[] args) throws Exception { > Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); > > Thread.currentThread().interrupt(); > ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); > if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { > throw new RuntimeException("Couldn't load GIF from bytes > after interruption"); > } > > if (!Thread.currentThread().isInterrupted()) { > throw new RuntimeException("Interrupt was swallowed"); > } > } > } > === > ________________________________________ > From: Volodin, Vladislav > Sent: Wednesday, January 29, 2020 9:52 AM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: RE: Remove System.out.println from > ImageIcon.loadImage > > Hi Jason, > > I have few questions: > > 1. The second assignment is probably redundant: > > } catch (InterruptedException e1) { > wasInterrupted = true; // line #2, see comment below > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > wasInterrupted = true; // <-- this is redundant, > because of the line #2 > } > } finally { > > 2. I think the first call of "addImage" is not necessary: > > boolean wasInterrupted = false; > mTracker.addImage(image, id); // maybe I should remove this, because > of another comment down below. > try { > loadStatus = 0; > mTracker.addImage(image, id); // because of that > > May I also ask you a question? > What is the purpose of interrupting the current thread in the finally > block, instead of doing it in the second catch block (where e2 is > created)? I assume that since we were able to handle the exception > properly, and plus the entire block is in the synchronization area, in > theory we have only one importer at the time. > > Kind regards, > Vlad > > -----Original Message----- > From: Jason Mehrens > Sent: Mittwoch, 29. Januar 2020 16:35 > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from > ImageIcon.loadImage > > Bug in that last version: > Thread.currentThread().isInterrupted(); -> > Thread.currentThread().interrupt(); > === > protected void loadImage(Image image) { > MediaTracker mTracker = getTracker(); > synchronized (mTracker) { > int id = getNextID(); > > boolean wasInterrupted = false; > mTracker.addImage(image, id); > try { > loadStatus = 0; > mTracker.addImage(image, id); > mTracker.waitForID(id, 0); > } catch (InterruptedException e1) { > wasInterrupted = true; > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > wasInterrupted = true; > } > } finally { > if (loadStatus == 0) { > loadStatus = > mTracker.statusID(id, false); > } > mTracker.removeImage(image, id); > if (wasInterrupted) { > > Thread.currentThread().interrupt(); > } > } > } > } > === > > ________________________________________ > From: swing-dev on behalf of > Jason Mehrens > Sent: Wednesday, January 29, 2020 9:33 AM > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from > ImageIcon.loadImage > > A shorter version is just to reassert at the end of catch e1. It is > safer to just reassert as the last statement in the finally. > > === > protected void loadImage(Image image) { > MediaTracker mTracker = getTracker(); > synchronized (mTracker) { > int id = getNextID(); > > boolean wasInterrupted = false; > mTracker.addImage(image, id); > try { > loadStatus = 0; > mTracker.addImage(image, id); > mTracker.waitForID(id, 0); > } catch (InterruptedException e1) { > wasInterrupted = true; > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > } > } finally { > if (loadStatus == 0) { > loadStatus = > mTracker.statusID(id, false); > } > mTracker.removeImage(image, id); > if (wasInterrupted) { > > Thread.currentThread().isInterrupted(); > } > } > } > } > === > > Jason > ________________________________________ > From: Volodin, Vladislav > Sent: Tuesday, January 28, 2020 4:02 PM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from > ImageIcon.loadImage > > This is a valid point, because I wasn?t sure that when the thread is > interrupted, I handled the first exception, and my thought was that > all other ?wait? calls (maybe in other threads) should get the same > exception as well. > > And since I handled this exceptional case, I am restoring the > interrupted status in case if I don?t know how to handle this > exception the second time. > > } catch (InterruptedException e1) { > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > Thread.currentThread().interrupt(); > } > > If I restore the interrupted status BEFORE waitForID call, then this > thread will immoderately fail. Should I restore it AFTER, e.g. > > } catch (InterruptedException e1) { > try { > mTracker.waitForID(id, 0); > Thread.currentThread().interrupt(); // } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > Thread.currentThread().interrupt(); > } > > Thanks, > Vlad > > Sent from myPad > > > On 28. Jan 2020, at 22:27, Jason Mehrens > wrote: > > > > ?I see. Well I would have to do some more digging and testing to > make myself more knowledgeable on MediaTracker. > > > > Then the only bug in your current code is that you are not > reasserting interrupted status of the current thread in the case e1 is > raised and e2 is not. It is usually best to reassert the interrupted > state at the end of the method. > > > > Jason > > > > ________________________________________ > > From: Volodin, Vladislav > > Sent: Tuesday, January 28, 2020 2:54 PM > > To: Jason Mehrens > > Cc: swing-dev at openjdk.java.net > > Subject: Re: Remove System.out.println from > ImageIcon.loadImage > > > > Hi Jason, > > > > I am not sure about the loop, because I don?t know if we can trust > results from mTracker.statusID at the moment when an exceptional case > occurs. For example, I was experimenting with the code and found out > that the MediaTracker can spawn a thread to load the image, or might > use the current thread, and the ABORTED state is never returned (I > don?t even know how to raise this state). That is why I don?t even > know if your loop will ever stop. > > > > In my solution, I give the second chance only, and in case if the > execution was interrupted the second time, I explicitly assign the > ABORTED state to loadStatus. If the user wants to load this image once > again, he can create ImageIcon again (or even do this in a loop), or > reinitialize it with a single method (I don?t remember its name). > > > > What do you think? > > > > Kind regards, > > Vlad > > > > Sent from myPad > > > >> On 28. Jan 2020, at 21:34, Jason Mehrens > wrote: > >> > >> ?Vlad, > >> > >> I assume you would want to wait in a loop and reassert the interrupt > at the end. > >> > >> === > >> protected void loadImage(Image image) { > >> MediaTracker mTracker = getTracker(); > >> synchronized(mTracker) { > >> int id = getNextID(); > >> > >> mTracker.addImage(image, id); > >> boolean wasInterrupted = false; > >> try { > >> do { > >> try { > >> mTracker.waitForID(id, 0); > >> } catch (InterruptedException e) { > >> wasInterrupted = true; > >> } > >> loadStatus = mTracker.statusID(id, false); > >> } while (loadStatus == MediaTracker.LOADING); > >> mTracker.removeImage(image, id); > >> > >> width = image.getWidth(imageObserver); > >> height = image.getHeight(imageObserver); > >> } finally { > >> if (wasInterrupted) { > >> Thread.currentThread().interrupt(); > >> } > >> } > >> } > >> } > >> === > >> > >> Jason > >> ________________________________________ > >> From: swing-dev on behalf of > Volodin, Vladislav > >> Sent: Monday, January 27, 2020 11:11 AM > >> To: Sergey Bylokhov > >> Cc: swing-dev at openjdk.java.net > >> Subject: Re: Remove System.out.println from > ImageIcon.loadImage > >> > >> Hello Sergey, and others, > >> > >> here is the patch (made with "git diff") in the attachment. I have > read that sometimes the attachments are lost. So here is my version > with few comments regarding my code. I decided to use your approach > with a small improvement. There is an excerpt of my patch. > >> > >> The idea is pretty simple: > >> 1. I create an empty gif 1x1; > >> 2. Initialize DefaultToolkit (I plan to interrupt the main thread, > and if I do not initialize the toolkit in advance, my test will fail > at the beginning > >> 3. Interrupt the main thread > >> 4. Try to load the icon: > >> > >> import javax.swing.*; > >> import java.awt.*; > >> > >> public class imageIconInterrupted { > >> static byte[] EMPTY_GIF = new byte[]{ > >> (byte) 0x47, (byte) 0x49, (byte) 0x46, (byte) 0x38, (byte) > 0x39, (byte) 0x61, (byte) 0x01, (byte) 0x00, > >> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) > 0x00, (byte) 0x21, (byte) 0xF9, (byte) 0x04, > >> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) > 0x00, (byte) 0x2C, (byte) 0x00, (byte) 0x00, > >> (byte) 0x00, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) > 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x02 > >> }; > >> > >> public static void main(String[] args) throws Exception { > >> Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); > >> > >> Thread.currentThread().interrupt(); > >> ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); > >> if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { > >> throw new RuntimeException("Couldn't load GIF from bytes > after interruption"); > >> } > >> } > >> } > >> > >> The code of loadImage I have changed as follows: > >> 1. I clear loadStatus for "finally" part; > >> 2. Check the interruption according to your comments; > >> 3. Change the status to ABORTED, if the interruption happened again > (this part I cannot test, because I cannot properly interrupt the > thread whenever I want. Multithreading is quite fragile there :( ) > >> 4. update the status "interrupted" again; > >> 5. and then - finally block. > >> > >> protected void loadImage(Image image) { > >> ... > >> try { > >> loadStatus = 0; > >> mTracker.addImage(image, id); > >> mTracker.waitForID(id, 0); > >> } catch (InterruptedException e1) { > >> try { > >> mTracker.waitForID(id, 0); > >> } catch (InterruptedException e2) { > >> loadStatus = MediaTracker.ABORTED; > >> Thread.currentThread().interrupt(); > >> } > >> } finally { > >> if (loadStatus == 0) { > >> loadStatus = mTracker.statusID(id, false); > >> } > >> mTracker.removeImage(image, id); > >> } > >> > >> P.S. if you think that my patch sounds fine, I will find a sponsor > for the bug report and the patch preparation, so you can review it later. > >> After the second attempt, my EMPTY_GIF was loaded successfully. The > ABORTED part it seems that I don't know if it has ever worked. My > patch (in the attachment) checks also the state ERROR for the URL that > doesn't exist. Something like: > >> > >> ImageIcon iconNotExist = new ImageIcon(new > URL("http://doesnt.exist.anywhere/1.gif")); // I am not sure if I > spelled this URL grammatically correct > >> if (iconNotExist.getImageLoadStatus() != MediaTracker.ERRORED) { > >> throw new RuntimeException("Got unexpected status from > non-existing GIF"); > >> } > >> > >> Thanks to everyone. > >> > >> Kind regards, > >> Vlad > >> > >> -----Original Message----- > >> From: Sergey Bylokhov > >> Sent: Dienstag, 21. Januar 2020 22:26 > >> To: Volodin, Vladislav > >> Cc: Jason Mehrens ; > swing-dev at openjdk.java.net > >> Subject: Re: Remove System.out.println from > ImageIcon.loadImage > >> > >>>> On 1/21/20 1:14 pm, Volodin, Vladislav wrote: > >>> Hi all, > >>> > >>> If I am not mistaken, this method is called from the constructor > and other methods. How long should we try loading the icon using the > unmanaged (by any thread pool, but I am not sure about this statement) > thread? > >>> > >>> We don?t even have the flag ?interrupted?. So technically this icon > has to be loaded. > >> > >> I think it is necessary to save the "interrupted" state in the catch > >> block and try to call waitForID() again. It will be necessary to set > >> "interrupted" flag for the Thread after that(when the waitForID will > >> return without exception). > >> > >> > >>> Sent from myFone > >>> > >>>>> On 21. Jan 2020, at 21:55, Sergey Bylokhov > wrote: > >>>> > >>>> ?On 1/21/20 12:26 pm, Jason Mehrens wrote: > >>>>> +1 for Sergey suggestion. > >>>> > >>>> Or probably we need to try to load the image again because of the > spec of the method state this: > >>>> "Loads the image, returning only when the image is loaded." > >>>> > >>>>> ________________________________________ > >>>>> From: Sergey Bylokhov > >>>>> Sent: Sunday, January 19, 2020 9:31 PM > >>>>> To: Volodin, Vladislav; Jason Mehrens > >>>>> Cc: swing-dev at openjdk.java.net > >>>>> Subject: Re: Remove System.out.println from > ImageIcon.loadImage > >>>>> I guess there are no objections, probably the best way to fix > >>>>> it is to drop the System.out.println and set interrupted flag. > >>>>> On 1/16/20 7:05 am, Volodin, Vladislav wrote: > >>>>>> If people in this distribution list agree, I can start working > on a simple fix and either remove the logging (System.out.println), or > replace it with PlatformLogger. I guess the second solution sounds > better, but I don't know what is the better way to write a test-case > for it. > >>>>> -- > >>>>> Best regards, Sergey. > >>>> > >>>> > >>>> -- > >>>> Best regards, Sergey. > >> > >> > >> -- > >> Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Mar 8 23:12:11 2020 From: philip.race at oracle.com (Philip Race) Date: Sun, 08 Mar 2020 16:12:11 -0700 Subject: Remove System.out.println from ImageIcon.loadImage In-Reply-To: References: Message-ID: <5E657BCB.90104@oracle.com> I think you are reading too much into it. The docs are just trying to say its synchronous and you don't need need to use a MediaTracker yourself. Retrying - even once - seems wrong. -phil On 1/21/20, 12:55 PM, Sergey Bylokhov wrote: > On 1/21/20 12:26 pm, Jason Mehrens wrote: >> +1 for Sergey suggestion. > > Or probably we need to try to load the image again because of the spec > of the method state this: > "Loads the image, returning only when the image is loaded." > >> >> ________________________________________ >> From: Sergey Bylokhov >> Sent: Sunday, January 19, 2020 9:31 PM >> To: Volodin, Vladislav; Jason Mehrens >> Cc: swing-dev at openjdk.java.net >> Subject: Re: Remove System.out.println from >> ImageIcon.loadImage >> >> I guess there are no objections, probably the best way to fix >> it is to drop the System.out.println and set interrupted flag. >> >> On 1/16/20 7:05 am, Volodin, Vladislav wrote: >>> If people in this distribution list agree, I can start working on a >>> simple fix and either remove the logging (System.out.println), or >>> replace it with PlatformLogger. I guess the second solution sounds >>> better, but I don't know what is the better way to write a test-case >>> for it. >> >> >> -- >> Best regards, Sergey. >> > > From tejpal.rebari at oracle.com Mon Mar 9 00:03:29 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Mon, 9 Mar 2020 05:33:29 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> Message-ID: <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> Hello Pankaj and Sergey, I have updated the keySet() method and test as per your suggestions. Please take a look. Webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Mon Mar 9 06:12:05 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Sun, 8 Mar 2020 23:12:05 -0700 (PDT) Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> Message-ID: <4ccfd0af-903b-4cf2-b58a-5a6cbeed19d3@default> Hello Tejpal, The product fix part looks ok to me. You are still not following the 80 chars max per line convention in line 44. Also, you don't need to print keysCount and KeySetCount if they are equal. Just add this information in Runtime Exception you are throwing when the test fails. Regards, Pankaj From: Tejpal Rebari Sent: Monday, March 9, 2020 5:33 AM To: Pankaj Bansal ; Sergey Bylokhov Cc: swing-dev at openjdk.java.net Subject: Re: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() Hello Pankaj and Sergey, I have updated the keySet() method and test as per your suggestions. Please take a look. Webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tejpal.rebari at oracle.com Mon Mar 9 06:53:40 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Mon, 9 Mar 2020 12:23:40 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <4ccfd0af-903b-4cf2-b58a-5a6cbeed19d3@default> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <4ccfd0af-903b-4cf2-b58a-5a6cbeed19d3@default> Message-ID: <0842075A-C118-4FA5-B759-EFCEC953C5E7@oracle.com> Thanks for review Pankaj. > On 09-Mar-2020, at 11:42 AM, Pankaj Bansal wrote: > > Hello Tejpal, > > The product fix part looks ok to me. > You are still not following the 80 chars max per line convention in line 44. > Also, you don?t need to print keysCount and KeySetCount if they are equal. Just add this information in Runtime Exception you are throwing when the test fails. > > Regards, > Pankaj I will fix it during the push. Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Mon Mar 9 10:48:52 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 9 Mar 2020 03:48:52 -0700 (PDT) Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: References: Message-ID: Hello Bhawesh, The product change looks good. As discussed in the internal review for moving the test to open from closed repo, please change the test name to a meaningful name and change the copyright year. Also, please follow max 80 characters per line convention. Regards, Pankaj -----Original Message----- From: Bhawesh Choudhary Sent: Wednesday, March 4, 2020 4:13 PM To: swing-dev at openjdk.java.net Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF Hi, Please review this fix, JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ Issue: In Windows LookAndFeel, When navigating Combobox's list of JFileChooser via keys, the contents of JFileChooser changes. Fix: Set flag "JComboBox.isTableCellEditor" to True which prohibits JCombobox from sending selection change event when JCombobox's list selection change happens via keys. Verification: Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as well as BasicLookAndFeel with keys navigation. also added a test case to verify the same. Did not find any misbehavior with the fix. Regards Bhawesh From Sergey.Bylokhov at oracle.com Mon Mar 9 11:47:29 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Mar 2020 04:47:29 -0700 Subject: RFR: 8240690 Race condition between EDT and BasicDirectoryModel.FilesLoader.run0() Message-ID: <2ac1ff2c-6a0a-f706-4847-bca62ff09dc8@oracle.com> Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8240690 Fix: http://cr.openjdk.java.net/~serb/8240690/webrev.01 The test in the webrev has failed from time to time in our CI. It was closed and serialize/deserialize the JFileChooser on the main thread under Motif L&F only. Initially, I thought that the intermittent issues will be fixed by moving the code to EDT. I have done it, and also add a check for all L&Fs. As a result, I was able to reproduce tons of issues related to JFileChooser on all platforms. 1. When we create the JFileChooser and initialize some L&F, we create some background thread that loads the list of files, and only after that adds the list of files to the JFileChooser itself. This is one of the exception where we access the swing component on non EDT, take a look to the changes in BasicDirectoryModel.FilesLoader. I have moved some calls to the JFileChooser from the FilesLoader.run0 which is executed on the background thread to the constructor of FilesLoader which is executed on the EDT. So on the background thread, the "JFileChooser.isTraversable" and "JFileChooser.accept" will be used. These methods are changed to be more multiple-threads friendly(mostly read the property to the local field then check, then use). 2. During serialization, we temporarily reset the FileSystemView of the JFileChooser to the null(it is also possible to do this via public API). This uncovered a few places where we did not expect the null. 3. The "FilesLoader" had a logic of "runnables" blocks of data which should be used to update the JFileChooser by some portions of data. We used the only one "runnable" in the Vector of runnables, but even then it caused a concurrent modification exception if we tried to cancel the task and background thread modified the list of tasks(the list from empty became non-empty). ->> I just replaced it by one reference. Note that this fix works only on top of https://mail.openjdk.java.net/pipermail/swing-dev/2020-March/010155.html otherwise serialization just does not work on macOS. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Mar 9 11:57:08 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Mar 2020 04:57:08 -0700 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> Message-ID: Hi, Tejpal. Do not you need to call super.keySet() as well? +set.addAll(super.keySet()); return set; similar to public Set> entrySet() {...} It would be good to update the test to cover this. On 3/8/20 5:03 pm, Tejpal Rebari wrote: > Hello Pankaj and Sergey, > > I have updated the keySet() method and test as per your suggestions. > Please take a look. > > Webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ > > Regards > Tejpal -- Best regards, Sergey. From jason_mehrens at hotmail.com Mon Mar 9 18:33:29 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 9 Mar 2020 18:33:29 +0000 Subject: Remove System.out.println from ImageIcon.loadImage In-Reply-To: <5E657814.6020806@oracle.com> References: , <6CA1C9A2-3FE1-445D-93B7-57DC8818F0FB@sap.com>, , , , , , , <5E657814.6020806@oracle.com> Message-ID: Phil, Point 6, "The worst thing you can do with InterruptedException is swallow it -- catch it and neither rethrow it nor reassert the thread's interrupted status." -Brian Goetz https://www.ibm.com/developerworks/library/j-jtp05236/index.html The swallowing of interrupts interferes with implementing cooperative cancelable tasks. For modal dialogs like the JOptionPane, interrupting the EDT from the application thread can be used to cancel modal blocking. The JOptionPane for INFO, ERROR, WARNING icons shown are provided by the ImageIcon class which means the ImageIcon can if the timing is just right swallow the interrupt that is important for the JOptionPane to see as a signal not wait. Jason ________________________________________ From: Philip Race Sent: Sunday, March 8, 2020 5:56 PM To: Volodin, Vladislav Cc: Jason Mehrens; swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage 1) That bug is still closed. Did you want it re-opened ? I've just done so. BTW I don't know why, but it was closed less than 3 months ago by an engineer from the hotspot team (!?) I have NO idea why since there is no comment. 2) If you are starting a review thread for a bug, the email subject line should have the bug id and its synopsis thus : RFR: 6421373: ImageIcon does not reassert interrupt status. Although depending on what we end up doing the synopsis may need to change (see 6 + 7 below). 3) The test has very long lines. Please curtail them to 80 chars. 4) What Christoph said. 5) I know where it was coming from, but I wish the docs said "Returns when the image is loaded, or loading has failed. Call getImageLoadStatus()" to check this." Also a whole bunch of other questions arise like what should happen if you call setImage() twice for different images. If the first image succeeded, but the second failed, then what ? 6) I am not completely sold on reasserting the interrupted status since it is a change of behaviour and you will need an approved CSR to push this. Not sure if you need to update the javadoc as well ... 7) Now .. if all you really wanted was to get rid of the print statement this is a lot of effort with some compatibility impact. -phil. On 2/22/20, 2:38 AM, Volodin, Vladislav wrote: Hello Jason and everyone else, here is my webrev that my colleague published http://cr.openjdk.java.net/~clanger/webrevs/6421373.0/ Can you please review it and let me know if I should change anything? Currently I am OOO, but I will do the changes in March. Kind regards, Vlad Get Outlook for iOS ________________________________ From: Jason Mehrens Sent: Tuesday, February 11, 2020 9:13:41 PM To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage Vlad, Yea that looks good. Jason ________________________________________ From: Volodin, Vladislav Sent: Wednesday, February 5, 2020 9:59 AM To: Jason Mehrens Cc: swing-dev at openjdk.java.net Subject: RE: Remove System.out.println from ImageIcon.loadImage Hi Jason, thank you for your advice. I have changed my code, now it simulates the behavior of the interrupted thread. Can you please check my patch? I don't have the "bug" ticket, so in my test case "@bug JDK-123456" should be adjusted. I will appreciate if you and somebody else can review my patch and submit it to JDK. Thanks, Vlad -----Original Message----- From: Jason Mehrens Sent: Mittwoch, 29. Januar 2020 17:55 To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage 1. Agreed. 2. I was just pulling from the jdk8 source (because I'm lazy) to express the idea. Feel free to adjust. 3. Reasserting in the finally ensure we are not forcefully setting the interrupted status on the current thread and calling 'statusID' and 'removeImage'. It also ensures that the interrupt is set even if an unexpected exception is thrown. Reasserting at the end of 'e1' and never in 'e2' should work too. The main issue that I'm trying to convey to you is that your test is incomplete in that it does check that the interrupt was swallowed. Swallowing interrupts is bad practice. Reasserting in e2 only means that we swallow interrupts from e1. Change your test to this and retest: === public static void main(String[] args) throws Exception { Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); Thread.currentThread().interrupt(); ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { throw new RuntimeException("Couldn't load GIF from bytes after interruption"); } if (!Thread.currentThread().isInterrupted()) { throw new RuntimeException("Interrupt was swallowed"); } } } === ________________________________________ From: Volodin, Vladislav Sent: Wednesday, January 29, 2020 9:52 AM To: Jason Mehrens Cc: swing-dev at openjdk.java.net Subject: RE: Remove System.out.println from ImageIcon.loadImage Hi Jason, I have few questions: 1. The second assignment is probably redundant: } catch (InterruptedException e1) { wasInterrupted = true; // line #2, see comment below try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; wasInterrupted = true; // <-- this is redundant, because of the line #2 } } finally { 2. I think the first call of "addImage" is not necessary: boolean wasInterrupted = false; mTracker.addImage(image, id); // maybe I should remove this, because of another comment down below. try { loadStatus = 0; mTracker.addImage(image, id); // because of that May I also ask you a question? What is the purpose of interrupting the current thread in the finally block, instead of doing it in the second catch block (where e2 is created)? I assume that since we were able to handle the exception properly, and plus the entire block is in the synchronization area, in theory we have only one importer at the time. Kind regards, Vlad -----Original Message----- From: Jason Mehrens Sent: Mittwoch, 29. Januar 2020 16:35 To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage Bug in that last version: Thread.currentThread().isInterrupted(); -> Thread.currentThread().interrupt(); === protected void loadImage(Image image) { MediaTracker mTracker = getTracker(); synchronized (mTracker) { int id = getNextID(); boolean wasInterrupted = false; mTracker.addImage(image, id); try { loadStatus = 0; mTracker.addImage(image, id); mTracker.waitForID(id, 0); } catch (InterruptedException e1) { wasInterrupted = true; try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; wasInterrupted = true; } } finally { if (loadStatus == 0) { loadStatus = mTracker.statusID(id, false); } mTracker.removeImage(image, id); if (wasInterrupted) { Thread.currentThread().interrupt(); } } } } === ________________________________________ From: swing-dev on behalf of Jason Mehrens Sent: Wednesday, January 29, 2020 9:33 AM To: Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage A shorter version is just to reassert at the end of catch e1. It is safer to just reassert as the last statement in the finally. === protected void loadImage(Image image) { MediaTracker mTracker = getTracker(); synchronized (mTracker) { int id = getNextID(); boolean wasInterrupted = false; mTracker.addImage(image, id); try { loadStatus = 0; mTracker.addImage(image, id); mTracker.waitForID(id, 0); } catch (InterruptedException e1) { wasInterrupted = true; try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; } } finally { if (loadStatus == 0) { loadStatus = mTracker.statusID(id, false); } mTracker.removeImage(image, id); if (wasInterrupted) { Thread.currentThread().isInterrupted(); } } } } === Jason ________________________________________ From: Volodin, Vladislav Sent: Tuesday, January 28, 2020 4:02 PM To: Jason Mehrens Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage This is a valid point, because I wasn?t sure that when the thread is interrupted, I handled the first exception, and my thought was that all other ?wait? calls (maybe in other threads) should get the same exception as well. And since I handled this exceptional case, I am restoring the interrupted status in case if I don?t know how to handle this exception the second time. } catch (InterruptedException e1) { try { mTracker.waitForID(id, 0); } catch (InterruptedException e2) { loadStatus = MediaTracker.ABORTED; Thread.currentThread().interrupt(); } If I restore the interrupted status BEFORE waitForID call, then this thread will immoderately fail. Should I restore it AFTER, e.g. } catch (InterruptedException e1) { try { mTracker.waitForID(id, 0); Thread.currentThread().interrupt(); // On 28. Jan 2020, at 22:27, Jason Mehrens wrote: > > ?I see. Well I would have to do some more digging and testing to make myself more knowledgeable on MediaTracker. > > Then the only bug in your current code is that you are not reasserting interrupted status of the current thread in the case e1 is raised and e2 is not. It is usually best to reassert the interrupted state at the end of the method. > > Jason > > ________________________________________ > From: Volodin, Vladislav > Sent: Tuesday, January 28, 2020 2:54 PM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > Hi Jason, > > I am not sure about the loop, because I don?t know if we can trust results from mTracker.statusID at the moment when an exceptional case occurs. For example, I was experimenting with the code and found out that the MediaTracker can spawn a thread to load the image, or might use the current thread, and the ABORTED state is never returned (I don?t even know how to raise this state). That is why I don?t even know if your loop will ever stop. > > In my solution, I give the second chance only, and in case if the execution was interrupted the second time, I explicitly assign the ABORTED state to loadStatus. If the user wants to load this image once again, he can create ImageIcon again (or even do this in a loop), or reinitialize it with a single method (I don?t remember its name). > > What do you think? > > Kind regards, > Vlad > > Sent from myPad > >> On 28. Jan 2020, at 21:34, Jason Mehrens wrote: >> >> ?Vlad, >> >> I assume you would want to wait in a loop and reassert the interrupt at the end. >> >> === >> protected void loadImage(Image image) { >> MediaTracker mTracker = getTracker(); >> synchronized(mTracker) { >> int id = getNextID(); >> >> mTracker.addImage(image, id); >> boolean wasInterrupted = false; >> try { >> do { >> try { >> mTracker.waitForID(id, 0); >> } catch (InterruptedException e) { >> wasInterrupted = true; >> } >> loadStatus = mTracker.statusID(id, false); >> } while (loadStatus == MediaTracker.LOADING); >> mTracker.removeImage(image, id); >> >> width = image.getWidth(imageObserver); >> height = image.getHeight(imageObserver); >> } finally { >> if (wasInterrupted) { >> Thread.currentThread().interrupt(); >> } >> } >> } >> } >> === >> >> Jason >> ________________________________________ >> From: swing-dev on behalf of Volodin, Vladislav >> Sent: Monday, January 27, 2020 11:11 AM >> To: Sergey Bylokhov >> Cc: swing-dev at openjdk.java.net >> Subject: Re: Remove System.out.println from ImageIcon.loadImage >> >> Hello Sergey, and others, >> >> here is the patch (made with "git diff") in the attachment. I have read that sometimes the attachments are lost. So here is my version with few comments regarding my code. I decided to use your approach with a small improvement. There is an excerpt of my patch. >> >> The idea is pretty simple: >> 1. I create an empty gif 1x1; >> 2. Initialize DefaultToolkit (I plan to interrupt the main thread, and if I do not initialize the toolkit in advance, my test will fail at the beginning >> 3. Interrupt the main thread >> 4. Try to load the icon: >> >> import javax.swing.*; >> import java.awt.*; >> >> public class imageIconInterrupted { >> static byte[] EMPTY_GIF = new byte[]{ >> (byte) 0x47, (byte) 0x49, (byte) 0x46, (byte) 0x38, (byte) 0x39, (byte) 0x61, (byte) 0x01, (byte) 0x00, >> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x21, (byte) 0xF9, (byte) 0x04, >> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x2C, (byte) 0x00, (byte) 0x00, >> (byte) 0x00, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x02 >> }; >> >> public static void main(String[] args) throws Exception { >> Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); >> >> Thread.currentThread().interrupt(); >> ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); >> if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { >> throw new RuntimeException("Couldn't load GIF from bytes after interruption"); >> } >> } >> } >> >> The code of loadImage I have changed as follows: >> 1. I clear loadStatus for "finally" part; >> 2. Check the interruption according to your comments; >> 3. Change the status to ABORTED, if the interruption happened again (this part I cannot test, because I cannot properly interrupt the thread whenever I want. Multithreading is quite fragile there :( ) >> 4. update the status "interrupted" again; >> 5. and then - finally block. >> >> protected void loadImage(Image image) { >> ... >> try { >> loadStatus = 0; >> mTracker.addImage(image, id); >> mTracker.waitForID(id, 0); >> } catch (InterruptedException e1) { >> try { >> mTracker.waitForID(id, 0); >> } catch (InterruptedException e2) { >> loadStatus = MediaTracker.ABORTED; >> Thread.currentThread().interrupt(); >> } >> } finally { >> if (loadStatus == 0) { >> loadStatus = mTracker.statusID(id, false); >> } >> mTracker.removeImage(image, id); >> } >> >> P.S. if you think that my patch sounds fine, I will find a sponsor for the bug report and the patch preparation, so you can review it later. >> After the second attempt, my EMPTY_GIF was loaded successfully. The ABORTED part it seems that I don't know if it has ever worked. My patch (in the attachment) checks also the state ERROR for the URL that doesn't exist. Something like: >> >> ImageIcon iconNotExist = new ImageIcon(new URL("http://doesnt.exist.anywhere/1.gif")); // I am not sure if I spelled this URL grammatically correct >> if (iconNotExist.getImageLoadStatus() != MediaTracker.ERRORED) { >> throw new RuntimeException("Got unexpected status from non-existing GIF"); >> } >> >> Thanks to everyone. >> >> Kind regards, >> Vlad >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Dienstag, 21. Januar 2020 22:26 >> To: Volodin, Vladislav >> Cc: Jason Mehrens ; swing-dev at openjdk.java.net >> Subject: Re: Remove System.out.println from ImageIcon.loadImage >> >>>> On 1/21/20 1:14 pm, Volodin, Vladislav wrote: >>> Hi all, >>> >>> If I am not mistaken, this method is called from the constructor and other methods. How long should we try loading the icon using the unmanaged (by any thread pool, but I am not sure about this statement) thread? >>> >>> We don?t even have the flag ?interrupted?. So technically this icon has to be loaded. >> >> I think it is necessary to save the "interrupted" state in the catch >> block and try to call waitForID() again. It will be necessary to set >> "interrupted" flag for the Thread after that(when the waitForID will >> return without exception). >> >> >>> Sent from myFone >>> >>>>> On 21. Jan 2020, at 21:55, Sergey Bylokhov wrote: >>>> >>>> ?On 1/21/20 12:26 pm, Jason Mehrens wrote: >>>>> +1 for Sergey suggestion. >>>> >>>> Or probably we need to try to load the image again because of the spec of the method state this: >>>> "Loads the image, returning only when the image is loaded." >>>> >>>>> ________________________________________ >>>>> From: Sergey Bylokhov >>>>> Sent: Sunday, January 19, 2020 9:31 PM >>>>> To: Volodin, Vladislav; Jason Mehrens >>>>> Cc: swing-dev at openjdk.java.net >>>>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>>>> I guess there are no objections, probably the best way to fix >>>>> it is to drop the System.out.println and set interrupted flag. >>>>> On 1/16/20 7:05 am, Volodin, Vladislav wrote: >>>>>> If people in this distribution list agree, I can start working on a simple fix and either remove the logging (System.out.println), or replace it with PlatformLogger. I guess the second solution sounds better, but I don't know what is the better way to write a test-case for it. >>>>> -- >>>>> Best regards, Sergey. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. From philip.race at oracle.com Mon Mar 9 18:48:01 2020 From: philip.race at oracle.com (Phil Race) Date: Mon, 9 Mar 2020 11:48:01 -0700 Subject: Remove System.out.println from ImageIcon.loadImage In-Reply-To: References: <6CA1C9A2-3FE1-445D-93B7-57DC8818F0FB@sap.com> <5E657814.6020806@oracle.com> Message-ID: <19f3d745-a13c-4407-fa10-82b2234d4750@oracle.com> I am not arguing the general case. I am addressing this case where we have long standing behaviour. And I can't find anywhere JOptionPane or similar is calling interrupt(). -phil On 3/9/20 11:33 AM, Jason Mehrens wrote: > Phil, > > Point 6, "The worst thing you can do with InterruptedException is swallow it -- catch it and neither rethrow it nor reassert the thread's interrupted status." -Brian Goetz > https://www.ibm.com/developerworks/library/j-jtp05236/index.html > > The swallowing of interrupts interferes with implementing cooperative cancelable tasks. For modal dialogs like the JOptionPane, interrupting the EDT from the application thread can be used to cancel modal blocking. The JOptionPane for INFO, ERROR, WARNING icons shown are provided by the ImageIcon class which means the ImageIcon can if the timing is just right swallow the interrupt that is important for the JOptionPane to see as a signal not wait. > > Jason > > > ________________________________________ > From: Philip Race > Sent: Sunday, March 8, 2020 5:56 PM > To: Volodin, Vladislav > Cc: Jason Mehrens; swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > 1) That bug is still closed. Did you want it re-opened ? I've just done so. > BTW I don't know why, but it was closed less than 3 months ago > by an engineer from the hotspot team (!?) I have NO idea why > since there is no comment. > > 2) If you are starting a review thread for a bug, the email subject line > should have the bug id and its synopsis thus : > RFR: 6421373: ImageIcon does not reassert interrupt status. > Although depending on what we end up doing the synopsis may > need to change (see 6 + 7 below). > > 3) The test has very long lines. Please curtail them to 80 chars. > > 4) What Christoph said. > > 5) I know where it was coming from, but I wish the docs said > "Returns when the image is loaded, or loading has failed. > Call getImageLoadStatus()" to check this." > Also a whole bunch of other questions arise like what > should happen if you call setImage() twice for different images. > If the first image succeeded, but the second failed, then what ? > > 6) I am not completely sold on reasserting the interrupted status > since it is a change of behaviour and you will need an approved CSR > to push this. Not sure if you need to update the javadoc as well ... > > 7) Now .. if all you really wanted was to get rid of the print statement > this is a lot of effort with some compatibility impact. > > -phil. > > > > On 2/22/20, 2:38 AM, Volodin, Vladislav wrote: > Hello Jason and everyone else, > > here is my webrev that my colleague published http://cr.openjdk.java.net/~clanger/webrevs/6421373.0/ > Can you please review it and let me know if I should change anything? Currently I am OOO, but I will do the changes in March. > > Kind regards, > Vlad > > Get Outlook for iOS > ________________________________ > From: Jason Mehrens > Sent: Tuesday, February 11, 2020 9:13:41 PM > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > Vlad, > > Yea that looks good. > > Jason > > ________________________________________ > From: Volodin, Vladislav > Sent: Wednesday, February 5, 2020 9:59 AM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: RE: Remove System.out.println from ImageIcon.loadImage > > Hi Jason, > > thank you for your advice. I have changed my code, now it simulates the behavior of the interrupted thread. Can you please check my patch? > I don't have the "bug" ticket, so in my test case "@bug JDK-123456" should be adjusted. > > I will appreciate if you and somebody else can review my patch and submit it to JDK. > > Thanks, > Vlad > > -----Original Message----- > From: Jason Mehrens > Sent: Mittwoch, 29. Januar 2020 17:55 > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > 1. Agreed. > 2. I was just pulling from the jdk8 source (because I'm lazy) to express the idea. Feel free to adjust. > 3. Reasserting in the finally ensure we are not forcefully setting the interrupted status on the current thread and calling 'statusID' and 'removeImage'. It also ensures that the interrupt is set even if an unexpected exception is thrown. Reasserting at the end of 'e1' and never in 'e2' should work too. > > The main issue that I'm trying to convey to you is that your test is incomplete in that it does check that the interrupt was swallowed. Swallowing interrupts is bad practice. Reasserting in e2 only means that we swallow interrupts from e1. > > Change your test to this and retest: > === > public static void main(String[] args) throws Exception { > Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); > > Thread.currentThread().interrupt(); > ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); > if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { > throw new RuntimeException("Couldn't load GIF from bytes after interruption"); > } > > if (!Thread.currentThread().isInterrupted()) { > throw new RuntimeException("Interrupt was swallowed"); > } > } > } > === > ________________________________________ > From: Volodin, Vladislav > Sent: Wednesday, January 29, 2020 9:52 AM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: RE: Remove System.out.println from ImageIcon.loadImage > > Hi Jason, > > I have few questions: > > 1. The second assignment is probably redundant: > > } catch (InterruptedException e1) { > wasInterrupted = true; // line #2, see comment below > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > wasInterrupted = true; // <-- this is redundant, because of the line #2 > } > } finally { > > 2. I think the first call of "addImage" is not necessary: > > boolean wasInterrupted = false; > mTracker.addImage(image, id); // maybe I should remove this, because of another comment down below. > try { > loadStatus = 0; > mTracker.addImage(image, id); // because of that > > May I also ask you a question? > What is the purpose of interrupting the current thread in the finally block, instead of doing it in the second catch block (where e2 is created)? I assume that since we were able to handle the exception properly, and plus the entire block is in the synchronization area, in theory we have only one importer at the time. > > Kind regards, > Vlad > > -----Original Message----- > From: Jason Mehrens > Sent: Mittwoch, 29. Januar 2020 16:35 > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > Bug in that last version: > Thread.currentThread().isInterrupted(); -> Thread.currentThread().interrupt(); > === > protected void loadImage(Image image) { > MediaTracker mTracker = getTracker(); > synchronized (mTracker) { > int id = getNextID(); > > boolean wasInterrupted = false; > mTracker.addImage(image, id); > try { > loadStatus = 0; > mTracker.addImage(image, id); > mTracker.waitForID(id, 0); > } catch (InterruptedException e1) { > wasInterrupted = true; > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > wasInterrupted = true; > } > } finally { > if (loadStatus == 0) { > loadStatus = mTracker.statusID(id, false); > } > mTracker.removeImage(image, id); > if (wasInterrupted) { > Thread.currentThread().interrupt(); > } > } > } > } > === > > ________________________________________ > From: swing-dev on behalf of Jason Mehrens > Sent: Wednesday, January 29, 2020 9:33 AM > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > A shorter version is just to reassert at the end of catch e1. It is safer to just reassert as the last statement in the finally. > > === > protected void loadImage(Image image) { > MediaTracker mTracker = getTracker(); > synchronized (mTracker) { > int id = getNextID(); > > boolean wasInterrupted = false; > mTracker.addImage(image, id); > try { > loadStatus = 0; > mTracker.addImage(image, id); > mTracker.waitForID(id, 0); > } catch (InterruptedException e1) { > wasInterrupted = true; > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > } > } finally { > if (loadStatus == 0) { > loadStatus = mTracker.statusID(id, false); > } > mTracker.removeImage(image, id); > if (wasInterrupted) { > Thread.currentThread().isInterrupted(); > } > } > } > } > === > > Jason > ________________________________________ > From: Volodin, Vladislav > Sent: Tuesday, January 28, 2020 4:02 PM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > This is a valid point, because I wasn?t sure that when the thread is interrupted, I handled the first exception, and my thought was that all other ?wait? calls (maybe in other threads) should get the same exception as well. > > And since I handled this exceptional case, I am restoring the interrupted status in case if I don?t know how to handle this exception the second time. > > } catch (InterruptedException e1) { > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > Thread.currentThread().interrupt(); > } > > If I restore the interrupted status BEFORE waitForID call, then this thread will immoderately fail. Should I restore it AFTER, e.g. > > } catch (InterruptedException e1) { > try { > mTracker.waitForID(id, 0); > Thread.currentThread().interrupt(); // } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > Thread.currentThread().interrupt(); > } > > Thanks, > Vlad > > Sent from myPad > >> On 28. Jan 2020, at 22:27, Jason Mehrens wrote: >> >> ?I see. Well I would have to do some more digging and testing to make myself more knowledgeable on MediaTracker. >> >> Then the only bug in your current code is that you are not reasserting interrupted status of the current thread in the case e1 is raised and e2 is not. It is usually best to reassert the interrupted state at the end of the method. >> >> Jason >> >> ________________________________________ >> From: Volodin, Vladislav >> Sent: Tuesday, January 28, 2020 2:54 PM >> To: Jason Mehrens >> Cc: swing-dev at openjdk.java.net >> Subject: Re: Remove System.out.println from ImageIcon.loadImage >> >> Hi Jason, >> >> I am not sure about the loop, because I don?t know if we can trust results from mTracker.statusID at the moment when an exceptional case occurs. For example, I was experimenting with the code and found out that the MediaTracker can spawn a thread to load the image, or might use the current thread, and the ABORTED state is never returned (I don?t even know how to raise this state). That is why I don?t even know if your loop will ever stop. >> >> In my solution, I give the second chance only, and in case if the execution was interrupted the second time, I explicitly assign the ABORTED state to loadStatus. If the user wants to load this image once again, he can create ImageIcon again (or even do this in a loop), or reinitialize it with a single method (I don?t remember its name). >> >> What do you think? >> >> Kind regards, >> Vlad >> >> Sent from myPad >> >>> On 28. Jan 2020, at 21:34, Jason Mehrens wrote: >>> >>> ?Vlad, >>> >>> I assume you would want to wait in a loop and reassert the interrupt at the end. >>> >>> === >>> protected void loadImage(Image image) { >>> MediaTracker mTracker = getTracker(); >>> synchronized(mTracker) { >>> int id = getNextID(); >>> >>> mTracker.addImage(image, id); >>> boolean wasInterrupted = false; >>> try { >>> do { >>> try { >>> mTracker.waitForID(id, 0); >>> } catch (InterruptedException e) { >>> wasInterrupted = true; >>> } >>> loadStatus = mTracker.statusID(id, false); >>> } while (loadStatus == MediaTracker.LOADING); >>> mTracker.removeImage(image, id); >>> >>> width = image.getWidth(imageObserver); >>> height = image.getHeight(imageObserver); >>> } finally { >>> if (wasInterrupted) { >>> Thread.currentThread().interrupt(); >>> } >>> } >>> } >>> } >>> === >>> >>> Jason >>> ________________________________________ >>> From: swing-dev on behalf of Volodin, Vladislav >>> Sent: Monday, January 27, 2020 11:11 AM >>> To: Sergey Bylokhov >>> Cc: swing-dev at openjdk.java.net >>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>> >>> Hello Sergey, and others, >>> >>> here is the patch (made with "git diff") in the attachment. I have read that sometimes the attachments are lost. So here is my version with few comments regarding my code. I decided to use your approach with a small improvement. There is an excerpt of my patch. >>> >>> The idea is pretty simple: >>> 1. I create an empty gif 1x1; >>> 2. Initialize DefaultToolkit (I plan to interrupt the main thread, and if I do not initialize the toolkit in advance, my test will fail at the beginning >>> 3. Interrupt the main thread >>> 4. Try to load the icon: >>> >>> import javax.swing.*; >>> import java.awt.*; >>> >>> public class imageIconInterrupted { >>> static byte[] EMPTY_GIF = new byte[]{ >>> (byte) 0x47, (byte) 0x49, (byte) 0x46, (byte) 0x38, (byte) 0x39, (byte) 0x61, (byte) 0x01, (byte) 0x00, >>> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x21, (byte) 0xF9, (byte) 0x04, >>> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x2C, (byte) 0x00, (byte) 0x00, >>> (byte) 0x00, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x02 >>> }; >>> >>> public static void main(String[] args) throws Exception { >>> Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); >>> >>> Thread.currentThread().interrupt(); >>> ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); >>> if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { >>> throw new RuntimeException("Couldn't load GIF from bytes after interruption"); >>> } >>> } >>> } >>> >>> The code of loadImage I have changed as follows: >>> 1. I clear loadStatus for "finally" part; >>> 2. Check the interruption according to your comments; >>> 3. Change the status to ABORTED, if the interruption happened again (this part I cannot test, because I cannot properly interrupt the thread whenever I want. Multithreading is quite fragile there :( ) >>> 4. update the status "interrupted" again; >>> 5. and then - finally block. >>> >>> protected void loadImage(Image image) { >>> ... >>> try { >>> loadStatus = 0; >>> mTracker.addImage(image, id); >>> mTracker.waitForID(id, 0); >>> } catch (InterruptedException e1) { >>> try { >>> mTracker.waitForID(id, 0); >>> } catch (InterruptedException e2) { >>> loadStatus = MediaTracker.ABORTED; >>> Thread.currentThread().interrupt(); >>> } >>> } finally { >>> if (loadStatus == 0) { >>> loadStatus = mTracker.statusID(id, false); >>> } >>> mTracker.removeImage(image, id); >>> } >>> >>> P.S. if you think that my patch sounds fine, I will find a sponsor for the bug report and the patch preparation, so you can review it later. >>> After the second attempt, my EMPTY_GIF was loaded successfully. The ABORTED part it seems that I don't know if it has ever worked. My patch (in the attachment) checks also the state ERROR for the URL that doesn't exist. Something like: >>> >>> ImageIcon iconNotExist = new ImageIcon(new URL("http://doesnt.exist.anywhere/1.gif")); // I am not sure if I spelled this URL grammatically correct >>> if (iconNotExist.getImageLoadStatus() != MediaTracker.ERRORED) { >>> throw new RuntimeException("Got unexpected status from non-existing GIF"); >>> } >>> >>> Thanks to everyone. >>> >>> Kind regards, >>> Vlad >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Dienstag, 21. Januar 2020 22:26 >>> To: Volodin, Vladislav >>> Cc: Jason Mehrens ; swing-dev at openjdk.java.net >>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>> >>>>> On 1/21/20 1:14 pm, Volodin, Vladislav wrote: >>>> Hi all, >>>> >>>> If I am not mistaken, this method is called from the constructor and other methods. How long should we try loading the icon using the unmanaged (by any thread pool, but I am not sure about this statement) thread? >>>> >>>> We don?t even have the flag ?interrupted?. So technically this icon has to be loaded. >>> I think it is necessary to save the "interrupted" state in the catch >>> block and try to call waitForID() again. It will be necessary to set >>> "interrupted" flag for the Thread after that(when the waitForID will >>> return without exception). >>> >>> >>>> Sent from myFone >>>> >>>>>> On 21. Jan 2020, at 21:55, Sergey Bylokhov wrote: >>>>> ?On 1/21/20 12:26 pm, Jason Mehrens wrote: >>>>>> +1 for Sergey suggestion. >>>>> Or probably we need to try to load the image again because of the spec of the method state this: >>>>> "Loads the image, returning only when the image is loaded." >>>>> >>>>>> ________________________________________ >>>>>> From: Sergey Bylokhov >>>>>> Sent: Sunday, January 19, 2020 9:31 PM >>>>>> To: Volodin, Vladislav; Jason Mehrens >>>>>> Cc: swing-dev at openjdk.java.net >>>>>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>>>>> I guess there are no objections, probably the best way to fix >>>>>> it is to drop the System.out.println and set interrupted flag. >>>>>> On 1/16/20 7:05 am, Volodin, Vladislav wrote: >>>>>>> If people in this distribution list agree, I can start working on a simple fix and either remove the logging (System.out.println), or replace it with PlatformLogger. I guess the second solution sounds better, but I don't know what is the better way to write a test-case for it. >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> -- >>> Best regards, Sergey. From pankaj.b.bansal at oracle.com Tue Mar 10 06:00:51 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 10 Mar 2020 11:30:51 +0530 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: References: Message-ID: <5bc80d2b-f6f1-53fd-0b9d-98446d7fbe47@oracle.com> Hello Sergey, The changes look fine. Regards, Pankaj On 08/03/20 3:50 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk/client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240633 > Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00 > > Our tests in mach5 for JFileChooser sometime fails with different > suspicious exceptions. The root cause is that the Aqua UI delegates > add various listeners to the JFileChooser, and never delete them. > So these Aqua related listeners may fail if current L&F was changed. > > In the fix we will "uninstall" all child components for the > AquaFileChooserUI. > > Also in the AquaFileChooserUI we had added model as a > PropertyChangeListener twice, > and never removed the filterComboBoxModel. > From prasanta.sadhukhan at oracle.com Tue Mar 10 07:01:21 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 10 Mar 2020 12:31:21 +0530 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: References: Message-ID: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> Hi Sergey, There are some ActionListeners that we add, namely for fileNameTextField, directoryComboBox, filterComboBox, approveButton, cancelButton. Shouldn't we remove those as has been done in Metal/Windows L&F uninstallUI? I see uninstallUI does not do removeActionListener, or else proabably we could just add fileNameTextField.uninstallUI() along with the fix? Regards Prasanta On 08-Mar-20 3:50 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk/client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240633 > Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00 > > Our tests in mach5 for JFileChooser sometime fails with different > suspicious exceptions. The root cause is that the Aqua UI delegates > add various listeners to the JFileChooser, and never delete them. > So these Aqua related listeners may fail if current L&F was changed. > > In the fix we will "uninstall" all child components for the > AquaFileChooserUI. > > Also in the AquaFileChooserUI we had added model as a > PropertyChangeListener twice, > and never removed the filterComboBoxModel. > From tejpal.rebari at oracle.com Tue Mar 10 08:04:30 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Tue, 10 Mar 2020 13:34:30 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> Message-ID: <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> Hi Sergey, > On 09-Mar-2020, at 5:27 PM, Sergey Bylokhov wrote: > > Hi, Tejpal. > Do not you need to call super.keySet() as well? > +set.addAll(super.keySet()); > return set; Yes, will update this. > > similar to public Set> entrySet() {...} > > It would be good to update the test to cover this. I am not getting how to cover this in the test. Isn?t comparing the number of elements in the Enumeration and Set not enough. Thanks Tejpal From pankaj.b.bansal at oracle.com Tue Mar 10 12:34:30 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 10 Mar 2020 18:04:30 +0530 Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: References: <92ca9fe1-6bbc-47c6-bc62-3f78ae7c7194@oracle.com> <4db1f723-0f5a-4d66-8db6-529897885d79@default> <4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default> <75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> Message-ID: <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> Hello Sergey/Vlad/Alexey, Sorry, I could not reply to this earlier. I have one doubt about this approach. Won't the calculation of stepCount itself suffer from floating point issue? I mean the user will pass min, max, stepsize, then wont the calculation of steps required to go from min to max will also suffer from same floating point issue? I think there can be an rounding of error of -1 or +1 in calculation of step count. eg. int steps =0; for (double i=min+stepsize; i<=max; i+=stepsize) steps++; double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. The reason is that, there is floating point error in first case, but it is not present in second case. I think the best we can do here is as Sergey suggested in his first reply to use Math.fma to reduce the floating point error chances from 2 to 1 or just close this as not an issue Regards, Pankaj On 19/02/20 3:49 AM, Sergey Bylokhov wrote: > I think it should work, the step will counts from the default value. > > So currently: > 1. if the user set default value to X1 and then he iterates forward > 100 times then he will get some X2. During this calculation, he could > get "100" rounding issues. > 2. If later the user decides iterates backward then most probably he > will not get X1, and the amount of possible "rounding issues" will be > 200. > > If the user will repeat steps 1. and 2. then each time the values will > "float". > > If we will use counter then in the worst case we will get only two > roundings per step: X1+step*100 = X2(if we will use fma we will get > only one for every step). > > It will not solve all issues but at least will make the iteration > "stable". > > On 2/17/20 1:59 am, Alexey Ivanov wrote: >> Hi Vlad, >> >> The idea looks reasonable. However, it does not allow for manual >> editing. The cases where max and min values are not multiples of step >> would be hard to handle with this approach. For example: max = 10.05, >> min = 0.01, step = 0.1; how many ticks are there? What if the user >> enters 1.01015; the value should change to 1.11015 or 0.91015. >> >> On 13/02/2020 22:22, Volodin, Vladislav wrote: >>> Hello Sergey, Alexey and Pankaj, >>> >>> I am reading the current discussion and I was thinking about an idea >>> changing the code in the way that instead of working with >>> float/double numbers we work with integer ticks. For example, the >>> model remembers the min/max/step values and calculates a number of >>> steps required to reach from min to max. All increment/decrement >>> actions are done against the current ?tick? value. If the current >>> ?tick? reaches 0 - we return min; if maxTick ? we return max. And >>> the current value can be always counted as (min + tick * step) if >>> tick is neither zero, nor max tick count. >>> >>> At least if we deal with integer ticks, but all reading operations >>> calculate on the fly, we will be able to control the >>> representativeness of output. >>> >>> As always, I don?t know all the details and possible consequences, >>> so feel free to ignore my email, if I am wrong. >>> >>> Kind regards, >>> Vlad >>> >>> Sent from myPad >>> >>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov >>>> wrote: >>>> >>>> ?On 2/12/20 8:21 am, Alexey Ivanov wrote: >>>>> The bug report says that going from -0.15 to -0.10 does not allow >>>>> going back to -0.15. This happens because the result of this >>>>> sequence of operations cannot be represented exactly, or, in other >>>>> words, because of rounding errors; or rather the result is less >>>>> than the set minimal value. >>>>> Can we set the value of the spinner to the set minimal value >>>>> instead of disallowing the operation. I mean, after going up the >>>>> displayed value is -0.10; going down by 0.05 gives the result >>>>> which is less than the minimal value for the spinner, and thus >>>>> going down is not allowed. What if we set the value of the spinner >>>>> to its minimal value instead? >>>> In this case, we will need to update all types including int. Isn't >>>> it will be surprised that the spinner will show the value which is >>>> not calculated as >>>> "defaultValue + stepValue * stepCount"? >>>> >>>> >>>> -- >>>> Best regards, Sergey. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason_mehrens at hotmail.com Tue Mar 10 18:28:30 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 10 Mar 2020 18:28:30 +0000 Subject: Remove System.out.println from ImageIcon.loadImage In-Reply-To: <19f3d745-a13c-4407-fa10-82b2234d4750@oracle.com> References: <6CA1C9A2-3FE1-445D-93B7-57DC8818F0FB@sap.com> <5E657814.6020806@oracle.com> , <19f3d745-a13c-4407-fa10-82b2234d4750@oracle.com> Message-ID: Phil, Good deal. My misunderstanding. So on to the long standing behavior argument. I can build this example test out more if needed but hopefully it is enough to understand how the EDT can be interrupted in a multi-thread swing app that supports cooperative thread cancellation. Use of SwingWorker and or FutureTask propagate interrupt to EDT via Future::cancel(true). === import java.awt.Component; import java.util.concurrent.Callable; import java.util.concurrent.ExecutionException; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Future; import java.util.concurrent.FutureTask; import java.util.concurrent.TimeUnit; import java.util.concurrent.TimeoutException; import javax.swing.*; public class DialogTest { public static T invokeAndWait(Callable c, long timeout, TimeUnit unit) throws InterruptedException, TimeoutException, ExecutionException { Objects.requireNonNull(unit); FutureTask f = new FutureTask<>(c); SwingUtilities.invokeLater(f); try { return f.get(timeout, unit); } catch (Throwable t) { f.cancel(true); //Forward app cancellation signal to active EDT task. throw t; } } public static void main(String[] args) { ExecutorService es = Executors.newSingleThreadExecutor(); try { Future appTask = es.submit(new AppTask()); try { appTask.get(10, TimeUnit.SECONDS); } catch (InterruptedException userCancel) { appTask.cancel(true); //Cancel the app task System.out.println("Swing action called appTask.cancel(true)"); Thread.currentThread().interrupt(); } catch (TimeoutException userNotResponsive) { appTask.cancel(true); //Cancel the app task System.out.println("Problem between chair and keyboard"); } catch (ExecutionException ee) { appTask.cancel(true); //Cancel the app task System.out.println("Unexpected error."); } } finally { es.shutdown(); } } private static class AppTask implements Callable { AppTask() {} public Void call() throws Exception { Integer choice = invokeAndWait(new Dialog(), 60L, TimeUnit.SECONDS); if (JOptionPane.YES_OPTION == choice.intValue()) { System.out.println("Yes"); } else if (JOptionPane.NO_OPTION == choice.intValue()) { System.out.println("No"); } else { System.out.println("Abort"); } return null; } } private static class Dialog implements Callable { Dialog() {} @Override public Integer call() throws Exception { assert SwingUtilities.isEventDispatchThread() : Thread.currentThread(); return JOptionPane.showConfirmDialog((Component) null, "Stay or go?", DialogTest.class.getName(), JOptionPane.YES_NO_OPTION, JOptionPane.ERROR_MESSAGE); } } } ==== In this test case. Simply start the program and wait. When the EDT is interrupted via f.cancel(true) the JOptionPane is closed. This is a nice feature to have. Comment out the 'f.cancel(true)' and the dialog will stay open yet there is no app thread interested in the user response. Yuck. What is not in the test case is that the same interrupt propagation can occur if we say hook a JTable row selection or a button to perform 'appTask' cancelation. That cancellation is much less predictable than a timeout. Users can just start button mashing. I can code this up if needed. What can happen is that the EDT interrupted is just before we are going to show the dialog and the ImageIcon used to display the 'error shield' swallows the interrupt and the dialog stays open. Bottom line is that the long standing behavior is really that interrupts close the JOptionPane in the majority of cases except when the ImageIcon swallows the interrupt. To me it would be more consistent if the ImageIcon just followed the general rule for interrupt handling which means the JOptionPane static methods would support cancellation consistently. Jason ________________________________________ From: Phil Race Sent: Monday, March 9, 2020 1:48 PM To: Jason Mehrens; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: Remove System.out.println from ImageIcon.loadImage I am not arguing the general case. I am addressing this case where we have long standing behaviour. And I can't find anywhere JOptionPane or similar is calling interrupt(). -phil On 3/9/20 11:33 AM, Jason Mehrens wrote: > Phil, > > Point 6, "The worst thing you can do with InterruptedException is swallow it -- catch it and neither rethrow it nor reassert the thread's interrupted status." -Brian Goetz > https://www.ibm.com/developerworks/library/j-jtp05236/index.html > > The swallowing of interrupts interferes with implementing cooperative cancelable tasks. For modal dialogs like the JOptionPane, interrupting the EDT from the application thread can be used to cancel modal blocking. The JOptionPane for INFO, ERROR, WARNING icons shown are provided by the ImageIcon class which means the ImageIcon can if the timing is just right swallow the interrupt that is important for the JOptionPane to see as a signal not wait. > > Jason > > > ________________________________________ > From: Philip Race > Sent: Sunday, March 8, 2020 5:56 PM > To: Volodin, Vladislav > Cc: Jason Mehrens; swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > 1) That bug is still closed. Did you want it re-opened ? I've just done so. > BTW I don't know why, but it was closed less than 3 months ago > by an engineer from the hotspot team (!?) I have NO idea why > since there is no comment. > > 2) If you are starting a review thread for a bug, the email subject line > should have the bug id and its synopsis thus : > RFR: 6421373: ImageIcon does not reassert interrupt status. > Although depending on what we end up doing the synopsis may > need to change (see 6 + 7 below). > > 3) The test has very long lines. Please curtail them to 80 chars. > > 4) What Christoph said. > > 5) I know where it was coming from, but I wish the docs said > "Returns when the image is loaded, or loading has failed. > Call getImageLoadStatus()" to check this." > Also a whole bunch of other questions arise like what > should happen if you call setImage() twice for different images. > If the first image succeeded, but the second failed, then what ? > > 6) I am not completely sold on reasserting the interrupted status > since it is a change of behaviour and you will need an approved CSR > to push this. Not sure if you need to update the javadoc as well ... > > 7) Now .. if all you really wanted was to get rid of the print statement > this is a lot of effort with some compatibility impact. > > -phil. > > > > On 2/22/20, 2:38 AM, Volodin, Vladislav wrote: > Hello Jason and everyone else, > > here is my webrev that my colleague published http://cr.openjdk.java.net/~clanger/webrevs/6421373.0/ > Can you please review it and let me know if I should change anything? Currently I am OOO, but I will do the changes in March. > > Kind regards, > Vlad > > Get Outlook for iOS > ________________________________ > From: Jason Mehrens > Sent: Tuesday, February 11, 2020 9:13:41 PM > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > Vlad, > > Yea that looks good. > > Jason > > ________________________________________ > From: Volodin, Vladislav > Sent: Wednesday, February 5, 2020 9:59 AM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: RE: Remove System.out.println from ImageIcon.loadImage > > Hi Jason, > > thank you for your advice. I have changed my code, now it simulates the behavior of the interrupted thread. Can you please check my patch? > I don't have the "bug" ticket, so in my test case "@bug JDK-123456" should be adjusted. > > I will appreciate if you and somebody else can review my patch and submit it to JDK. > > Thanks, > Vlad > > -----Original Message----- > From: Jason Mehrens > Sent: Mittwoch, 29. Januar 2020 17:55 > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > 1. Agreed. > 2. I was just pulling from the jdk8 source (because I'm lazy) to express the idea. Feel free to adjust. > 3. Reasserting in the finally ensure we are not forcefully setting the interrupted status on the current thread and calling 'statusID' and 'removeImage'. It also ensures that the interrupt is set even if an unexpected exception is thrown. Reasserting at the end of 'e1' and never in 'e2' should work too. > > The main issue that I'm trying to convey to you is that your test is incomplete in that it does check that the interrupt was swallowed. Swallowing interrupts is bad practice. Reasserting in e2 only means that we swallow interrupts from e1. > > Change your test to this and retest: > === > public static void main(String[] args) throws Exception { > Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); > > Thread.currentThread().interrupt(); > ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); > if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { > throw new RuntimeException("Couldn't load GIF from bytes after interruption"); > } > > if (!Thread.currentThread().isInterrupted()) { > throw new RuntimeException("Interrupt was swallowed"); > } > } > } > === > ________________________________________ > From: Volodin, Vladislav > Sent: Wednesday, January 29, 2020 9:52 AM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: RE: Remove System.out.println from ImageIcon.loadImage > > Hi Jason, > > I have few questions: > > 1. The second assignment is probably redundant: > > } catch (InterruptedException e1) { > wasInterrupted = true; // line #2, see comment below > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > wasInterrupted = true; // <-- this is redundant, because of the line #2 > } > } finally { > > 2. I think the first call of "addImage" is not necessary: > > boolean wasInterrupted = false; > mTracker.addImage(image, id); // maybe I should remove this, because of another comment down below. > try { > loadStatus = 0; > mTracker.addImage(image, id); // because of that > > May I also ask you a question? > What is the purpose of interrupting the current thread in the finally block, instead of doing it in the second catch block (where e2 is created)? I assume that since we were able to handle the exception properly, and plus the entire block is in the synchronization area, in theory we have only one importer at the time. > > Kind regards, > Vlad > > -----Original Message----- > From: Jason Mehrens > Sent: Mittwoch, 29. Januar 2020 16:35 > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > Bug in that last version: > Thread.currentThread().isInterrupted(); -> Thread.currentThread().interrupt(); > === > protected void loadImage(Image image) { > MediaTracker mTracker = getTracker(); > synchronized (mTracker) { > int id = getNextID(); > > boolean wasInterrupted = false; > mTracker.addImage(image, id); > try { > loadStatus = 0; > mTracker.addImage(image, id); > mTracker.waitForID(id, 0); > } catch (InterruptedException e1) { > wasInterrupted = true; > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > wasInterrupted = true; > } > } finally { > if (loadStatus == 0) { > loadStatus = mTracker.statusID(id, false); > } > mTracker.removeImage(image, id); > if (wasInterrupted) { > Thread.currentThread().interrupt(); > } > } > } > } > === > > ________________________________________ > From: swing-dev on behalf of Jason Mehrens > Sent: Wednesday, January 29, 2020 9:33 AM > To: Volodin, Vladislav > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > A shorter version is just to reassert at the end of catch e1. It is safer to just reassert as the last statement in the finally. > > === > protected void loadImage(Image image) { > MediaTracker mTracker = getTracker(); > synchronized (mTracker) { > int id = getNextID(); > > boolean wasInterrupted = false; > mTracker.addImage(image, id); > try { > loadStatus = 0; > mTracker.addImage(image, id); > mTracker.waitForID(id, 0); > } catch (InterruptedException e1) { > wasInterrupted = true; > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > } > } finally { > if (loadStatus == 0) { > loadStatus = mTracker.statusID(id, false); > } > mTracker.removeImage(image, id); > if (wasInterrupted) { > Thread.currentThread().isInterrupted(); > } > } > } > } > === > > Jason > ________________________________________ > From: Volodin, Vladislav > Sent: Tuesday, January 28, 2020 4:02 PM > To: Jason Mehrens > Cc: swing-dev at openjdk.java.net > Subject: Re: Remove System.out.println from ImageIcon.loadImage > > This is a valid point, because I wasn?t sure that when the thread is interrupted, I handled the first exception, and my thought was that all other ?wait? calls (maybe in other threads) should get the same exception as well. > > And since I handled this exceptional case, I am restoring the interrupted status in case if I don?t know how to handle this exception the second time. > > } catch (InterruptedException e1) { > try { > mTracker.waitForID(id, 0); > } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > Thread.currentThread().interrupt(); > } > > If I restore the interrupted status BEFORE waitForID call, then this thread will immoderately fail. Should I restore it AFTER, e.g. > > } catch (InterruptedException e1) { > try { > mTracker.waitForID(id, 0); > Thread.currentThread().interrupt(); // } catch (InterruptedException e2) { > loadStatus = MediaTracker.ABORTED; > Thread.currentThread().interrupt(); > } > > Thanks, > Vlad > > Sent from myPad > >> On 28. Jan 2020, at 22:27, Jason Mehrens wrote: >> >> ?I see. Well I would have to do some more digging and testing to make myself more knowledgeable on MediaTracker. >> >> Then the only bug in your current code is that you are not reasserting interrupted status of the current thread in the case e1 is raised and e2 is not. It is usually best to reassert the interrupted state at the end of the method. >> >> Jason >> >> ________________________________________ >> From: Volodin, Vladislav >> Sent: Tuesday, January 28, 2020 2:54 PM >> To: Jason Mehrens >> Cc: swing-dev at openjdk.java.net >> Subject: Re: Remove System.out.println from ImageIcon.loadImage >> >> Hi Jason, >> >> I am not sure about the loop, because I don?t know if we can trust results from mTracker.statusID at the moment when an exceptional case occurs. For example, I was experimenting with the code and found out that the MediaTracker can spawn a thread to load the image, or might use the current thread, and the ABORTED state is never returned (I don?t even know how to raise this state). That is why I don?t even know if your loop will ever stop. >> >> In my solution, I give the second chance only, and in case if the execution was interrupted the second time, I explicitly assign the ABORTED state to loadStatus. If the user wants to load this image once again, he can create ImageIcon again (or even do this in a loop), or reinitialize it with a single method (I don?t remember its name). >> >> What do you think? >> >> Kind regards, >> Vlad >> >> Sent from myPad >> >>> On 28. Jan 2020, at 21:34, Jason Mehrens wrote: >>> >>> ?Vlad, >>> >>> I assume you would want to wait in a loop and reassert the interrupt at the end. >>> >>> === >>> protected void loadImage(Image image) { >>> MediaTracker mTracker = getTracker(); >>> synchronized(mTracker) { >>> int id = getNextID(); >>> >>> mTracker.addImage(image, id); >>> boolean wasInterrupted = false; >>> try { >>> do { >>> try { >>> mTracker.waitForID(id, 0); >>> } catch (InterruptedException e) { >>> wasInterrupted = true; >>> } >>> loadStatus = mTracker.statusID(id, false); >>> } while (loadStatus == MediaTracker.LOADING); >>> mTracker.removeImage(image, id); >>> >>> width = image.getWidth(imageObserver); >>> height = image.getHeight(imageObserver); >>> } finally { >>> if (wasInterrupted) { >>> Thread.currentThread().interrupt(); >>> } >>> } >>> } >>> } >>> === >>> >>> Jason >>> ________________________________________ >>> From: swing-dev on behalf of Volodin, Vladislav >>> Sent: Monday, January 27, 2020 11:11 AM >>> To: Sergey Bylokhov >>> Cc: swing-dev at openjdk.java.net >>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>> >>> Hello Sergey, and others, >>> >>> here is the patch (made with "git diff") in the attachment. I have read that sometimes the attachments are lost. So here is my version with few comments regarding my code. I decided to use your approach with a small improvement. There is an excerpt of my patch. >>> >>> The idea is pretty simple: >>> 1. I create an empty gif 1x1; >>> 2. Initialize DefaultToolkit (I plan to interrupt the main thread, and if I do not initialize the toolkit in advance, my test will fail at the beginning >>> 3. Interrupt the main thread >>> 4. Try to load the icon: >>> >>> import javax.swing.*; >>> import java.awt.*; >>> >>> public class imageIconInterrupted { >>> static byte[] EMPTY_GIF = new byte[]{ >>> (byte) 0x47, (byte) 0x49, (byte) 0x46, (byte) 0x38, (byte) 0x39, (byte) 0x61, (byte) 0x01, (byte) 0x00, >>> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x21, (byte) 0xF9, (byte) 0x04, >>> (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x2C, (byte) 0x00, (byte) 0x00, >>> (byte) 0x00, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x02 >>> }; >>> >>> public static void main(String[] args) throws Exception { >>> Toolkit ignoreToolkit = Toolkit.getDefaultToolkit(); >>> >>> Thread.currentThread().interrupt(); >>> ImageIcon iconInterrupt = new ImageIcon(EMPTY_GIF); >>> if (iconInterrupt.getImageLoadStatus() != MediaTracker.COMPLETE) { >>> throw new RuntimeException("Couldn't load GIF from bytes after interruption"); >>> } >>> } >>> } >>> >>> The code of loadImage I have changed as follows: >>> 1. I clear loadStatus for "finally" part; >>> 2. Check the interruption according to your comments; >>> 3. Change the status to ABORTED, if the interruption happened again (this part I cannot test, because I cannot properly interrupt the thread whenever I want. Multithreading is quite fragile there :( ) >>> 4. update the status "interrupted" again; >>> 5. and then - finally block. >>> >>> protected void loadImage(Image image) { >>> ... >>> try { >>> loadStatus = 0; >>> mTracker.addImage(image, id); >>> mTracker.waitForID(id, 0); >>> } catch (InterruptedException e1) { >>> try { >>> mTracker.waitForID(id, 0); >>> } catch (InterruptedException e2) { >>> loadStatus = MediaTracker.ABORTED; >>> Thread.currentThread().interrupt(); >>> } >>> } finally { >>> if (loadStatus == 0) { >>> loadStatus = mTracker.statusID(id, false); >>> } >>> mTracker.removeImage(image, id); >>> } >>> >>> P.S. if you think that my patch sounds fine, I will find a sponsor for the bug report and the patch preparation, so you can review it later. >>> After the second attempt, my EMPTY_GIF was loaded successfully. The ABORTED part it seems that I don't know if it has ever worked. My patch (in the attachment) checks also the state ERROR for the URL that doesn't exist. Something like: >>> >>> ImageIcon iconNotExist = new ImageIcon(new URL("http://doesnt.exist.anywhere/1.gif")); // I am not sure if I spelled this URL grammatically correct >>> if (iconNotExist.getImageLoadStatus() != MediaTracker.ERRORED) { >>> throw new RuntimeException("Got unexpected status from non-existing GIF"); >>> } >>> >>> Thanks to everyone. >>> >>> Kind regards, >>> Vlad >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Dienstag, 21. Januar 2020 22:26 >>> To: Volodin, Vladislav >>> Cc: Jason Mehrens ; swing-dev at openjdk.java.net >>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>> >>>>> On 1/21/20 1:14 pm, Volodin, Vladislav wrote: >>>> Hi all, >>>> >>>> If I am not mistaken, this method is called from the constructor and other methods. How long should we try loading the icon using the unmanaged (by any thread pool, but I am not sure about this statement) thread? >>>> >>>> We don?t even have the flag ?interrupted?. So technically this icon has to be loaded. >>> I think it is necessary to save the "interrupted" state in the catch >>> block and try to call waitForID() again. It will be necessary to set >>> "interrupted" flag for the Thread after that(when the waitForID will >>> return without exception). >>> >>> >>>> Sent from myFone >>>> >>>>>> On 21. Jan 2020, at 21:55, Sergey Bylokhov wrote: >>>>> ?On 1/21/20 12:26 pm, Jason Mehrens wrote: >>>>>> +1 for Sergey suggestion. >>>>> Or probably we need to try to load the image again because of the spec of the method state this: >>>>> "Loads the image, returning only when the image is loaded." >>>>> >>>>>> ________________________________________ >>>>>> From: Sergey Bylokhov >>>>>> Sent: Sunday, January 19, 2020 9:31 PM >>>>>> To: Volodin, Vladislav; Jason Mehrens >>>>>> Cc: swing-dev at openjdk.java.net >>>>>> Subject: Re: Remove System.out.println from ImageIcon.loadImage >>>>>> I guess there are no objections, probably the best way to fix >>>>>> it is to drop the System.out.println and set interrupted flag. >>>>>> On 1/16/20 7:05 am, Volodin, Vladislav wrote: >>>>>>> If people in this distribution list agree, I can start working on a simple fix and either remove the logging (System.out.println), or replace it with PlatformLogger. I guess the second solution sounds better, but I don't know what is the better way to write a test-case for it. >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> -- >>> Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Mar 10 23:57:48 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Mar 2020 16:57:48 -0700 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> Message-ID: <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> On 3/10/20 1:04 am, Tejpal Rebari wrote: > I am not getting how to cover this in the test. I that additional call is necessary, then it should be possible to trigger it by the test. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 11 00:03:19 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Mar 2020 17:03:19 -0700 Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> References: <92ca9fe1-6bbc-47c6-bc62-3f78ae7c7194@oracle.com> <4db1f723-0f5a-4d66-8db6-529897885d79@default> <4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default> <75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> Message-ID: <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com> On 3/10/20 5:34 am, Pankaj Bansal wrote: > Hello Sergey/Vlad/Alexey, > > Sorry, I could not reply to this earlier. I have one doubt about this approach. Won't the calculation of stepCount itself suffer from floating point issue? I mean the user will pass min, max, stepsize, then wont the calculation of steps required to go from min to max will also suffer from same floating point issue? I think there can be an rounding of error of -1 or +1 in calculation of step count. It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 > > eg. > > int steps =0; > > for (double i=min+stepsize; i<=max; i+=stepsize) > steps++; > > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. > > > The reason is that, there is floating point error in first case, but it is not present in second case. > > I think the best we can do here is as Sergey suggested in his first reply to use Math.fma to reduce the floating point error chances from 2 to 1 or just close this as not an issue > > Regards, > > Pankaj > > > On 19/02/20 3:49 AM, Sergey Bylokhov wrote: >> I think it should work, the step will counts from the default value. >> >> So currently: >> 1. if the user set default value to X1 and then he iterates forward 100 times then he will get some X2. During this calculation, he could get "100" rounding issues. >> 2. If later the user decides iterates backward then most probably he will not get X1, and the amount of possible "rounding issues" will be 200. >> >> If the user will repeat steps 1. and 2. then each time the values will "float". >> >> If we will use counter then in the worst case we will get only two roundings per step: X1+step*100 = X2(if we will use fma we will get only one for every step). >> >> It will not solve all issues but at least will make the iteration "stable". >> >> On 2/17/20 1:59 am, Alexey Ivanov wrote: >>> Hi Vlad, >>> >>> The idea looks reasonable. However, it does not allow for manual editing. The cases where max and min values are not multiples of step would be hard to handle with this approach. For example: max = 10.05, min = 0.01, step = 0.1; how many ticks are there? What if the user enters 1.01015; the value should change to 1.11015 or 0.91015. >>> >>> On 13/02/2020 22:22, Volodin, Vladislav wrote: >>>> Hello Sergey, Alexey and Pankaj, >>>> >>>> I am reading the current discussion and I was thinking about an idea changing the code in the way that instead of working with float/double numbers we work with integer ticks. For example, the model remembers the min/max/step values and calculates a number of steps required to reach from min to max. All increment/decrement actions are done against the current ?tick? value. If the current ?tick? reaches 0 - we return min; if maxTick ? we return max. And the current value can be always counted as (min + tick * step) if tick is neither zero, nor max tick count. >>>> >>>> At least if we deal with integer ticks, but all reading operations calculate on the fly, we will be able to control the representativeness of output. >>>> >>>> As always, I don?t know all the details and possible consequences, so feel free to ignore my email, if I am wrong. >>>> >>>> Kind regards, >>>> Vlad >>>> >>>> Sent from myPad >>>> >>>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov wrote: >>>>> >>>>> ?On 2/12/20 8:21 am, Alexey Ivanov wrote: >>>>>> The bug report says that going from -0.15 to -0.10 does not allow going back to -0.15. This happens because the result of this sequence of operations cannot be represented exactly, or, in other words, because of rounding errors; or rather the result is less than the set minimal value. >>>>>> Can we set the value of the spinner to the set minimal value instead of disallowing the operation. I mean, after going up the displayed value is -0.10; going down by 0.05 gives the result which is less than the minimal value for the spinner, and thus going down is not allowed. What if we set the value of the spinner to its minimal value instead? >>>>> In this case, we will need to update all types including int. Isn't it will be surprised that the spinner will show the value which is not calculated as >>>>> "defaultValue + stepValue * stepCount"? >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 11 00:09:38 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Mar 2020 17:09:38 -0700 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: References: Message-ID: I am not sure that the test will properly cover the fix. I mean the test should cover the Windows L&F and maybe other L&F, but when I have run the test on macOS, I simply could not find the "the \"Look in\" combobox's popup". On 3/4/20 2:43 am, Bhawesh Choudhary wrote: > Hi, > > Please review this fix, > JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 > Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ > > Issue: > In Windows LookAndFeel, When navigating Combobox's list of JFileChooser via keys, the contents of JFileChooser changes. > > Fix: > Set flag "JComboBox.isTableCellEditor" to True which prohibits JCombobox from sending selection change event when JCombobox's list selection change happens via keys. > > > Verification: > Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as well as BasicLookAndFeel with keys navigation. also added a test case to verify the same. > > Did not find any misbehavior with the fix. > > Regards > Bhawesh -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 11 00:12:59 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Mar 2020 17:12:59 -0700 Subject: [OpenJDK 2D-Dev] [15] Review Request: 8237746 Fixing compiler warnings in src/demo/share/jfc In-Reply-To: <047e9859-bd9a-2716-d54a-bcd73b572b27@oracle.com> References: <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com> <047e9859-bd9a-2716-d54a-bcd73b572b27@oracle.com> Message-ID: <19118a11-e420-4ec5-0364-f3bce325f293@oracle.com> I plan to push this change if there are no more comments about the webrev. On 3/2/20 10:31 am, Alexander Zuev wrote: > Looks much better. I would double the proposal of creating the separate issue for bringing formatting in different files to the same coding standard. Seeing different spacing on cycles and method invocations in different classes makes me cringe. But functionally it seems everything is fine. > > /Alex > > On 22-Feb-20 12:50, Sergey Bylokhov wrote: >> Thank you, an updated version is upload: >> http://cr.openjdk.java.net/~serb/8237746/webrev.01 >> >> On 2/17/20 11:55 am, Marc Hoffmann wrote: >>> Thanks Alexey for the detailed review! I attached a updated version. >>> >>> The examples have many cleanup opportunities. I wanted to focus on compiler warnings for now and keep the changeset minimal. >>> >>> >>>> *Font2DTest.java* >>>> 674???????? if ( selectedText == fp.USER_TEXT ) >>>> 675?????????? userTextDialog.setVisible(true); >>>> 676???????? else >>>> 677?????????? userTextDialog.setVisible(false); >>>> >>>> I'd put the braces around and indent the statements by 4 spaces. >>>> However, it's the style used throughout the file: if there's only one statement, there are no braces and the statement is indented by 2 spaces rather than 4. Probably, to keep the code consistent, it's better to leave it as is. >>>> >>>> 797???????????? else >>>> 798?????????????? fontInfoDialog.setVisible(false); >>> >>> Maybe separate issue for formatting? >>> >>>> >>>> *FontPanel.java* >>>> 1248??????????? if (valArray == null) { >>>> 1249??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>> 1250??????????? } >>>> 1259??????????? if (valArray == null) { >>>> 1260??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>> 1261??????????? } >>>> Can it be replaced with FMValues.values() as you did in Font2DTest.java lines 153, 156? >>>> >>>> And below >>>> 1311??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>>> 1324??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>> >>> Done. >>> >>>> >>>> *ButtonDemo.java* >>>> 64???? Vector buttons = new Vector<>(); >>>> Shall it be JComponent? >>> >>> Doesn?t because JPanel.add() returns Component: >>> >>> ???? buttons.add(p2.add(new JButton(getString("ButtonDemo.button1")))); >>> >>> Should I introduce a local variable? >>> >>>> >>>> >>>> *ComboBoxDemo.java* >>>> 60???? JComboBox hairCB; >>>> Why not JComboBox ? >>>> All createXXX methods use this type. >>>> Then the cast below would be unnecessary: >>>> 282???????????? String name = (String) parts.get(hairCB.getSelectedItem()); >>> >>> This comes from the lookup in the parts Hashtable. Unfortunately it has String an ImageIcon values. >>> >>>> >>>> >>>> 114???????? presetCB = (JComboBox) comboBoxPanel.add(createPresetComboBox()); >>>> To avoid cast, you can use two statements: >>>> presetCB = createPresetComboBox(); >>>> comboBoxPanel.add(presetCB); >>> >>> Done for all 4 occurrences. >>> >>>> >>>> >>>> *DirectionPanel.java* >>>> 97???????????????? AbstractButton b = e.nextElement(); >>>> 98???????????? if( b.getActionCommand().equals(selection) ) { >>>> Indentation on line 97 seems incorrect, it should align to line 98, shouldn't it? >>> >>> Done (replace tab with spaces). >>> >>>> >>>> >>>> *SliderDemo.java* >>>> 167???????? @SuppressWarnings("unchecked") >>>> 168???????????????? Dictionary labelTable = s.getLabelTable(); >>>> Would using Dictionary suppress the warning automatically? >>>> I mean that @SuppressWarning would become unnecessary. >>> >>> Dictionary does not allow put of specific types in the next line. But fixed tabs in the same line. >>> >>>> >>>> >>>> *SplitPaneDemo.java* >>>> 168 divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); >>>> can be simplified to >>>> divSize.setText(Integer.toString(splitPane.getDividerSize())); >>>> by using static method Integer.toString() method. >>> >>> Done. >>> >>>> >>>> >>>> Shall the copyright year be updated in all the modified files? >>> >>> Please let me know what would be the correct process. >>> >>> Cheers, >>> -marc >>> >>> >>> >>> >>>> On 17. Feb 2020, at 15:40, Alexey Ivanov wrote: >>>> >>>> Thank you, Marc, for your contribution. >>>> And thank you to Sergey for creating the review. >>>> >>>> *Font2DTest.java* >>>> 674???????? if ( selectedText == fp.USER_TEXT ) >>>> 675?????????? userTextDialog.setVisible(true); >>>> 676???????? else >>>> 677?????????? userTextDialog.setVisible(false); >>>> >>>> I'd put the braces around and indent the statements by 4 spaces. >>>> However, it's the style used throughout the file: if there's only one statement, there are no braces and the statement is indented by 2 spaces rather than 4. Probably, to keep the code consistent, it's better to leave it as is. >>>> >>>> 797???????????? else >>>> 798?????????????? fontInfoDialog.setVisible(false); >>>> >>>> >>>> *FontPanel.java* >>>> 1248??????????? if (valArray == null) { >>>> 1249??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>> 1250??????????? } >>>> 1259??????????? if (valArray == null) { >>>> 1260??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>> 1261??????????? } >>>> Can it be replaced with FMValues.values() as you did in Font2DTest.java lines 153, 156? >>>> >>>> And below >>>> 1311??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>>> 1324??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>>> >>>> >>>> *ButtonDemo.java* >>>> 64???? Vector buttons = new Vector<>(); >>>> Shall it be JComponent? >>>> >>>> >>>> *ComboBoxDemo.java* >>>> 60???? JComboBox hairCB; >>>> Why not JComboBox ? >>>> All createXXX methods use this type. >>>> Then the cast below would be unnecessary: >>>> 282???????????? String name = (String) parts.get(hairCB.getSelectedItem()); >>>> >>>> >>>> 114???????? presetCB = (JComboBox) comboBoxPanel.add(createPresetComboBox()); >>>> To avoid cast, you can use two statements: >>>> presetCB = createPresetComboBox(); >>>> comboBoxPanel.add(presetCB); >>>> >>>> >>>> *DirectionPanel.java* >>>> 97???????????????? AbstractButton b = e.nextElement(); >>>> 98???????????? if( b.getActionCommand().equals(selection) ) { >>>> Indentation on line 97 seems incorrect, it should align to line 98, shouldn't it? >>>> >>>> >>>> *SliderDemo.java* >>>> 167???????? @SuppressWarnings("unchecked") >>>> 168???????????????? Dictionary labelTable = s.getLabelTable(); >>>> Would using Dictionary suppress the warning automatically? >>>> I mean that @SuppressWarning would become unnecessary. >>>> >>>> >>>> *SplitPaneDemo.java* >>>> 168 divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); >>>> can be simplified to >>>> divSize.setText(Integer.toString(splitPane.getDividerSize())); >>>> by using static method Integer.toString() method. >>>> >>>> >>>> Shall the copyright year be updated in all the modified files? >>>> >>>> >>>> On 23/01/2020 08:54, Marc Hoffmann wrote: >>>>> Hi Sergey, >>>>> >>>>> thanks for sponsoring this patch! >>>>> >>>>> I successfully applied the webrev patch on current JDK head (57807:7bae17e00566). The build runs without warnings on the demo code :) >>>>> >>>>> But I noticed a minor glitch: I inserted a tab in src/demo/share/jfc/SwingSet2/DirectionPanel.java Line 97 where only spaces are used in the rest of the file. Probably this should be fixed before merge. >>>>> >>>>> Regards, >>>>> -marc >>>>> >>>>> >>>>>> On 23. Jan 2020, at 01:35, Sergey Bylokhov wrote: >>>>>> >>>>>> Hello. >>>>>> Please review the fix for compiler warnings in the demo/jfc in JDK 15. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237746 >>>>>> Fix: http://cr.openjdk.java.net/~serb/8237746/webrev.00 >>>>>> >>>>>> This fix contributed by the Marc Hoffmann: >>>>>> https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html >>>>>> >>>>>> Fixed warnings: raw types, deprecated APIs, deprecated Applet APIs. >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>> -- >>>> Regards, >>>> Alexey >>> >>> >>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 11 00:40:43 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Mar 2020 17:40:43 -0700 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> References: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> Message-ID: <14446066-7f88-b68f-c7a6-e602a94b9a18@oracle.com> On 3/10/20 12:01 am, Prasanta Sadhukhan wrote: > Hi Sergey, > > There are some ActionListeners that we add, namely for fileNameTextField, directoryComboBox, filterComboBox, approveButton, cancelButton. Shouldn't we remove those as has been done in Metal/Windows L&F uninstallUI? These components are parts of the AquaFileChooserUI(they are L&F specific) and they as well as the listeners should be dropped when the application switches the L&F, unlike listeners in the JFileChooser which are preserved across different L&F. > > I see uninstallUI does not do removeActionListener, or else proabably we could just add fileNameTextField.uninstallUI() along with the fix? > > Regards > Prasanta > On 08-Mar-20 3:50 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk/client. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8240633 >> Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00 >> >> Our tests in mach5 for JFileChooser sometime fails with different >> suspicious exceptions. The root cause is that the Aqua UI delegates >> add various listeners to the JFileChooser, and never delete them. >> So these Aqua related listeners may fail if current L&F was changed. >> >> In the fix we will "uninstall" all child components for the AquaFileChooserUI. >> >> Also in the AquaFileChooserUI we had added model as a PropertyChangeListener twice, >> and never removed the filterComboBoxModel. >> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Mar 11 05:23:52 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 11 Mar 2020 10:53:52 +0530 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: <14446066-7f88-b68f-c7a6-e602a94b9a18@oracle.com> References: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> <14446066-7f88-b68f-c7a6-e602a94b9a18@oracle.com> Message-ID: On 11-Mar-20 6:10 AM, Sergey Bylokhov wrote: > On 3/10/20 12:01 am, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> There are some ActionListeners that we add, namely for >> fileNameTextField, directoryComboBox, filterComboBox, approveButton, >> cancelButton. Shouldn't we remove those as has been done in >> Metal/Windows L&F uninstallUI? > > These components are parts of the AquaFileChooserUI(they are L&F > specific) > and they as well as the listeners should be dropped when the application > switches the L&F, unlike listeners in the JFileChooser which are > preserved > across different L&F. > Yes, it was part of MetalFileChooseUI and WindowsFileChooserUI too but it was removed explicitly in uninstallUI. >> >> I see uninstallUI does not do removeActionListener, or else proabably >> we could just add fileNameTextField.uninstallUI() along with the fix? >> >> Regards >> Prasanta >> On 08-Mar-20 3:50 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk/client. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240633 >>> Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00 >>> >>> Our tests in mach5 for JFileChooser sometime fails with different >>> suspicious exceptions. The root cause is that the Aqua UI delegates >>> add various listeners to the JFileChooser, and never delete them. >>> So these Aqua related listeners may fail if current L&F was changed. >>> >>> In the fix we will "uninstall" all child components for the >>> AquaFileChooserUI. >>> >>> Also in the AquaFileChooserUI we had added model as a >>> PropertyChangeListener twice, >>> and never removed the filterComboBoxModel. >>> > > From Sergey.Bylokhov at oracle.com Wed Mar 11 05:54:10 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Mar 2020 22:54:10 -0700 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: References: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> <14446066-7f88-b68f-c7a6-e602a94b9a18@oracle.com> Message-ID: <7a4ccce8-4cdf-24de-c70e-660fec3a62d7@oracle.com> On 3/10/20 10:23 pm, Prasanta Sadhukhan wrote: >> > Yes, it was part of MetalFileChooseUI and WindowsFileChooserUI too but it was removed explicitly in uninstallUI. The MetalFileChooseUI and WindowsFileChooserUI use non-local(we could say public) listeners for example BasicFileChooserUI.getCancelSelectionAction(): These listeners could be accessed by the application since is a BasicFileChooserUI is in the "javax.swing.plaf.basic" package. So we should not use these listeners after the L&F switch. The Aqua uses only its own listeners, so they die at the same time as the FileChooseUI itself. >>> >>> I see uninstallUI does not do removeActionListener, or else proabably we could just add fileNameTextField.uninstallUI() along with the fix? >>> >>> Regards >>> Prasanta >>> On 08-Mar-20 3:50 AM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk/client. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240633 >>>> Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00 >>>> >>>> Our tests in mach5 for JFileChooser sometime fails with different >>>> suspicious exceptions. The root cause is that the Aqua UI delegates >>>> add various listeners to the JFileChooser, and never delete them. >>>> So these Aqua related listeners may fail if current L&F was changed. >>>> >>>> In the fix we will "uninstall" all child components for the AquaFileChooserUI. >>>> >>>> Also in the AquaFileChooserUI we had added model as a PropertyChangeListener twice, >>>> and never removed the filterComboBoxModel. >>>> >> >> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Mar 11 06:00:00 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 11 Mar 2020 11:30:00 +0530 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: <7a4ccce8-4cdf-24de-c70e-660fec3a62d7@oracle.com> References: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> <14446066-7f88-b68f-c7a6-e602a94b9a18@oracle.com> <7a4ccce8-4cdf-24de-c70e-660fec3a62d7@oracle.com> Message-ID: <46769c30-1fd4-297c-5e00-e63a786f35ef@oracle.com> On 11-Mar-20 11:24 AM, Sergey Bylokhov wrote: > On 3/10/20 10:23 pm, Prasanta Sadhukhan wrote: >>> >> Yes, it was part of MetalFileChooseUI and WindowsFileChooserUI too >> but it was removed explicitly in uninstallUI. > > The MetalFileChooseUI and WindowsFileChooserUI use non-local(we could > say public) listeners for example > BasicFileChooserUI.getCancelSelectionAction(): > > These listeners could be accessed by the application since is a > BasicFileChooserUI is in the "javax.swing.plaf.basic" package. > So we should not use these listeners after the L&F switch. The Aqua > uses only its own listeners, so they die at the same time as the > FileChooseUI itself. > > OK. What about fileNameTextField. Shouldn't we need to uninstallUI that too? >>>> >>>> I see uninstallUI does not do removeActionListener, or else >>>> proabably we could just add fileNameTextField.uninstallUI() along >>>> with the fix? >>>> >>>> Regards >>>> Prasanta >>>> On 08-Mar-20 3:50 AM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk/client. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240633 >>>>> Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00 >>>>> >>>>> Our tests in mach5 for JFileChooser sometime fails with different >>>>> suspicious exceptions. The root cause is that the Aqua UI delegates >>>>> add various listeners to the JFileChooser, and never delete them. >>>>> So these Aqua related listeners may fail if current L&F was changed. >>>>> >>>>> In the fix we will "uninstall" all child components for the >>>>> AquaFileChooserUI. >>>>> >>>>> Also in the AquaFileChooserUI we had added model as a >>>>> PropertyChangeListener twice, >>>>> and never removed the filterComboBoxModel. >>>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Wed Mar 11 06:11:00 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Mar 2020 23:11:00 -0700 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: <46769c30-1fd4-297c-5e00-e63a786f35ef@oracle.com> References: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> <14446066-7f88-b68f-c7a6-e602a94b9a18@oracle.com> <7a4ccce8-4cdf-24de-c70e-660fec3a62d7@oracle.com> <46769c30-1fd4-297c-5e00-e63a786f35ef@oracle.com> Message-ID: On 3/10/20 11:00 pm, Prasanta Sadhukhan wrote: > > On 11-Mar-20 11:24 AM, Sergey Bylokhov wrote: >> On 3/10/20 10:23 pm, Prasanta Sadhukhan wrote: >>>> >>> Yes, it was part of MetalFileChooseUI and WindowsFileChooserUI too but it was removed explicitly in uninstallUI. >> >> The MetalFileChooseUI and WindowsFileChooserUI use non-local(we could say public) listeners for example BasicFileChooserUI.getCancelSelectionAction(): >> >> These listeners could be accessed by the application since is a BasicFileChooserUI is in the "javax.swing.plaf.basic" package. >> So we should not use these listeners after the L&F switch. The Aqua uses only its own listeners, so they die at the same time as the FileChooseUI itself. >> >> > OK. What about fileNameTextField. Shouldn't we need to uninstallUI that too? It does not have a jbutton inside so it not necessary, the problem only exists for jbutton itself, or any compound components which use jbutton inside. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Mar 11 06:14:53 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 11 Mar 2020 11:44:53 +0530 Subject: RFR: 8240633 Memory leaks in the implementations of FileChooserUI In-Reply-To: References: <7d0fcc13-178c-535f-67a8-58c202581fa1@oracle.com> <14446066-7f88-b68f-c7a6-e602a94b9a18@oracle.com> <7a4ccce8-4cdf-24de-c70e-660fec3a62d7@oracle.com> <46769c30-1fd4-297c-5e00-e63a786f35ef@oracle.com> Message-ID: <226ec4ba-d3c7-f3f2-ac36-99c6db3156b9@oracle.com> On 11-Mar-20 11:41 AM, Sergey Bylokhov wrote: > On 3/10/20 11:00 pm, Prasanta Sadhukhan wrote: >> >> On 11-Mar-20 11:24 AM, Sergey Bylokhov wrote: >>> On 3/10/20 10:23 pm, Prasanta Sadhukhan wrote: >>>>> >>>> Yes, it was part of MetalFileChooseUI and WindowsFileChooserUI too >>>> but it was removed explicitly in uninstallUI. >>> >>> The MetalFileChooseUI and WindowsFileChooserUI use non-local(we >>> could say public) listeners for example >>> BasicFileChooserUI.getCancelSelectionAction(): >>> >>> These listeners could be accessed by the application since is a >>> BasicFileChooserUI is in the "javax.swing.plaf.basic" package. >>> So we should not use these listeners after the L&F switch. The Aqua >>> uses only its own listeners, so they die at the same time as the >>> FileChooseUI itself. >>> >>> >> OK. What about fileNameTextField. Shouldn't we need to uninstallUI >> that too? > > It does not have a jbutton inside so it not necessary, the problem > only exists for jbutton itself, or any compound components which use > jbutton inside. > > OK. Thanks for the clarification. Looks fine to me. Regards Prasanta > > From alexey.ivanov at oracle.com Wed Mar 11 19:28:33 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 11 Mar 2020 19:28:33 +0000 Subject: [OpenJDK 2D-Dev] [15] Review Request: 8237746 Fixing compiler warnings in src/demo/share/jfc In-Reply-To: <19118a11-e420-4ec5-0364-f3bce325f293@oracle.com> References: <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com> <047e9859-bd9a-2716-d54a-bcd73b572b27@oracle.com> <19118a11-e420-4ec5-0364-f3bce325f293@oracle.com> Message-ID: <6c70a474-783b-52fb-cc41-b94626302452@oracle.com> Hi Sergey, The updated webrev.01 looks good to me. Please go ahead and push the changes. I agree with Alexander, separate issues for formatting are better. Regards, Alexey On 11/03/2020 00:12, Sergey Bylokhov wrote: > I plan to push this change if there are no more comments about the > webrev. > > On 3/2/20 10:31 am, Alexander Zuev wrote: >> Looks much better. I would double the proposal of creating the >> separate issue for bringing formatting in different files to the same >> coding standard. Seeing different spacing on cycles and method >> invocations in different classes makes me cringe. But functionally it >> seems everything is fine. >> >> /Alex >> >> On 22-Feb-20 12:50, Sergey Bylokhov wrote: >>> Thank you, an updated version is upload: >>> http://cr.openjdk.java.net/~serb/8237746/webrev.01 >>> >>> On 2/17/20 11:55 am, Marc Hoffmann wrote: >>>> Thanks Alexey for the detailed review! I attached a updated version. >>>> >>>> The examples have many cleanup opportunities. I wanted to focus on >>>> compiler warnings for now and keep the changeset minimal. >>>> >>>> >>>>> *Font2DTest.java* >>>>> 674???????? if ( selectedText == fp.USER_TEXT ) >>>>> 675?????????? userTextDialog.setVisible(true); >>>>> 676???????? else >>>>> 677?????????? userTextDialog.setVisible(false); >>>>> >>>>> I'd put the braces around and indent the statements by 4 spaces. >>>>> However, it's the style used throughout the file: if there's only >>>>> one statement, there are no braces and the statement is indented >>>>> by 2 spaces rather than 4. Probably, to keep the code consistent, >>>>> it's better to leave it as is. >>>>> >>>>> 797???????????? else >>>>> 798?????????????? fontInfoDialog.setVisible(false); >>>> >>>> Maybe separate issue for formatting? >>>> >>>>> >>>>> *FontPanel.java* >>>>> 1248??????????? if (valArray == null) { >>>>> 1249??????????????? valArray = >>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>>> 1250??????????? } >>>>> 1259??????????? if (valArray == null) { >>>>> 1260??????????????? valArray = >>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>>> 1261??????????? } >>>>> Can it be replaced with FMValues.values() as you did in >>>>> Font2DTest.java lines 153, 156? >>>>> >>>>> And below >>>>> 1311??????????????? valArray = >>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>>>> 1324??????????????? valArray = >>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>>> >>>> Done. >>>> >>>>> >>>>> *ButtonDemo.java* >>>>> 64???? Vector buttons = new Vector<>(); >>>>> Shall it be JComponent? >>>> >>>> Doesn?t because JPanel.add() returns Component: >>>> >>>> ???? buttons.add(p2.add(new >>>> JButton(getString("ButtonDemo.button1")))); >>>> >>>> Should I introduce a local variable? >>>> >>>>> >>>>> >>>>> *ComboBoxDemo.java* >>>>> 60???? JComboBox hairCB; >>>>> Why not JComboBox ? >>>>> All createXXX methods use this type. >>>>> Then the cast below would be unnecessary: >>>>> 282???????????? String name = (String) >>>>> parts.get(hairCB.getSelectedItem()); >>>> >>>> This comes from the lookup in the parts Hashtable. Unfortunately it >>>> has String an ImageIcon values. >>>> >>>>> >>>>> >>>>> 114???????? presetCB = (JComboBox) >>>>> comboBoxPanel.add(createPresetComboBox()); >>>>> To avoid cast, you can use two statements: >>>>> presetCB = createPresetComboBox(); >>>>> comboBoxPanel.add(presetCB); >>>> >>>> Done for all 4 occurrences. >>>> >>>>> >>>>> >>>>> *DirectionPanel.java* >>>>> 97???????????????? AbstractButton b = e.nextElement(); >>>>> 98???????????? if( b.getActionCommand().equals(selection) ) { >>>>> Indentation on line 97 seems incorrect, it should align to line >>>>> 98, shouldn't it? >>>> >>>> Done (replace tab with spaces). >>>> >>>>> >>>>> >>>>> *SliderDemo.java* >>>>> 167???????? @SuppressWarnings("unchecked") >>>>> 168???????????????? Dictionary labelTable = >>>>> s.getLabelTable(); >>>>> Would using Dictionary suppress the warning automatically? >>>>> I mean that @SuppressWarning would become unnecessary. >>>> >>>> Dictionary does not allow put of specific types in the next >>>> line. But fixed tabs in the same line. >>>> >>>>> >>>>> >>>>> *SplitPaneDemo.java* >>>>> 168 >>>>> divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); >>>>> >>>>> can be simplified to >>>>> divSize.setText(Integer.toString(splitPane.getDividerSize())); >>>>> by using static method Integer.toString() method. >>>> >>>> Done. >>>> >>>>> >>>>> >>>>> Shall the copyright year be updated in all the modified files? >>>> >>>> Please let me know what would be the correct process. >>>> >>>> Cheers, >>>> -marc >>>> >>>> >>>> >>>> >>>>> On 17. Feb 2020, at 15:40, Alexey Ivanov >>>>> wrote: >>>>> >>>>> Thank you, Marc, for your contribution. >>>>> And thank you to Sergey for creating the review. >>>>> >>>>> *Font2DTest.java* >>>>> 674???????? if ( selectedText == fp.USER_TEXT ) >>>>> 675?????????? userTextDialog.setVisible(true); >>>>> 676???????? else >>>>> 677?????????? userTextDialog.setVisible(false); >>>>> >>>>> I'd put the braces around and indent the statements by 4 spaces. >>>>> However, it's the style used throughout the file: if there's only >>>>> one statement, there are no braces and the statement is indented >>>>> by 2 spaces rather than 4. Probably, to keep the code consistent, >>>>> it's better to leave it as is. >>>>> >>>>> 797???????????? else >>>>> 798?????????????? fontInfoDialog.setVisible(false); >>>>> >>>>> >>>>> *FontPanel.java* >>>>> 1248??????????? if (valArray == null) { >>>>> 1249??????????????? valArray = >>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>>> 1250??????????? } >>>>> 1259??????????? if (valArray == null) { >>>>> 1260??????????????? valArray = >>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]); >>>>> 1261??????????? } >>>>> Can it be replaced with FMValues.values() as you did in >>>>> Font2DTest.java lines 153, 156? >>>>> >>>>> And below >>>>> 1311??????????????? valArray = >>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>>>> 1324??????????????? valArray = >>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]); >>>>> >>>>> >>>>> *ButtonDemo.java* >>>>> 64???? Vector buttons = new Vector<>(); >>>>> Shall it be JComponent? >>>>> >>>>> >>>>> *ComboBoxDemo.java* >>>>> 60???? JComboBox hairCB; >>>>> Why not JComboBox ? >>>>> All createXXX methods use this type. >>>>> Then the cast below would be unnecessary: >>>>> 282???????????? String name = (String) >>>>> parts.get(hairCB.getSelectedItem()); >>>>> >>>>> >>>>> 114???????? presetCB = (JComboBox) >>>>> comboBoxPanel.add(createPresetComboBox()); >>>>> To avoid cast, you can use two statements: >>>>> presetCB = createPresetComboBox(); >>>>> comboBoxPanel.add(presetCB); >>>>> >>>>> >>>>> *DirectionPanel.java* >>>>> 97???????????????? AbstractButton b = e.nextElement(); >>>>> 98???????????? if( b.getActionCommand().equals(selection) ) { >>>>> Indentation on line 97 seems incorrect, it should align to line >>>>> 98, shouldn't it? >>>>> >>>>> >>>>> *SliderDemo.java* >>>>> 167???????? @SuppressWarnings("unchecked") >>>>> 168???????????????? Dictionary labelTable = >>>>> s.getLabelTable(); >>>>> Would using Dictionary suppress the warning automatically? >>>>> I mean that @SuppressWarning would become unnecessary. >>>>> >>>>> >>>>> *SplitPaneDemo.java* >>>>> 168 >>>>> divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); >>>>> >>>>> can be simplified to >>>>> divSize.setText(Integer.toString(splitPane.getDividerSize())); >>>>> by using static method Integer.toString() method. >>>>> >>>>> >>>>> Shall the copyright year be updated in all the modified files? >>>>> >>>>> >>>>> On 23/01/2020 08:54, Marc Hoffmann wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> thanks for sponsoring this patch! >>>>>> >>>>>> I successfully applied the webrev patch on current JDK head >>>>>> (57807:7bae17e00566). The build runs without warnings on the demo >>>>>> code :) >>>>>> >>>>>> But I noticed a minor glitch: I inserted a tab in >>>>>> src/demo/share/jfc/SwingSet2/DirectionPanel.java Line 97 where >>>>>> only spaces are used in the rest of the file. Probably this >>>>>> should be fixed before merge. >>>>>> >>>>>> Regards, >>>>>> -marc >>>>>> >>>>>> >>>>>>> On 23. Jan 2020, at 01:35, Sergey Bylokhov >>>>>>> wrote: >>>>>>> >>>>>>> Hello. >>>>>>> Please review the fix for compiler warnings in the demo/jfc in >>>>>>> JDK 15. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237746 >>>>>>> Fix: http://cr.openjdk.java.net/~serb/8237746/webrev.00 >>>>>>> >>>>>>> This fix contributed by the Marc Hoffmann: >>>>>>> https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html >>>>>>> >>>>>>> >>>>>>> Fixed warnings: raw types, deprecated APIs, deprecated Applet APIs. >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>> >>>>> -- >>>>> Regards, >>>>> Alexey >>>> >>>> >>>> >>>> >>> >>> >> > > From alexey.ivanov at oracle.com Wed Mar 11 20:07:58 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 11 Mar 2020 20:07:58 +0000 Subject: [15] Review Request: 8237746 Fixing compiler warnings in src/demo/share/jfc In-Reply-To: <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com> References: <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com> Message-ID: <8d627478-3af5-49cd-df43-c9caf5551be1@oracle.com> Thank you to Marc for updating webrev and to Sergey for uploading it. The changes look fine to me as I already stated. I just wanted to share more comments: On 22/02/2020 09:50, Sergey Bylokhov wrote: > Thank you, an updated version is upload: > http://cr.openjdk.java.net/~serb/8237746/webrev.01 > > On 2/17/20 11:55 am, Marc Hoffmann wrote: >> Thanks Alexey for the detailed review! I attached a updated version. >> >> The examples have many cleanup opportunities. I wanted to focus on >> compiler warnings for now and keep the changeset minimal. Yes, I agree. It's better to fix one problem at a time. >> >> >>> *ButtonDemo.java* >>> 64???? Vector buttons = new Vector<>(); >>> Shall it be JComponent? >> >> Doesn?t because JPanel.add() returns Component: >> >> ???? buttons.add(p2.add(new JButton(getString("ButtonDemo.button1")))); >> >> Should I introduce a local variable? It could be another opportunity to contribute and clean up. Vector can be replaced with ArrayList; and Component with AbstractButton, then the type casts and instanceof checks in listeners can be cleaned up too. >>> *ComboBoxDemo.java* >>> 60???? JComboBox hairCB; >>> Why not JComboBox ? >>> All createXXX methods use this type. >>> Then the cast below would be unnecessary: >>> 282???????????? String name = (String) >>> parts.get(hairCB.getSelectedItem()); >> >> This comes from the lookup in the parts Hashtable. Unfortunately it >> has String an ImageIcon values. Probably this could also be made cleaner then? Or maybe it's not worth it. >> >>> >>> >>> 114???????? presetCB = (JComboBox) >>> comboBoxPanel.add(createPresetComboBox()); >>> To avoid cast, you can use two statements: >>> presetCB = createPresetComboBox(); >>> comboBoxPanel.add(presetCB); >> >> Done for all 4 occurrences. >> >>> >>> >>> *DirectionPanel.java* >>> 97???????????????? AbstractButton b = e.nextElement(); >>> 98???????????? if( b.getActionCommand().equals(selection) ) { >>> Indentation on line 97 seems incorrect, it should align to line 98, >>> shouldn't it? >> >> Done (replace tab with spaces). >> >>> >>> >>> *SliderDemo.java* >>> 167???????? @SuppressWarnings("unchecked") >>> 168???????????????? Dictionary labelTable = >>> s.getLabelTable(); >>> Would using Dictionary suppress the warning automatically? >>> I mean that @SuppressWarning would become unnecessary. >> >> Dictionary does not allow put of specific types in the next >> line. But fixed tabs in the same line. I see, it comes from JSlider.get/setLabelTable which use the raw type Dictionary. So probably the API of JSlider itself can be updated to accept Dictionary. The generification of these two methods of JSlider was reverted to raw types under https://bugs.openjdk.java.net/browse/JDK-8055254 because SwingSet2 did not compile. So it should be a coordinated change to both the API and the demo. >>> -- Regards, Alexey From hoffmann at mountainminds.com Wed Mar 11 20:22:32 2020 From: hoffmann at mountainminds.com (Marc Hoffmann) Date: Wed, 11 Mar 2020 21:22:32 +0100 Subject: [15] Review Request: 8237746 Fixing compiler warnings in src/demo/share/jfc In-Reply-To: <8d627478-3af5-49cd-df43-c9caf5551be1@oracle.com> References: <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com> <8d627478-3af5-49cd-df43-c9caf5551be1@oracle.com> Message-ID: <20D3C5AC-C49C-4201-9326-F3EFB8AFB481@mountainminds.com> Hi Alexey, I?m happy to add more small fixes at a later point in time. Please understand that I?m not a Swing expert. But I could help to make the code look cleaner and more like modern Java. Also I think the example code is used in some regression tests, right? So I need to make sure not to break those. Is there documentation or any pointers how to run those tests? Regards, -marc > On 11. Mar 2020, at 21:07, Alexey Ivanov wrote: > > Thank you to Marc for updating webrev and to Sergey for uploading it. > > The changes look fine to me as I already stated. > > I just wanted to share more comments: > > On 22/02/2020 09:50, Sergey Bylokhov wrote: >> Thank you, an updated version is upload: >> http://cr.openjdk.java.net/~serb/8237746/webrev.01 >> >> On 2/17/20 11:55 am, Marc Hoffmann wrote: >>> Thanks Alexey for the detailed review! I attached a updated version. >>> >>> The examples have many cleanup opportunities. I wanted to focus on compiler warnings for now and keep the changeset minimal. > > Yes, I agree. It's better to fix one problem at a time. > >>> >>> >>>> *ButtonDemo.java* >>>> 64 Vector buttons = new Vector<>(); >>>> Shall it be JComponent? >>> >>> Doesn?t because JPanel.add() returns Component: >>> >>> buttons.add(p2.add(new JButton(getString("ButtonDemo.button1")))); >>> >>> Should I introduce a local variable? > > It could be another opportunity to contribute and clean up. > > Vector can be replaced with ArrayList; and Component with AbstractButton, then the type casts and instanceof checks in listeners can be cleaned up too. > >>>> *ComboBoxDemo.java* >>>> 60 JComboBox hairCB; >>>> Why not JComboBox ? >>>> All createXXX methods use this type. >>>> Then the cast below would be unnecessary: >>>> 282 String name = (String) parts.get(hairCB.getSelectedItem()); >>> >>> This comes from the lookup in the parts Hashtable. Unfortunately it has String an ImageIcon values. > > Probably this could also be made cleaner then? Or maybe it's not worth it. > >>> >>>> >>>> >>>> 114 presetCB = (JComboBox) comboBoxPanel.add(createPresetComboBox()); >>>> To avoid cast, you can use two statements: >>>> presetCB = createPresetComboBox(); >>>> comboBoxPanel.add(presetCB); >>> >>> Done for all 4 occurrences. >>> >>>> >>>> >>>> *DirectionPanel.java* >>>> 97 AbstractButton b = e.nextElement(); >>>> 98 if( b.getActionCommand().equals(selection) ) { >>>> Indentation on line 97 seems incorrect, it should align to line 98, shouldn't it? >>> >>> Done (replace tab with spaces). >>> >>>> >>>> >>>> *SliderDemo.java* >>>> 167 @SuppressWarnings("unchecked") >>>> 168 Dictionary labelTable = s.getLabelTable(); >>>> Would using Dictionary suppress the warning automatically? >>>> I mean that @SuppressWarning would become unnecessary. >>> >>> Dictionary does not allow put of specific types in the next line. But fixed tabs in the same line. > > I see, it comes from JSlider.get/setLabelTable which use the raw type Dictionary. > So probably the API of JSlider itself can be updated to accept Dictionary. > > The generification of these two methods of JSlider was reverted to raw types under https://bugs.openjdk.java.net/browse/JDK-8055254 because SwingSet2 did not compile. So it should be a coordinated change to both the API and the demo. > >>>> > -- > Regards, > Alexey From bhawesh.choudhary at oracle.com Fri Mar 13 06:40:55 2020 From: bhawesh.choudhary at oracle.com (Bhawesh Choudhary) Date: Fri, 13 Mar 2020 12:10:55 +0530 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: References: Message-ID: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> Hi, Please find updated Webrev as per suggestions [Test name update and Code formatting] JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/ -Bhawesh On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote: > Hi, > > Please review this fix, > JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 > Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ > > Issue: > In Windows LookAndFeel, When navigating Combobox's list of > JFileChooser via keys, the contents of JFileChooser changes. > > Fix: > Set flag "JComboBox.isTableCellEditor" to True which prohibits > JCombobox from sending selection change event when JCombobox's list > selection change happens via keys. > > > Verification: > Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as > well as BasicLookAndFeel with keys navigation. also added a test case > to verify the same. > > Did not find any misbehavior with the fix. > > Regards > Bhawesh From tejpal.rebari at oracle.com Fri Mar 13 09:30:54 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Fri, 13 Mar 2020 15:00:54 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> Message-ID: Hi Sergey, > On 11-Mar-2020, at 5:27 AM, Sergey Bylokhov wrote: > > On 3/10/20 1:04 am, Tejpal Rebari wrote: >> I am not getting how to cover this in the test. > > I that additional call is necessary, then it should be possible to trigger it by the test. > > -- > Best regards, Sergey. I have updated the test to check for super.keySet(). Now the test will check for 1. defaults key size returned by the UIManager.getDefaults() 2. key size after writing an additional value to the UIManager.getDefaults() Verified that the tests fails after the fix of http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ and passes after adding set.addAll(super.keySet()); Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev2/ Thanks Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Mar 13 10:06:59 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Mar 2020 03:06:59 -0700 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> Message-ID: Looks fine. On 3/13/20 2:30 am, Tejpal Rebari wrote: > Hi Sergey, > >> On 11-Mar-2020, at 5:27 AM, Sergey Bylokhov > wrote: >> >> On 3/10/20 1:04 am, Tejpal Rebari wrote: >>> I am not getting how to cover this in the test. >> >> I that additional call is necessary, then it should be possible to trigger it by the test. >> >> -- >> Best regards, Sergey. > > I have updated the test to check for super.keySet(). > > Now the test will check for > 1. defaults key size returned by the UIManager.getDefaults() > 2. key size after?writing an additional value to the UIManager.getDefaults() > > Verified that the tests fails after the fix of http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ > and passes after adding set.addAll(super.keySet()); > Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev2/ > > Thanks > Tejpal > -- Best regards, Sergey. From JAYATHIRTH.D.V at ORACLE.COM Fri Mar 13 10:25:05 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Fri, 13 Mar 2020 15:55:05 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> Message-ID: <25C79997-C301-46D0-829D-053370F4CBA8@ORACLE.COM> Hi Tejpal, Test case is not verifying all failure scenarios properly (If both test cases fail exception will be thrown only for first test failure) Make sure that you verify each test case failure and print appropriate message. Source change looks good to me. Thanks, Jay > On 13-Mar-2020, at 3:36 PM, Sergey Bylokhov wrote: > > Looks fine. > > On 3/13/20 2:30 am, Tejpal Rebari wrote: >> Hi Sergey, >>> On 11-Mar-2020, at 5:27 AM, Sergey Bylokhov >> wrote: >>> >>> On 3/10/20 1:04 am, Tejpal Rebari wrote: >>>> I am not getting how to cover this in the test. >>> >>> I that additional call is necessary, then it should be possible to trigger it by the test. >>> >>> -- >>> Best regards, Sergey. >> I have updated the test to check for super.keySet(). >> Now the test will check for >> 1. defaults key size returned by the UIManager.getDefaults() >> 2. key size after writing an additional value to the UIManager.getDefaults() >> Verified that the tests fails after the fix of http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ >> and passes after adding set.addAll(super.keySet()); >> Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev2/ >> Thanks >> Tejpal > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tejpal.rebari at oracle.com Fri Mar 13 11:01:10 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Fri, 13 Mar 2020 16:31:10 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: <25C79997-C301-46D0-829D-053370F4CBA8@ORACLE.COM> References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> <25C79997-C301-46D0-829D-053370F4CBA8@ORACLE.COM> Message-ID: Hi Jay, > On 13-Mar-2020, at 3:55 PM, Jayathirth D v wrote: > > Hi Tejpal, > > Test case is not verifying all failure scenarios properly (If both test cases fail exception will be thrown only for first test failure) > Make sure that you verify each test case failure and print appropriate message. > > Source change looks good to me. > > Thanks, > Jay > I have updated the test to properly print the error message according to test cases failure. Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev3/ Thanks Tejpal >> On 13-Mar-2020, at 3:36 PM, Sergey Bylokhov > wrote: >> >> Looks fine. >> >> On 3/13/20 2:30 am, Tejpal Rebari wrote: >>> Hi Sergey, >>>> On 11-Mar-2020, at 5:27 AM, Sergey Bylokhov >> wrote: >>>> >>>> On 3/10/20 1:04 am, Tejpal Rebari wrote: >>>>> I am not getting how to cover this in the test. >>>> >>>> I that additional call is necessary, then it should be possible to trigger it by the test. >>>> >>>> -- >>>> Best regards, Sergey. >>> I have updated the test to check for super.keySet(). >>> Now the test will check for >>> 1. defaults key size returned by the UIManager.getDefaults() >>> 2. key size after writing an additional value to the UIManager.getDefaults() >>> Verified that the tests fails after the fix of http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ >>> and passes after adding set.addAll(super.keySet()); >>> Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev2/ >>> Thanks >>> Tejpal >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAYATHIRTH.D.V at ORACLE.COM Fri Mar 13 11:02:26 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Fri, 13 Mar 2020 16:32:26 +0530 Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> <25C79997-C301-46D0-829D-053370F4CBA8@ORACLE.COM> Message-ID: <357EC5FD-41B0-4EF7-B628-505F5DE784A2@ORACLE.COM> +1. Thanks, Jay > On 13-Mar-2020, at 4:31 PM, Tejpal Rebari wrote: > > Hi Jay, >> On 13-Mar-2020, at 3:55 PM, Jayathirth D v > wrote: >> >> Hi Tejpal, >> >> Test case is not verifying all failure scenarios properly (If both test cases fail exception will be thrown only for first test failure) >> Make sure that you verify each test case failure and print appropriate message. >> >> Source change looks good to me. >> >> Thanks, >> Jay >> > I have updated the test to properly print the error message according to test cases failure. > Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev3/ > > Thanks > Tejpal > > >>> On 13-Mar-2020, at 3:36 PM, Sergey Bylokhov > wrote: >>> >>> Looks fine. >>> >>> On 3/13/20 2:30 am, Tejpal Rebari wrote: >>>> Hi Sergey, >>>>> On 11-Mar-2020, at 5:27 AM, Sergey Bylokhov >> wrote: >>>>> >>>>> On 3/10/20 1:04 am, Tejpal Rebari wrote: >>>>>> I am not getting how to cover this in the test. >>>>> >>>>> I that additional call is necessary, then it should be possible to trigger it by the test. >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> I have updated the test to check for super.keySet(). >>>> Now the test will check for >>>> 1. defaults key size returned by the UIManager.getDefaults() >>>> 2. key size after writing an additional value to the UIManager.getDefaults() >>>> Verified that the tests fails after the fix of http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ >>>> and passes after adding set.addAll(super.keySet()); >>>> Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev2/ >>>> Thanks >>>> Tejpal >>> >>> >>> -- >>> Best regards, Sergey. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Fri Mar 13 11:53:05 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 13 Mar 2020 04:53:05 -0700 (PDT) Subject: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() In-Reply-To: References: <0c5fb1f2-050f-e4cc-1f7d-396a16ee51ce@oracle.com> <52CA7187-2420-4578-858D-4B2E6EC381AC@oracle.com> <1FE7F842-668F-4C33-9B4D-67AF116B3599@oracle.com> <61073d83-a5ad-d21a-0cf6-412c5b8bcfe1@oracle.com> <25C79997-C301-46D0-829D-053370F4CBA8@ORACLE.COM> Message-ID: <9364074c-36d2-4d34-924a-4ae2f4cfeeca@default> Looks good to me though the webrev02 was also good enough and easy to read as second case is anyway going to fail if first case fails. You can push webrev03 as well. Regards, Pankaj From: Tejpal Rebari Sent: Friday, March 13, 2020 4:31 PM To: Jayathirth D v Cc: swing-dev at openjdk.java.net Subject: Re: RFR: 8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet() Hi Jay, On 13-Mar-2020, at 3:55 PM, Jayathirth D v wrote: Hi Tejpal, Test case is not verifying all failure scenarios properly (If both test cases fail exception will be thrown only for first test failure) Make sure that you verify each test case failure and print appropriate message. Source change looks good to me. Thanks, Jay I have updated the test to properly print the error message according to test cases failure. Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev3/ Thanks Tejpal On 13-Mar-2020, at 3:36 PM, Sergey Bylokhov wrote: Looks fine. On 3/13/20 2:30 am, Tejpal Rebari wrote: Hi Sergey, On 11-Mar-2020, at 5:27 AM, Sergey Bylokhov > wrote: On 3/10/20 1:04 am, Tejpal Rebari wrote: I am not getting how to cover this in the test. I that additional call is necessary, then it should be possible to trigger it by the test. -- Best regards, Sergey. I have updated the test to check for super.keySet(). Now the test will check for 1. defaults key size returned by the UIManager.getDefaults() 2. key size after writing an additional value to the UIManager.getDefaults() Verified that the tests fails after the fix of http://cr.openjdk.java.net/~trebari/swing/8146330/webrev1/ and passes after adding set.addAll(super.keySet()); Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8146330/webrev2/ Thanks Tejpal -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Mar 13 16:39:34 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 13 Mar 2020 22:09:34 +0530 Subject: RFR JDK-8236635: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT Message-ID: Hi All, Please review a fix for an issue where it is seen the frame height is different in ubuntu19.10 when it contains JTabbedPane with SCROLL_TAB_LAYOUT policy compared to WRAP_TAB_LAYOUT policy. Bug: https://bugs.openjdk.java.net/browse/JDK-8236635 Issue is because the native frame decorations are different in 19.10 compared to 18.04, where the issue is not seen. Fix is to set the frame undecorated. The original issue 8215396 still fails with this modified test without the 8215396 fix. diff -r 062b36ecf8d7 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Thu Feb 20 14:49:20 2020 +0530 +++ b/test/jdk/ProblemList.txt? Fri Mar 13 21:56:05 2020 +0530 @@ -822,7 +822,6 @@ ?javax/swing/JCheckBox/8032667/bug8032667_image_diff.java 8199063 macosx-all ?javax/swing/JComboBox/7031551/bug7031551.java 8199056 generic-all ?javax/swing/JScrollBar/6924059/bug6924059.java 8199078 generic-all *-javax/swing/JTabbedPane/TabProb.java 8236635 linux-all* ?javax/swing/JTree/8003830/bug8003830.java 8199057 generic-all ?javax/swing/plaf/nimbus/ColorCustomizationTest.java 8199080 generic-all ?javax/swing/SwingWorker/6432565/bug6432565.java 8199077 generic-all diff -r 062b36ecf8d7 test/jdk/javax/swing/JTabbedPane/TabProb.java --- a/test/jdk/javax/swing/JTabbedPane/TabProb.java???? Thu Feb 20 14:49:20 2020 +0530 +++ b/test/jdk/javax/swing/JTabbedPane/TabProb.java???? Fri Mar 13 21:56:05 2020 +0530 @@ -82,6 +82,7 @@ ???????? panel.add(label); ???????? tabpanel.add("TEST", panel); ???????? add(tabpanel, BorderLayout.CENTER); *+??????? setUndecorated(true);* ???????? setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); ???? } Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Sat Mar 14 13:11:29 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Sat, 14 Mar 2020 06:11:29 -0700 (PDT) Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com> References: <92ca9fe1-6bbc-47c6-bc62-3f78ae7c7194@oracle.com> <4db1f723-0f5a-4d66-8db6-529897885d79@default> <4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default> <75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com> Message-ID: <3a4a2cb9-4735-405b-ba6d-6e30131f70b5@default> Hello Sergey, << It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 I tried to code according to my understanding of the idea. I have created a preliminary webrev to demonstrate what I am doing. This is nowhere final, so please ignore the optimizations. Please have a look. As I was thinking, the precision error is creating issue while creating the step count. I have to do lot of stuff to allow values to be changed by editing the textfield. There are some other issues also, like the double value is formatted according to the formatter and that is also causing problems. webrev: http://cr.openjdk.java.net/~pbansal/8220811/webrev01/ Regards, Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 11, 2020 5:33 AM To: Pankaj Bansal ; Alexey Ivanov ; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue On 3/10/20 5:34 am, Pankaj Bansal wrote: > Hello Sergey/Vlad/Alexey, > > Sorry, I could not reply to this earlier. I have one doubt about this approach. Won't the calculation of stepCount itself suffer from floating point issue? I mean the user will pass min, max, stepsize, then wont the calculation of steps required to go from min to max will also suffer from same floating point issue? I think there can be an rounding of error of -1 or +1 in calculation of step count. It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 > > eg. > > int steps =0; > > for (double i=min+stepsize; i<=max; i+=stepsize) > steps++; > > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. > > > The reason is that, there is floating point error in first case, but it is not present in second case. > > I think the best we can do here is as Sergey suggested in his first > reply to use Math.fma to reduce the floating point error chances from > 2 to 1 or just close this as not an issue > > Regards, > > Pankaj > > > On 19/02/20 3:49 AM, Sergey Bylokhov wrote: >> I think it should work, the step will counts from the default value. >> >> So currently: >> 1. if the user set default value to X1 and then he iterates forward 100 times then he will get some X2. During this calculation, he could get "100" rounding issues. >> 2. If later the user decides iterates backward then most probably he will not get X1, and the amount of possible "rounding issues" will be 200. >> >> If the user will repeat steps 1. and 2. then each time the values will "float". >> >> If we will use counter then in the worst case we will get only two roundings per step: X1+step*100 = X2(if we will use fma we will get only one for every step). >> >> It will not solve all issues but at least will make the iteration "stable". >> >> On 2/17/20 1:59 am, Alexey Ivanov wrote: >>> Hi Vlad, >>> >>> The idea looks reasonable. However, it does not allow for manual editing. The cases where max and min values are not multiples of step would be hard to handle with this approach. For example: max = 10.05, min = 0.01, step = 0.1; how many ticks are there? What if the user enters 1.01015; the value should change to 1.11015 or 0.91015. >>> >>> On 13/02/2020 22:22, Volodin, Vladislav wrote: >>>> Hello Sergey, Alexey and Pankaj, >>>> >>>> I am reading the current discussion and I was thinking about an idea changing the code in the way that instead of working with float/double numbers we work with integer ticks. For example, the model remembers the min/max/step values and calculates a number of steps required to reach from min to max. All increment/decrement actions are done against the current ?tick? value. If the current ?tick? reaches 0 - we return min; if maxTick ? we return max. And the current value can be always counted as (min + tick * step) if tick is neither zero, nor max tick count. >>>> >>>> At least if we deal with integer ticks, but all reading operations calculate on the fly, we will be able to control the representativeness of output. >>>> >>>> As always, I don?t know all the details and possible consequences, so feel free to ignore my email, if I am wrong. >>>> >>>> Kind regards, >>>> Vlad >>>> >>>> Sent from myPad >>>> >>>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov wrote: >>>>> >>>>> ?On 2/12/20 8:21 am, Alexey Ivanov wrote: >>>>>> The bug report says that going from -0.15 to -0.10 does not allow going back to -0.15. This happens because the result of this sequence of operations cannot be represented exactly, or, in other words, because of rounding errors; or rather the result is less than the set minimal value. >>>>>> Can we set the value of the spinner to the set minimal value instead of disallowing the operation. I mean, after going up the displayed value is -0.10; going down by 0.05 gives the result which is less than the minimal value for the spinner, and thus going down is not allowed. What if we set the value of the spinner to its minimal value instead? >>>>> In this case, we will need to update all types including int. >>>>> Isn't it will be surprised that the spinner will show the value which is not calculated as "defaultValue + stepValue * stepCount"? >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >> >> > -- Best regards, Sergey. From jason_mehrens at hotmail.com Sat Mar 14 14:39:17 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sat, 14 Mar 2020 14:39:17 +0000 Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: <3a4a2cb9-4735-405b-ba6d-6e30131f70b5@default> References: <92ca9fe1-6bbc-47c6-bc62-3f78ae7c7194@oracle.com> <4db1f723-0f5a-4d66-8db6-529897885d79@default> <4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default> <75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com>, <3a4a2cb9-4735-405b-ba6d-6e30131f70b5@default> Message-ID: Pankaj, I would assume newMinimum.equals(Double.NaN) and newMinimum.equals(Float.NaN) should always evaluate to false. Perhaps you want to use Float.isNaN and Double.isNaN instead? Jason ________________________________________ From: swing-dev on behalf of Pankaj Bansal Sent: Saturday, March 14, 2020 8:11 AM To: Sergey Bylokhov; Alexey Ivanov; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue Hello Sergey, << It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 I tried to code according to my understanding of the idea. I have created a preliminary webrev to demonstrate what I am doing. This is nowhere final, so please ignore the optimizations. Please have a look. As I was thinking, the precision error is creating issue while creating the step count. I have to do lot of stuff to allow values to be changed by editing the textfield. There are some other issues also, like the double value is formatted according to the formatter and that is also causing problems. webrev: http://cr.openjdk.java.net/~pbansal/8220811/webrev01/ Regards, Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 11, 2020 5:33 AM To: Pankaj Bansal ; Alexey Ivanov ; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue On 3/10/20 5:34 am, Pankaj Bansal wrote: > Hello Sergey/Vlad/Alexey, > > Sorry, I could not reply to this earlier. I have one doubt about this approach. Won't the calculation of stepCount itself suffer from floating point issue? I mean the user will pass min, max, stepsize, then wont the calculation of steps required to go from min to max will also suffer from same floating point issue? I think there can be an rounding of error of -1 or +1 in calculation of step count. It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 > > eg. > > int steps =0; > > for (double i=min+stepsize; i<=max; i+=stepsize) > steps++; > > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. > > > The reason is that, there is floating point error in first case, but it is not present in second case. > > I think the best we can do here is as Sergey suggested in his first > reply to use Math.fma to reduce the floating point error chances from > 2 to 1 or just close this as not an issue > > Regards, > > Pankaj > > > On 19/02/20 3:49 AM, Sergey Bylokhov wrote: >> I think it should work, the step will counts from the default value. >> >> So currently: >> 1. if the user set default value to X1 and then he iterates forward 100 times then he will get some X2. During this calculation, he could get "100" rounding issues. >> 2. If later the user decides iterates backward then most probably he will not get X1, and the amount of possible "rounding issues" will be 200. >> >> If the user will repeat steps 1. and 2. then each time the values will "float". >> >> If we will use counter then in the worst case we will get only two roundings per step: X1+step*100 = X2(if we will use fma we will get only one for every step). >> >> It will not solve all issues but at least will make the iteration "stable". >> >> On 2/17/20 1:59 am, Alexey Ivanov wrote: >>> Hi Vlad, >>> >>> The idea looks reasonable. However, it does not allow for manual editing. The cases where max and min values are not multiples of step would be hard to handle with this approach. For example: max = 10.05, min = 0.01, step = 0.1; how many ticks are there? What if the user enters 1.01015; the value should change to 1.11015 or 0.91015. >>> >>> On 13/02/2020 22:22, Volodin, Vladislav wrote: >>>> Hello Sergey, Alexey and Pankaj, >>>> >>>> I am reading the current discussion and I was thinking about an idea changing the code in the way that instead of working with float/double numbers we work with integer ticks. For example, the model remembers the min/max/step values and calculates a number of steps required to reach from min to max. All increment/decrement actions are done against the current ?tick? value. If the current ?tick? reaches 0 - we return min; if maxTick ? we return max. And the current value can be always counted as (min + tick * step) if tick is neither zero, nor max tick count. >>>> >>>> At least if we deal with integer ticks, but all reading operations calculate on the fly, we will be able to control the representativeness of output. >>>> >>>> As always, I don?t know all the details and possible consequences, so feel free to ignore my email, if I am wrong. >>>> >>>> Kind regards, >>>> Vlad >>>> >>>> Sent from myPad >>>> >>>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov wrote: >>>>> >>>>> ?On 2/12/20 8:21 am, Alexey Ivanov wrote: >>>>>> The bug report says that going from -0.15 to -0.10 does not allow going back to -0.15. This happens because the result of this sequence of operations cannot be represented exactly, or, in other words, because of rounding errors; or rather the result is less than the set minimal value. >>>>>> Can we set the value of the spinner to the set minimal value instead of disallowing the operation. I mean, after going up the displayed value is -0.10; going down by 0.05 gives the result which is less than the minimal value for the spinner, and thus going down is not allowed. What if we set the value of the spinner to its minimal value instead? >>>>> In this case, we will need to update all types including int. >>>>> Isn't it will be surprised that the spinner will show the value which is not calculated as "defaultValue + stepValue * stepCount"? >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >> >> > -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Sat Mar 14 14:48:52 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Sat, 14 Mar 2020 07:48:52 -0700 (PDT) Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: References: <92ca9fe1-6bbc-47c6-bc62-3f78ae7c7194@oracle.com> <4db1f723-0f5a-4d66-8db6-529897885d79@default> <4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default> <75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com>> <<3a4a2cb9-4735-405b-ba6d-6e30131f70b5@default> Message-ID: <30730877-5548-46fb-8b8c-716f3b239ba0@default> Hello Jason, << I would assume newMinimum.equals(Double.NaN) and newMinimum.equals(Float.NaN) should always evaluate to false. It seems to work as expected. Double p1 = Double.NaN; Double p2 = 1.0; System.out.println(p1.equals(Double.NaN)); //prints true System.out.println(p2.equals(Double.NaN)); //prints false Regards, Pankaj -----Original Message----- From: Jason Mehrens Sent: Saturday, March 14, 2020 8:09 PM To: Pankaj Bansal ; Sergey Bylokhov ; Alexey Ivanov ; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue Pankaj, I would assume newMinimum.equals(Double.NaN) and newMinimum.equals(Float.NaN) should always evaluate to false. Perhaps you want to use Float.isNaN and Double.isNaN instead? Jason ________________________________________ From: swing-dev on behalf of Pankaj Bansal Sent: Saturday, March 14, 2020 8:11 AM To: Sergey Bylokhov; Alexey Ivanov; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue Hello Sergey, << It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 I tried to code according to my understanding of the idea. I have created a preliminary webrev to demonstrate what I am doing. This is nowhere final, so please ignore the optimizations. Please have a look. As I was thinking, the precision error is creating issue while creating the step count. I have to do lot of stuff to allow values to be changed by editing the textfield. There are some other issues also, like the double value is formatted according to the formatter and that is also causing problems. webrev: http://cr.openjdk.java.net/~pbansal/8220811/webrev01/ Regards, Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 11, 2020 5:33 AM To: Pankaj Bansal ; Alexey Ivanov ; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue On 3/10/20 5:34 am, Pankaj Bansal wrote: > Hello Sergey/Vlad/Alexey, > > Sorry, I could not reply to this earlier. I have one doubt about this approach. Won't the calculation of stepCount itself suffer from floating point issue? I mean the user will pass min, max, stepsize, then wont the calculation of steps required to go from min to max will also suffer from same floating point issue? I think there can be an rounding of error of -1 or +1 in calculation of step count. It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 > > eg. > > int steps =0; > > for (double i=min+stepsize; i<=max; i+=stepsize) > steps++; > > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. > > > The reason is that, there is floating point error in first case, but it is not present in second case. > > I think the best we can do here is as Sergey suggested in his first > reply to use Math.fma to reduce the floating point error chances from > 2 to 1 or just close this as not an issue > > Regards, > > Pankaj > > > On 19/02/20 3:49 AM, Sergey Bylokhov wrote: >> I think it should work, the step will counts from the default value. >> >> So currently: >> 1. if the user set default value to X1 and then he iterates forward 100 times then he will get some X2. During this calculation, he could get "100" rounding issues. >> 2. If later the user decides iterates backward then most probably he will not get X1, and the amount of possible "rounding issues" will be 200. >> >> If the user will repeat steps 1. and 2. then each time the values will "float". >> >> If we will use counter then in the worst case we will get only two roundings per step: X1+step*100 = X2(if we will use fma we will get only one for every step). >> >> It will not solve all issues but at least will make the iteration "stable". >> >> On 2/17/20 1:59 am, Alexey Ivanov wrote: >>> Hi Vlad, >>> >>> The idea looks reasonable. However, it does not allow for manual editing. The cases where max and min values are not multiples of step would be hard to handle with this approach. For example: max = 10.05, min = 0.01, step = 0.1; how many ticks are there? What if the user enters 1.01015; the value should change to 1.11015 or 0.91015. >>> >>> On 13/02/2020 22:22, Volodin, Vladislav wrote: >>>> Hello Sergey, Alexey and Pankaj, >>>> >>>> I am reading the current discussion and I was thinking about an idea changing the code in the way that instead of working with float/double numbers we work with integer ticks. For example, the model remembers the min/max/step values and calculates a number of steps required to reach from min to max. All increment/decrement actions are done against the current ?tick? value. If the current ?tick? reaches 0 - we return min; if maxTick ? we return max. And the current value can be always counted as (min + tick * step) if tick is neither zero, nor max tick count. >>>> >>>> At least if we deal with integer ticks, but all reading operations calculate on the fly, we will be able to control the representativeness of output. >>>> >>>> As always, I don?t know all the details and possible consequences, so feel free to ignore my email, if I am wrong. >>>> >>>> Kind regards, >>>> Vlad >>>> >>>> Sent from myPad >>>> >>>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov wrote: >>>>> >>>>> ?On 2/12/20 8:21 am, Alexey Ivanov wrote: >>>>>> The bug report says that going from -0.15 to -0.10 does not allow going back to -0.15. This happens because the result of this sequence of operations cannot be represented exactly, or, in other words, because of rounding errors; or rather the result is less than the set minimal value. >>>>>> Can we set the value of the spinner to the set minimal value instead of disallowing the operation. I mean, after going up the displayed value is -0.10; going down by 0.05 gives the result which is less than the minimal value for the spinner, and thus going down is not allowed. What if we set the value of the spinner to its minimal value instead? >>>>> In this case, we will need to update all types including int. >>>>> Isn't it will be surprised that the spinner will show the value which is not calculated as "defaultValue + stepValue * stepCount"? >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >> >> > -- Best regards, Sergey. From vladislav.volodin at sap.com Sat Mar 14 20:33:18 2020 From: vladislav.volodin at sap.com (Volodin, Vladislav) Date: Sat, 14 Mar 2020 20:33:18 +0000 Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: <30730877-5548-46fb-8b8c-716f3b239ba0@default> References: <92ca9fe1-6bbc-47c6-bc62-3f78ae7c7194@oracle.com> <4db1f723-0f5a-4d66-8db6-529897885d79@default> <4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default> <75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com> <3a4a2cb9-4735-405b-ba6d-6e30131f70b5@default> <30730877-5548-46fb-8b8c-716f3b239ba0@default> Message-ID: <0D81D11D-910C-4B0F-AF02-E3D768F21D6C@sap.com> Hello Pankaj, I am not the reviewer, but I agree with Jason. To me p1.equals(Double.NaN) looks confusing. Because people might think that it will be equivalent to p1 == Double.NaN, that will return false, when p1 is also NaN (https://stackoverflow.com/questions/8819738/why-does-double-nan-double-nan-return-false). I prefer to use the dedicated method such as "public static boolean isNaN(double v)". It looks self-descriptive. Meanwhile, I remember you sentence regarding the number of steps: > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. I checked this part with the code: Double min = -.15; Double max = 0.15; Double stepsize = .05; Double steps = (max - min) / stepsize; And I found out that in this case the number of steps will be 5,999999....., but we can compensate it with either Math.round, it will return 6, or we can add the "epsilon" value to "max", and count the number of steps as it is: Double max = 0.15 + Math.ulp(1.0); Steps count will be 6.00000238418579. Since there is no value in Double (and probably float) less than Math.ulp (or epsilon, if we use this term), it will be probably safe to use my approach. What do you think? Kind regards, Vlad ?On 14.03.20, 15:51, "Pankaj Bansal" wrote: Hello Jason, << I would assume newMinimum.equals(Double.NaN) and newMinimum.equals(Float.NaN) should always evaluate to false. It seems to work as expected. Double p1 = Double.NaN; Double p2 = 1.0; System.out.println(p1.equals(Double.NaN)); //prints true System.out.println(p2.equals(Double.NaN)); //prints false Regards, Pankaj -----Original Message----- From: Jason Mehrens Sent: Saturday, March 14, 2020 8:09 PM To: Pankaj Bansal ; Sergey Bylokhov ; Alexey Ivanov ; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue Pankaj, I would assume newMinimum.equals(Double.NaN) and newMinimum.equals(Float.NaN) should always evaluate to false. Perhaps you want to use Float.isNaN and Double.isNaN instead? Jason ________________________________________ From: swing-dev on behalf of Pankaj Bansal Sent: Saturday, March 14, 2020 8:11 AM To: Sergey Bylokhov; Alexey Ivanov; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue Hello Sergey, << It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 I tried to code according to my understanding of the idea. I have created a preliminary webrev to demonstrate what I am doing. This is nowhere final, so please ignore the optimizations. Please have a look. As I was thinking, the precision error is creating issue while creating the step count. I have to do lot of stuff to allow values to be changed by editing the textfield. There are some other issues also, like the double value is formatted according to the formatter and that is also causing problems. webrev: http://cr.openjdk.java.net/~pbansal/8220811/webrev01/ Regards, Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 11, 2020 5:33 AM To: Pankaj Bansal ; Alexey Ivanov ; Volodin, Vladislav Cc: swing-dev at openjdk.java.net Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue On 3/10/20 5:34 am, Pankaj Bansal wrote: > Hello Sergey/Vlad/Alexey, > > Sorry, I could not reply to this earlier. I have one doubt about this approach. Won't the calculation of stepCount itself suffer from floating point issue? I mean the user will pass min, max, stepsize, then wont the calculation of steps required to go from min to max will also suffer from same floating point issue? I think there can be an rounding of error of -1 or +1 in calculation of step count. It will differ for two cases: - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. - Initial/Default value will never be skipped due to counter=0 > > eg. > > int steps =0; > > for (double i=min+stepsize; i<=max; i+=stepsize) > steps++; > > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. > > > The reason is that, there is floating point error in first case, but it is not present in second case. > > I think the best we can do here is as Sergey suggested in his first > reply to use Math.fma to reduce the floating point error chances from > 2 to 1 or just close this as not an issue > > Regards, > > Pankaj > > > On 19/02/20 3:49 AM, Sergey Bylokhov wrote: >> I think it should work, the step will counts from the default value. >> >> So currently: >> 1. if the user set default value to X1 and then he iterates forward 100 times then he will get some X2. During this calculation, he could get "100" rounding issues. >> 2. If later the user decides iterates backward then most probably he will not get X1, and the amount of possible "rounding issues" will be 200. >> >> If the user will repeat steps 1. and 2. then each time the values will "float". >> >> If we will use counter then in the worst case we will get only two roundings per step: X1+step*100 = X2(if we will use fma we will get only one for every step). >> >> It will not solve all issues but at least will make the iteration "stable". >> >> On 2/17/20 1:59 am, Alexey Ivanov wrote: >>> Hi Vlad, >>> >>> The idea looks reasonable. However, it does not allow for manual editing. The cases where max and min values are not multiples of step would be hard to handle with this approach. For example: max = 10.05, min = 0.01, step = 0.1; how many ticks are there? What if the user enters 1.01015; the value should change to 1.11015 or 0.91015. >>> >>> On 13/02/2020 22:22, Volodin, Vladislav wrote: >>>> Hello Sergey, Alexey and Pankaj, >>>> >>>> I am reading the current discussion and I was thinking about an idea changing the code in the way that instead of working with float/double numbers we work with integer ticks. For example, the model remembers the min/max/step values and calculates a number of steps required to reach from min to max. All increment/decrement actions are done against the current ?tick? value. If the current ?tick? reaches 0 - we return min; if maxTick ? we return max. And the current value can be always counted as (min + tick * step) if tick is neither zero, nor max tick count. >>>> >>>> At least if we deal with integer ticks, but all reading operations calculate on the fly, we will be able to control the representativeness of output. >>>> >>>> As always, I don?t know all the details and possible consequences, so feel free to ignore my email, if I am wrong. >>>> >>>> Kind regards, >>>> Vlad >>>> >>>> Sent from myPad >>>> >>>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov wrote: >>>>> >>>>> On 2/12/20 8:21 am, Alexey Ivanov wrote: >>>>>> The bug report says that going from -0.15 to -0.10 does not allow going back to -0.15. This happens because the result of this sequence of operations cannot be represented exactly, or, in other words, because of rounding errors; or rather the result is less than the set minimal value. >>>>>> Can we set the value of the spinner to the set minimal value instead of disallowing the operation. I mean, after going up the displayed value is -0.10; going down by 0.05 gives the result which is less than the minimal value for the spinner, and thus going down is not allowed. What if we set the value of the spinner to its minimal value instead? >>>>> In this case, we will need to update all types including int. >>>>> Isn't it will be surprised that the spinner will show the value which is not calculated as "defaultValue + stepValue * stepCount"? >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Mar 16 05:34:12 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 15 Mar 2020 22:34:12 -0700 Subject: RFR JDK-8236635: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT In-Reply-To: References: Message-ID: <36faaf20-e571-0fea-3797-4a1ab771a4af@oracle.com> Looks fine. On 3/13/20 9:39 am, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen the frame height is different in ubuntu19.10 when it contains JTabbedPane with SCROLL_TAB_LAYOUT policy compared to WRAP_TAB_LAYOUT policy. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236635 > > Issue is because the native frame decorations are different in 19.10 compared to 18.04, where the issue is not seen. Fix is to set the frame undecorated. The original issue 8215396 still fails with this modified test without the 8215396 fix. > > diff -r 062b36ecf8d7 test/jdk/ProblemList.txt > > --- a/test/jdk/ProblemList.txt? Thu Feb 20 14:49:20 2020 +0530 > +++ b/test/jdk/ProblemList.txt? Fri Mar 13 21:56:05 2020 +0530 > @@ -822,7 +822,6 @@ > ?javax/swing/JCheckBox/8032667/bug8032667_image_diff.java 8199063 macosx-all > ?javax/swing/JComboBox/7031551/bug7031551.java 8199056 generic-all > ?javax/swing/JScrollBar/6924059/bug6924059.java 8199078 generic-all > *-javax/swing/JTabbedPane/TabProb.java 8236635 linux-all* > ?javax/swing/JTree/8003830/bug8003830.java 8199057 generic-all > ?javax/swing/plaf/nimbus/ColorCustomizationTest.java 8199080 generic-all > ?javax/swing/SwingWorker/6432565/bug6432565.java 8199077 generic-all > > diff -r 062b36ecf8d7 test/jdk/javax/swing/JTabbedPane/TabProb.java > > --- a/test/jdk/javax/swing/JTabbedPane/TabProb.java???? Thu Feb 20 14:49:20 2020 +0530 > +++ b/test/jdk/javax/swing/JTabbedPane/TabProb.java???? Fri Mar 13 21:56:05 2020 +0530 > @@ -82,6 +82,7 @@ > ???????? panel.add(label); > ???????? tabpanel.add("TEST", panel); > ???????? add(tabpanel, BorderLayout.CENTER); > *+??????? setUndecorated(true);* > ???????? setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); > > ???? } > Regards > Prasanta -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Mon Mar 16 07:10:14 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 16 Mar 2020 12:40:14 +0530 Subject: RFR JDK-8236635: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT In-Reply-To: References: Message-ID: Looks good to me -Pankaj On 13/03/20 10:09 PM, Prasanta Sadhukhan wrote: > > Hi All, > > Please review a fix for an issue where it is seen the frame height is > different in ubuntu19.10 when it contains JTabbedPane with > SCROLL_TAB_LAYOUT policy compared to WRAP_TAB_LAYOUT policy. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236635 > > Issue is because the native frame decorations are different in 19.10 > compared to 18.04, where the issue is not seen. Fix is to set the > frame undecorated. The original issue 8215396 still fails with this > modified test without the 8215396 fix. > > diff -r 062b36ecf8d7 test/jdk/ProblemList.txt > > --- a/test/jdk/ProblemList.txt? Thu Feb 20 14:49:20 2020 +0530 > +++ b/test/jdk/ProblemList.txt? Fri Mar 13 21:56:05 2020 +0530 > @@ -822,7 +822,6 @@ > ?javax/swing/JCheckBox/8032667/bug8032667_image_diff.java 8199063 > macosx-all > ?javax/swing/JComboBox/7031551/bug7031551.java 8199056 generic-all > ?javax/swing/JScrollBar/6924059/bug6924059.java 8199078 generic-all > *-javax/swing/JTabbedPane/TabProb.java 8236635 linux-all* > ?javax/swing/JTree/8003830/bug8003830.java 8199057 generic-all > ?javax/swing/plaf/nimbus/ColorCustomizationTest.java 8199080 generic-all > ?javax/swing/SwingWorker/6432565/bug6432565.java 8199077 generic-all > > diff -r 062b36ecf8d7 test/jdk/javax/swing/JTabbedPane/TabProb.java > > --- a/test/jdk/javax/swing/JTabbedPane/TabProb.java???? Thu Feb 20 > 14:49:20 2020 +0530 > +++ b/test/jdk/javax/swing/JTabbedPane/TabProb.java???? Fri Mar 13 > 21:56:05 2020 +0530 > @@ -82,6 +82,7 @@ > ???????? panel.add(label); > ???????? tabpanel.add("TEST", panel); > ???????? add(tabpanel, BorderLayout.CENTER); > *+??????? setUndecorated(true);* > ???????? setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); > > ???? } > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Mon Mar 16 08:36:28 2020 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Mar 2020 01:36:28 -0700 (PDT) Subject: RFR: 8152332 [macosx] JFileChooser cannot be serialized on Mac OS X Message-ID: <31af916b-b107-4b9e-93d1-d2413de8e760@default> Hello. Please review the fix for JDK/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8152332 Fix: http://cr.openjdk.java.net/~serb/8152332/webrev.00 This test failed because of two product bugs JDK-8240633 and JDK-8240690(still under review). But there is an issue in the test itself, it uses a sequence of robot events which does not work on L&Fs such as Aqua/Nimbus but works on Metal. The test was updated to close the file chooser w/o robot, and the default button is verified explicitly, also added a check for all L&Fs. I have checked that it is possible to verify the initial bug JDK-8146301 using an updated test. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Mar 16 11:55:10 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 16 Mar 2020 17:25:10 +0530 Subject: RFR: 8240690 Race condition between EDT and BasicDirectoryModel.FilesLoader.run0() In-Reply-To: <2ac1ff2c-6a0a-f706-4847-bca62ff09dc8@oracle.com> References: <2ac1ff2c-6a0a-f706-4847-bca62ff09dc8@oracle.com> Message-ID: <0c6f5daf-9f4a-7871-e8cf-230a7c6a5b5b@oracle.com> Looks ok to me. Regards Prasanta On 09-Mar-20 5:17 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk/client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240690 > Fix: http://cr.openjdk.java.net/~serb/8240690/webrev.01 > > The test in the webrev has failed from time to time in our > CI. It was closed and serialize/deserialize the JFileChooser > on the main thread under Motif L&F only. Initially, I thought > that the intermittent issues will be fixed by moving the code > to EDT. I have done it, and also add a check for all L&Fs. > As a result, I was able to reproduce tons of issues related > to JFileChooser on all platforms. > > 1. When we create the JFileChooser and initialize some L&F, > we create some background thread that loads the list of files, > and only after that adds the list of files to the JFileChooser > itself. This is one of the exception where we access the swing > component on non EDT, take a look to the changes in > ? BasicDirectoryModel.FilesLoader. > I have moved some calls to the JFileChooser from the FilesLoader.run0 > which is executed on the background thread to the constructor of > FilesLoader which is executed on the EDT. So on the background > thread, the "JFileChooser.isTraversable" and "JFileChooser.accept" will > be used. These methods are changed to be more multiple-threads > friendly(mostly read the property to the local field then check, then > use). > > 2. During serialization, we temporarily reset the FileSystemView of > the JFileChooser to the null(it is also possible to do this via public > API). > This uncovered a few places where we did not expect the null. > > 3. The "FilesLoader" had a logic of "runnables" blocks of data which > should be used to update the JFileChooser by some portions of data. We > used the only one "runnable" in the Vector of runnables, but even then > it caused a concurrent modification exception if we tried to cancel the > task and background thread modified the list of tasks(the list from empty > became non-empty). ->> I just replaced it by one reference. > > Note that this fix works only on top of > https://mail.openjdk.java.net/pipermail/swing-dev/2020-March/010155.html > otherwise serialization just does not work on macOS. > From kwong at proofpoint.com Mon Mar 16 17:08:30 2020 From: kwong at proofpoint.com (Kenny Wong) Date: Mon, 16 Mar 2020 17:08:30 +0000 Subject: OOM error parsing HTML with large 
 Tag text
Message-ID: <8114B407-4158-4FA6-A8EA-52AED7C4BA30@proofpoint.com>

Hello,

After upgrading from Java 8 to 11, we started seeing OOM errors when parsing HTML files with a large 
 tag text. The test program below works fine under Java 8, but terminates with an OutOfMemoryError under Java 9 or later. If the 
 tag text is *not* '\n' separated, it works in all versions of Java.

We have tracked down the problem to a change originally committed to Java 9:
https://github.com/openjdk/jdk/commit/17679435a174f6a7f0e450309dc8775e77df968a

Reverting the above change or replacing `Arrays.copyOf(txt, txt.length)` with `Arrays.copyOfRange(txt, offs, offs + length)` fixes the OOM error.

Thank you,
Kenny Wong

--- 8< ---
import java.io.StringReader;

import javax.swing.text.html.HTMLEditorKit;

public class Test {
    public static void main(String[] args) throws Exception {
        StringBuilder html = new StringBuilder();
        html.append("
");
        for (int i = 0; i < 10_000; i++) {
            html.append("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789")
                .append("\n");
        }
        html.append("
");

        HTMLEditorKit kit = new HTMLEditorKit();
        kit.read(new StringReader(html.toString()), kit.createDefaultDocument(), 0);
    }
}
--

--- 8< ---
$ java --version
openjdk 11.0.3 2019-04-16 LTS
OpenJDK Runtime Environment Zulu11.31+11-CA (build 11.0.3+7-LTS)
OpenJDK 64-Bit Server VM Zulu11.31+11-CA (build 11.0.3+7-LTS, mixed mode)

-bash3.2$ java Test.java 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.base/java.util.Arrays.copyOf(Arrays.java:3841)
    at java.desktop/javax.swing.text.DefaultStyledDocument$ElementSpec.(DefaultStyledDocument.java:1267)
    at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.addContent(HTMLDocument.java:3909)
    at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.addContent(HTMLDocument.java:3883)
    at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.preContent(HTMLDocument.java:3787)
    at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.handleText(HTMLDocument.java:2766)
    at java.desktop/javax.swing.text.html.parser.DocumentParser.handleText(DocumentParser.java:271)
    at java.desktop/javax.swing.text.html.parser.Parser.handleText(Parser.java:409)
    at java.desktop/javax.swing.text.html.parser.Parser.endTag(Parser.java:524)
    at java.desktop/javax.swing.text.html.parser.Parser.parseTag(Parser.java:1934)
    at java.desktop/javax.swing.text.html.parser.Parser.parseContent(Parser.java:2195)
    at java.desktop/javax.swing.text.html.parser.Parser.parse(Parser.java:2372)
    at java.desktop/javax.swing.text.html.parser.DocumentParser.parse(DocumentParser.java:135)
    at java.desktop/javax.swing.text.html.parser.ParserDelegator.parse(ParserDelegator.java:113)
    at java.desktop/javax.swing.text.html.HTMLEditorKit.read(HTMLEditorKit.java:263)
    at Test.main(Test.java:16)
---



From Sergey.Bylokhov at oracle.com  Mon Mar 16 17:29:12 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Mar 2020 10:29:12 -0700
Subject:  OOM error parsing HTML with large 
 Tag text
In-Reply-To: <8114B407-4158-4FA6-A8EA-52AED7C4BA30@proofpoint.com>
References: <8114B407-4158-4FA6-A8EA-52AED7C4BA30@proofpoint.com>
Message-ID: <9e07bca6-4a88-615d-b0e2-c61b8a7d9823@oracle.com>

Hi, Kenny.

Thank you for your report, can you please file the bug here:
https://bugs.java.com/bugdatabase

On 3/16/20 10:08 am, Kenny Wong wrote:
> Hello,
> 
> After upgrading from Java 8 to 11, we started seeing OOM errors when parsing HTML files with a large 
 tag text. The test program below works fine under Java 8, but terminates with an OutOfMemoryError under Java 9 or later. If the 
 tag text is *not* '\n' separated, it works in all versions of Java.
> 
> We have tracked down the problem to a change originally committed to Java 9:
> https://github.com/openjdk/jdk/commit/17679435a174f6a7f0e450309dc8775e77df968a
> 
> Reverting the above change or replacing `Arrays.copyOf(txt, txt.length)` with `Arrays.copyOfRange(txt, offs, offs + length)` fixes the OOM error.
> 
> Thank you,
> Kenny Wong
> 
> --- 8< ---
> import java.io.StringReader;
> 
> import javax.swing.text.html.HTMLEditorKit;
> 
> public class Test {
>      public static void main(String[] args) throws Exception {
>          StringBuilder html = new StringBuilder();
>          html.append("
");
>          for (int i = 0; i < 10_000; i++) {
>              html.append("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789")
>                  .append("\n");
>          }
>          html.append("
");
> 
>          HTMLEditorKit kit = new HTMLEditorKit();
>          kit.read(new StringReader(html.toString()), kit.createDefaultDocument(), 0);
>      }
> }
> --
> 
> --- 8< ---
> $ java --version
> openjdk 11.0.3 2019-04-16 LTS
> OpenJDK Runtime Environment Zulu11.31+11-CA (build 11.0.3+7-LTS)
> OpenJDK 64-Bit Server VM Zulu11.31+11-CA (build 11.0.3+7-LTS, mixed mode)
> 
> -bash3.2$ java Test.java
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>      at java.base/java.util.Arrays.copyOf(Arrays.java:3841)
>      at java.desktop/javax.swing.text.DefaultStyledDocument$ElementSpec.(DefaultStyledDocument.java:1267)
>      at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.addContent(HTMLDocument.java:3909)
>      at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.addContent(HTMLDocument.java:3883)
>      at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.preContent(HTMLDocument.java:3787)
>      at java.desktop/javax.swing.text.html.HTMLDocument$HTMLReader.handleText(HTMLDocument.java:2766)
>      at java.desktop/javax.swing.text.html.parser.DocumentParser.handleText(DocumentParser.java:271)
>      at java.desktop/javax.swing.text.html.parser.Parser.handleText(Parser.java:409)
>      at java.desktop/javax.swing.text.html.parser.Parser.endTag(Parser.java:524)
>      at java.desktop/javax.swing.text.html.parser.Parser.parseTag(Parser.java:1934)
>      at java.desktop/javax.swing.text.html.parser.Parser.parseContent(Parser.java:2195)
>      at java.desktop/javax.swing.text.html.parser.Parser.parse(Parser.java:2372)
>      at java.desktop/javax.swing.text.html.parser.DocumentParser.parse(DocumentParser.java:135)
>      at java.desktop/javax.swing.text.html.parser.ParserDelegator.parse(ParserDelegator.java:113)
>      at java.desktop/javax.swing.text.html.HTMLEditorKit.read(HTMLEditorKit.java:263)
>      at Test.main(Test.java:16)
> ---
> 
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Tue Mar 17 13:54:29 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 17 Mar 2020 19:24:29 +0530
Subject:  RFR 8241078: OOM error parsing HTML with large 
	Tag text
Message-ID: <6585cb9d-7fa8-3084-1046-7345e0740f75@oracle.com>

Hi All,

Please review a fix for an issue where it is seen that OOM errors 
generated when parsing HTML files with large 
 tagtext.

This is because of fix done in JDK-8173123 where the entire data array 
was copied again and again, insteadof the range specified via offset.

Fix is to use the offset in array copying to only copy the range specified

Bug: https://bugs.openjdk.java.net/browse/JDK-8241078

webrev: http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.0/

All javax/swing/text/html and javax/swing/text/DefaultStyleDocument 
jtreg test still pass after this change.

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Tue Mar 17 18:18:30 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Mar 2020 11:18:30 -0700
Subject:  RFR 8241078: OOM error parsing HTML with large
 
 Tag text
In-Reply-To: <6585cb9d-7fa8-3084-1046-7345e0740f75@oracle.com>
References: <6585cb9d-7fa8-3084-1046-7345e0740f75@oracle.com>
Message-ID: 

HI, Prasanta.

I suggest to limit memory in the test by the "-mx", otherwise
the test will pass on the systems which has the big amount of memory.
I tested 100G, when it pass.

On 3/17/20 6:54 am, Prasanta Sadhukhan wrote:
> Hi All,
> 
> Please review a fix for an issue where it is seen that OOM errors generated when parsing HTML files with large 
 tagtext.
> 
> This is because of fix done in JDK-8173123 where the entire data array was copied again and again, insteadof the range specified via offset.
> 
> Fix is to use the offset in array copying to only copy the range specified
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241078
> 
> webrev: http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.0/
> 
> All javax/swing/text/html and javax/swing/text/DefaultStyleDocument jtreg test still pass after this change.
> 
> Regards
> Prasanta


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Mar 18 03:54:51 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 18 Mar 2020 09:24:51 +0530
Subject:  RFR 8241078: OOM error parsing HTML with large
 
 Tag text
In-Reply-To: 
References: <6585cb9d-7fa8-3084-1046-7345e0740f75@oracle.com>
 
Message-ID: <0be3ab0b-8bcb-fe55-62b7-cd01b142ebd0@oracle.com>

Hi Sergey,

Test updated

http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.1/

Regards
Prasanta
On 17-Mar-20 11:48 PM, Sergey Bylokhov wrote:
> HI, Prasanta.
>
> I suggest to limit memory in the test by the "-mx", otherwise
> the test will pass on the systems which has the big amount of memory.
> I tested 100G, when it pass.
>
> On 3/17/20 6:54 am, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for an issue where it is seen that OOM errors 
>> generated when parsing HTML files with large 
 tagtext.
>>
>> This is because of fix done in JDK-8173123 where the entire data 
>> array was copied again and again, insteadof the range specified via 
>> offset.
>>
>> Fix is to use the offset in array copying to only copy the range 
>> specified
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241078
>>
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.0/
>>
>> All javax/swing/text/html and javax/swing/text/DefaultStyleDocument 
>> jtreg test still pass after this change.
>>
>> Regards
>> Prasanta
>
>

From prasanta.sadhukhan at oracle.com  Wed Mar 18 13:25:29 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 18 Mar 2020 18:55:29 +0530
Subject:  RFR JDK-8226230:Test
 javax/swing/JInternalFrame/8020708/bug8020708.java fails on Ubuntu
Message-ID: 

Hi All,

Please review a fix for an issue where this test fails in ubuntu citing 
" Close mnemonic does not work in [The CDE/Motif Look and Feel - 
com.sun.java.swing.plaf.motif.MotifLookAndFeel]"

Issue was in the test where subsequent frame with JInternalFrame were 
created almost instantaneously after the previous frame's mnemonic was 
tested. Added a delay and also make sure the frame is created in middle 
and decorations off to prevent any false clicks at wrong locations since 
the mouse needs to be moved to the menu for opening the menu which might 
overlap with ubuntu's top menubar.

Testing on ubuntu 16, 18.04 and 19.10, windows and mac is green.

diff -r 889b4191879c 
test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java
--- a/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java Mon 
Mar 16 12:49:08 2020 +0530
+++ b/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java Wed 
Mar 18 18:43:37 2020 +0530
@@ -57,6 +57,7 @@
 ???????? new Locale("sv"),
 ???????? new Locale("zh", "CN"),
 ???? };
 ???? private static final String[] LOOK_AND_FEELS = {
 ???????? "Nimbus",
@@ -87,6 +88,8 @@
 ???????????? public void run() {
 ???????????????? frame = new JFrame("Test");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
+?????????????? frame.setUndecorated(true);
+?????????????? frame.setLocationRelativeTo(null);
 ???????????????? frame.setSize(300, 200);

 ???????????????? JDesktopPane desktop = new JDesktopPane();
@@ -132,6 +135,7 @@
 ???????????????? frame.dispose();
 ???????????? }
 ???????? });
+?????? robot.delay(500);

 ???? }
Regards
Prasanta

From philip.race at oracle.com  Wed Mar 18 21:28:11 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 18 Mar 2020 14:28:11 -0700
Subject:  RFR: 8241229: Problem list
	jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
Message-ID: <5E72926B.2030602@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8241229

We only need to problem list on linux & solaris :


diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -808,6 +808,7 @@
  javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 
macosx-all
  javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
  javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 macosx-all
+jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 
linux-all,solaris-all
  javax/swing/UITest/UITest.java 8198392 generic-all
  javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 8198394 
generic-all
  javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 
generic-all

-phil

From Sergey.Bylokhov at oracle.com  Wed Mar 18 21:32:38 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 18 Mar 2020 14:32:38 -0700
Subject:  RFR: 8241229: Problem list
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
In-Reply-To: <5E72926B.2030602@oracle.com>
References: <5E72926B.2030602@oracle.com>
Message-ID: <26927618-3e83-d7f8-31e7-5e59eb58465e@oracle.com>

I guess that bug easy to fix, just need to add headful keyword to the test.

On 3/18/20 2:28 pm, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241229
> 
> We only need to problem list on linux & solaris :
> 
> 
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -808,6 +808,7 @@
>  ?javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 macosx-all
>  ?javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
>  ?javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 macosx-all
> +jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 linux-all,solaris-all
>  ?javax/swing/UITest/UITest.java 8198392 generic-all
>  ?javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 8198394 generic-all
>  ?javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 generic-all
> 
> -phil


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Mar 18 21:41:21 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 18 Mar 2020 14:41:21 -0700
Subject:  RFR: 8241229: Problem list
	jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
In-Reply-To: <26927618-3e83-d7f8-31e7-5e59eb58465e@oracle.com>
References: <5E72926B.2030602@oracle.com>
 <26927618-3e83-d7f8-31e7-5e59eb58465e@oracle.com>
Message-ID: <5E729581.6030206@oracle.com>

That is one possible solution that I mentioned, but I am not sure it is
the right one. Needs investigating by the RE.

Meanwhile this is  about the problem list so it does not fail tomorrow.

-phil.

On 3/18/20, 2:32 PM, Sergey Bylokhov wrote:
> I guess that bug easy to fix, just need to add headful keyword to the 
> test.
>
> On 3/18/20 2:28 pm, Philip Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241229
>>
>> We only need to problem list on linux & solaris :
>>
>>
>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt
>> +++ b/test/jdk/ProblemList.txt
>> @@ -808,6 +808,7 @@
>>   javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 
>> macosx-all
>>   javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
>>   javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 macosx-all
>> +jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 
>> linux-all,solaris-all
>>   javax/swing/UITest/UITest.java 8198392 generic-all
>>   javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 8198394 
>> generic-all
>>   javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 
>> generic-all
>>
>> -phil
>
>

From Sergey.Bylokhov at oracle.com  Wed Mar 18 21:52:23 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 18 Mar 2020 14:52:23 -0700
Subject:  RFR: 8241229: Problem list
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
In-Reply-To: <5E729581.6030206@oracle.com>
References: <5E72926B.2030602@oracle.com>
 <26927618-3e83-d7f8-31e7-5e59eb58465e@oracle.com>
 <5E729581.6030206@oracle.com>
Message-ID: 

On 3/18/20 2:41 pm, Philip Race wrote:
> That is one possible solution that I mentioned, but I am not sure it is
> the right one. Needs investigating by the RE.

It is an ok thing, the L&F might be unsupported on some specific
platform even if returned in the installed L&F list. Other possible thing
is to skip this exception in the test and move to the next L&F.

> 
> Meanwhile this is? about the problem list so it does not fail tomorrow.
> 
> -phil.
> 
> On 3/18/20, 2:32 PM, Sergey Bylokhov wrote:
>> I guess that bug easy to fix, just need to add headful keyword to the test.
>>
>> On 3/18/20 2:28 pm, Philip Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241229
>>>
>>> We only need to problem list on linux & solaris :
>>>
>>>
>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>>> --- a/test/jdk/ProblemList.txt
>>> +++ b/test/jdk/ProblemList.txt
>>> @@ -808,6 +808,7 @@
>>> ? javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 macosx-all
>>> ? javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
>>> ? javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 macosx-all
>>> +jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 linux-all,solaris-all
>>> ? javax/swing/UITest/UITest.java 8198392 generic-all
>>> ? javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 8198394 generic-all
>>> ? javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 generic-all
>>>
>>> -phil
>>
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Mar 18 21:54:41 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 18 Mar 2020 14:54:41 -0700
Subject:  RFR: 8241229: Problem list
	jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
In-Reply-To: 
References: <5E72926B.2030602@oracle.com>
 <26927618-3e83-d7f8-31e7-5e59eb58465e@oracle.com>
 <5E729581.6030206@oracle.com>
 
Message-ID: <5E7298A1.1080305@oracle.com>



On 3/18/20, 2:52 PM, Sergey Bylokhov wrote:
> On 3/18/20 2:41 pm, Philip Race wrote:
>> That is one possible solution that I mentioned, but I am not sure it is
>> the right one. Needs investigating by the RE.
>
> It is an ok thing, the L&F might be unsupported on some specific
> platform even if returned in the installed L&F list. Other possible thing
> is to skip this exception in the test and move to the next L&F.

Yes, I also mentioned that in the bug description

So can we problem list this today ?

-phil.
>
>>
>> Meanwhile this is  about the problem list so it does not fail tomorrow.
>>
>> -phil.
>>
>> On 3/18/20, 2:32 PM, Sergey Bylokhov wrote:
>>> I guess that bug easy to fix, just need to add headful keyword to 
>>> the test.
>>>
>>> On 3/18/20 2:28 pm, Philip Race wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241229
>>>>
>>>> We only need to problem list on linux & solaris :
>>>>
>>>>
>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>>>> --- a/test/jdk/ProblemList.txt
>>>> +++ b/test/jdk/ProblemList.txt
>>>> @@ -808,6 +808,7 @@
>>>>   javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 
>>>> macosx-all
>>>>   javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
>>>>   javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 
>>>> macosx-all
>>>> +jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 
>>>> 8241228 linux-all,solaris-all
>>>>   javax/swing/UITest/UITest.java 8198392 generic-all
>>>>   javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 
>>>> 8198394 generic-all
>>>>   javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 
>>>> generic-all
>>>>
>>>> -phil
>>>
>>>
>
>

From Sergey.Bylokhov at oracle.com  Wed Mar 18 21:59:57 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 18 Mar 2020 14:59:57 -0700
Subject:  RFR 8241078: OOM error parsing HTML with large
 
 Tag text
In-Reply-To: <0be3ab0b-8bcb-fe55-62b7-cd01b142ebd0@oracle.com>
References: <6585cb9d-7fa8-3084-1046-7345e0740f75@oracle.com>
 
 <0be3ab0b-8bcb-fe55-62b7-cd01b142ebd0@oracle.com>
Message-ID: 

Looks fine.

On 3/17/20 8:54 pm, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> Test updated
> 
> http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.1/
> 
> Regards
> Prasanta
> On 17-Mar-20 11:48 PM, Sergey Bylokhov wrote:
>> HI, Prasanta.
>>
>> I suggest to limit memory in the test by the "-mx", otherwise
>> the test will pass on the systems which has the big amount of memory.
>> I tested 100G, when it pass.
>>
>> On 3/17/20 6:54 am, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue where it is seen that OOM errors generated when parsing HTML files with large 
 tagtext.
>>>
>>> This is because of fix done in JDK-8173123 where the entire data array was copied again and again, insteadof the range specified via offset.
>>>
>>> Fix is to use the offset in array copying to only copy the range specified
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241078
>>>
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.0/
>>>
>>> All javax/swing/text/html and javax/swing/text/DefaultStyleDocument jtreg test still pass after this change.
>>>
>>> Regards
>>> Prasanta
>>
>>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Mar 18 22:01:15 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 18 Mar 2020 15:01:15 -0700
Subject:  RFR JDK-8226230:Test
 javax/swing/JInternalFrame/8020708/bug8020708.java fails on Ubuntu
In-Reply-To: 
References: 
Message-ID: 

Looks fine.

On 3/18/20 6:25 am, Prasanta Sadhukhan wrote:
> Hi All,
> 
> Please review a fix for an issue where this test fails in ubuntu citing " Close mnemonic does not work in [The CDE/Motif Look and Feel - com.sun.java.swing.plaf.motif.MotifLookAndFeel]"
> 
> Issue was in the test where subsequent frame with JInternalFrame were created almost instantaneously after the previous frame's mnemonic was tested. Added a delay and also make sure the frame is created in middle and decorations off to prevent any false clicks at wrong locations since the mouse needs to be moved to the menu for opening the menu which might overlap with ubuntu's top menubar.
> 
> Testing on ubuntu 16, 18.04 and 19.10, windows and mac is green.
> 
> diff -r 889b4191879c test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java
> --- a/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java Mon Mar 16 12:49:08 2020 +0530
> +++ b/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java Wed Mar 18 18:43:37 2020 +0530
> @@ -57,6 +57,7 @@
>  ???????? new Locale("sv"),
>  ???????? new Locale("zh", "CN"),
>  ???? };
>  ???? private static final String[] LOOK_AND_FEELS = {
>  ???????? "Nimbus",
> @@ -87,6 +88,8 @@
>  ???????????? public void run() {
>  ???????????????? frame = new JFrame("Test");
> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> +?????????????? frame.setUndecorated(true);
> +?????????????? frame.setLocationRelativeTo(null);
>  ???????????????? frame.setSize(300, 200);
> 
>  ???????????????? JDesktopPane desktop = new JDesktopPane();
> @@ -132,6 +135,7 @@
>  ???????????????? frame.dispose();
>  ???????????? }
>  ???????? });
> +?????? robot.delay(500);
> 
>  ???? }
> Regards
> Prasanta


-- 
Best regards, Sergey.

From alexey.ivanov at oracle.com  Wed Mar 18 22:24:50 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 18 Mar 2020 22:24:50 +0000
Subject:  RFR 8241078: OOM error parsing HTML with large
 
 Tag text
In-Reply-To: 
References: <6585cb9d-7fa8-3084-1046-7345e0740f75@oracle.com>
 
 <0be3ab0b-8bcb-fe55-62b7-cd01b142ebd0@oracle.com>
 
Message-ID: <0e786021-854a-3ca6-584f-406604ee3fb9@oracle.com>

Hi Prasanta,

Looks good to me too.

On 18/03/2020 21:59, Sergey Bylokhov wrote:
> Looks fine.
>
> On 3/17/20 8:54 pm, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> Test updated
>>
>> http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.1/
>>
>> Regards
>> Prasanta
>> On 17-Mar-20 11:48 PM, Sergey Bylokhov wrote:
>>> HI, Prasanta.
>>>
>>> I suggest to limit memory in the test by the "-mx", otherwise
>>> the test will pass on the systems which has the big amount of memory.
>>> I tested 100G, when it pass.
>>>
>>> On 3/17/20 6:54 am, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue where it is seen that OOM errors 
>>>> generated when parsing HTML files with large 
 tagtext.
>>>>
>>>> This is because of fix done in JDK-8173123 where the entire data 
>>>> array was copied again and again, insteadof the range specified via 
>>>> offset.
>>>>
>>>> Fix is to use the offset in array copying to only copy the range 
>>>> specified
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241078
>>>>
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8241078/webrev.0/
>>>>
>>>> All javax/swing/text/html and javax/swing/text/DefaultStyleDocument 
>>>> jtreg test still pass after this change.
>>>>
>>>> Regards
>>>> Prasanta
-- 
Regards,
Alexey

From alexey.ivanov at oracle.com  Wed Mar 18 22:32:08 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 18 Mar 2020 22:32:08 +0000
Subject:  RFR: 8241229: Problem list
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
In-Reply-To: <5E7298A1.1080305@oracle.com>
References: <5E72926B.2030602@oracle.com>
 <26927618-3e83-d7f8-31e7-5e59eb58465e@oracle.com>
 <5E729581.6030206@oracle.com>
 
 <5E7298A1.1080305@oracle.com>
Message-ID: <4b607831-b778-9d22-7f0e-0163926fa5a3@oracle.com>

Hi Phil,

On 18/03/2020 21:54, Philip Race wrote:
> On 3/18/20, 2:52 PM, Sergey Bylokhov wrote:
>> On 3/18/20 2:41 pm, Philip Race wrote:
>>> That is one possible solution that I mentioned, but I am not sure it is
>>> the right one. Needs investigating by the RE.
>>
>> It is an ok thing, the L&F might be unsupported on some specific
>> platform even if returned in the installed L&F list. Other possible 
>> thing
>> is to skip this exception in the test and move to the next L&F.
>
> Yes, I also mentioned that in the bug description
>
> So can we problem list this today ?

Looks good.


Regards,
Alexey
>
> -phil.
>>
>>>
>>> Meanwhile this is? about the problem list so it does not fail tomorrow.
>>>
>>> -phil.
>>>
>>> On 3/18/20, 2:32 PM, Sergey Bylokhov wrote:
>>>> I guess that bug easy to fix, just need to add headful keyword to 
>>>> the test.
>>>>
>>>> On 3/18/20 2:28 pm, Philip Race wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241229
>>>>>
>>>>> We only need to problem list on linux & solaris :
>>>>>
>>>>>
>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>>>>> --- a/test/jdk/ProblemList.txt
>>>>> +++ b/test/jdk/ProblemList.txt
>>>>> @@ -808,6 +808,7 @@
>>>>> javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 
>>>>> macosx-all
>>>>> ? javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
>>>>> ? javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 
>>>>> macosx-all
>>>>> +jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 
>>>>> 8241228 linux-all,solaris-all
>>>>> ? javax/swing/UITest/UITest.java 8198392 generic-all
>>>>> javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 
>>>>> 8198394 generic-all
>>>>> ? javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 
>>>>> generic-all
>>>>>
>>>>> -phil
>>>>
>>>>
>>
>>


From Sergey.Bylokhov at oracle.com  Wed Mar 18 22:37:00 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 18 Mar 2020 15:37:00 -0700
Subject:  RFR: 8241229: Problem list
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
In-Reply-To: <5E7298A1.1080305@oracle.com>
References: <5E72926B.2030602@oracle.com>
 <26927618-3e83-d7f8-31e7-5e59eb58465e@oracle.com>
 <5E729581.6030206@oracle.com>
 
 <5E7298A1.1080305@oracle.com>
Message-ID: <6b708b5b-c944-2061-cecf-2b2ae1713429@oracle.com>

On 3/18/20 2:54 pm, Philip Race wrote:
> 
> 
> On 3/18/20, 2:52 PM, Sergey Bylokhov wrote:
>> On 3/18/20 2:41 pm, Philip Race wrote:
>>> That is one possible solution that I mentioned, but I am not sure it is
>>> the right one. Needs investigating by the RE.
>>
>> It is an ok thing, the L&F might be unsupported on some specific
>> platform even if returned in the installed L&F list. Other possible thing
>> is to skip this exception in the test and move to the next L&F.
> 
> Yes, I also mentioned that in the bug description
> 
> So can we problem list this today ?

ok.

> 
> -phil.
>>
>>>
>>> Meanwhile this is? about the problem list so it does not fail tomorrow.
>>>
>>> -phil.
>>>
>>> On 3/18/20, 2:32 PM, Sergey Bylokhov wrote:
>>>> I guess that bug easy to fix, just need to add headful keyword to the test.
>>>>
>>>> On 3/18/20 2:28 pm, Philip Race wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241229
>>>>>
>>>>> We only need to problem list on linux & solaris :
>>>>>
>>>>>
>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>>>>> --- a/test/jdk/ProblemList.txt
>>>>> +++ b/test/jdk/ProblemList.txt
>>>>> @@ -808,6 +808,7 @@
>>>>> ? javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 macosx-all
>>>>> ? javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
>>>>> ? javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 macosx-all
>>>>> +jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 linux-all,solaris-all
>>>>> ? javax/swing/UITest/UITest.java 8198392 generic-all
>>>>> ? javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 8198394 generic-all
>>>>> ? javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 generic-all
>>>>>
>>>>> -phil
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Mar 19 01:39:36 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 18 Mar 2020 18:39:36 -0700
Subject:  RFR: 8241233 Typo in problem listing of
	UIDefaultKeySizeTest.java
Message-ID: <5E72CD58.3090707@oracle.com>

This is a bit of an oops but the fix 
https://bugs.openjdk.java.net/browse/JDK-8241229
included the "jdk/" parent directory in the path name of the file to be 
excluded.

bug: https://bugs.openjdk.java.net/browse/JDK-8241233

fix:
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -808,7 +808,7 @@
  javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 
macosx-all
  javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
  javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 macosx-all
-jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 
linux-all,solaris-all
+javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 
linux-all,solaris-all
  javax/swing/UITest/UITest.java 8198392 generic-all
  javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 8198394 
generic-all
  javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 
generic-all

-phil.

From JAYATHIRTH.D.V at ORACLE.COM  Thu Mar 19 02:37:45 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Thu, 19 Mar 2020 08:07:45 +0530
Subject:  RFR: 8241233 Typo in problem listing of
 UIDefaultKeySizeTest.java
In-Reply-To: <5E72CD58.3090707@oracle.com>
References: <5E72CD58.3090707@oracle.com>
Message-ID: 

Looks good to me.

Thanks,
Jay

> On 19-Mar-2020, at 7:09 AM, Philip Race  wrote:
> 
> This is a bit of an oops but the fix https://bugs.openjdk.java.net/browse/JDK-8241229
> included the "jdk/" parent directory in the path name of the file to be excluded.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8241233
> 
> fix:
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -808,7 +808,7 @@
> javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java 8238085 macosx-all
> javax/swing/MultiUIDefaults/Test6860438.java 8198391 generic-all
> javax/swing/MultiUIDefaults/4300666/bug4300666.java 7105119 macosx-all
> -jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 linux-all,solaris-all
> +javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java 8241228 linux-all,solaris-all
> javax/swing/UITest/UITest.java 8198392 generic-all
> javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java 8198394 generic-all
> javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java 8198395 generic-all
> 
> -phil.


From prasanta.sadhukhan at oracle.com  Thu Mar 19 17:41:14 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 19 Mar 2020 23:11:14 +0530
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
Message-ID: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>

Hi All,

Please review a fix for a jck issue where the test 
javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html is 
seen to fail after JDK-8241078 fix.

Issue was because the JCK test expects ElementSpec.getArray() to return 
the same text as sent to ElementSpec constructor and the above fix uses 
"offset" to copy the text instead of the full text.

Fix is to copy the full text into ElementSpec.data and store the correct 
offset.

It fixes the JCK issue and also 8241078 regression testcase. All JCK 
javax_swing/text/DefaultStyledDocument/ testcases pass after this fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8241291

webrev: http://cr.openjdk.java.net/~psadhukhan/8241291/webrev.0/

Regards
Prasanta

From philip.race at oracle.com  Thu Mar 19 18:30:27 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 19 Mar 2020 11:30:27 -0700
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
Message-ID: <5E73BA43.9020002@oracle.com>

   49         int lengthes[] = { 0, 1, 10 };
   50         int offs[] = { 0, 1, 6 };
   51         String text = "The text"


lengths not lengthes

I am a bit surprised, or puzzled, or maybe not understanding how
it is legal to specify text of length 8, but offsets + lengths which
would exceed that. I presume the implementation is robust against this.
But why did you pick those values ?

-phil



On 3/19/20, 10:41 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for a jck issue where the test 
> javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html is 
> seen to fail after JDK-8241078 fix.
>
> Issue was because the JCK test expects ElementSpec.getArray() to 
> return the same text as sent to ElementSpec constructor and the above 
> fix uses "offset" to copy the text instead of the full text.
>
> Fix is to copy the full text into ElementSpec.data and store the 
> correct offset.
>
> It fixes the JCK issue and also 8241078 regression testcase. All JCK 
> javax_swing/text/DefaultStyledDocument/ testcases pass after this fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241291
>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8241291/webrev.0/
>
> Regards
> Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Fri Mar 20 00:52:35 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 19 Mar 2020 17:52:35 -0700
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
Message-ID: <52539829-bdcd-09bd-967e-594a0b16c5b7@oracle.com>

> Fix is to copy the full text into ElementSpec.data and store the correct offset.
> 
> It fixes the JCK issue and also 8241078 regression testcase. All JCK javax_swing/text/DefaultStyledDocument/ testcases pass after this fix.

But this will break JDK-8173123, isn't it?

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Fri Mar 20 03:12:24 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 20 Mar 2020 08:42:24 +0530
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <5E73BA43.9020002@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
 <5E73BA43.9020002@oracle.com>
Message-ID: <4a5d4150-711a-266a-c864-2df069a700df@oracle.com>


On 20-Mar-20 12:00 AM, Philip Race wrote:
>    49         int lengthes[] = { 0, 1, 10 };
>    50         int offs[] = { 0, 1, 6 };
>    51         String text = "The text"
> lengths not lengthes
>
> I am a bit surprised, or puzzled, or maybe not understanding how
> it is legal to specify text of length 8, but offsets + lengths which
> would exceed that. I presume the implementation is robust against this.
> But why did you pick those values ?

These are the values used in the jck tests so I reused that.

Regards
Prasanta
> -phil
>
>
> On 3/19/20, 10:41 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for a jck issue where the test 
>> javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html is 
>> seen to fail after JDK-8241078 fix.
>>
>> Issue was because the JCK test expects ElementSpec.getArray() to 
>> return the same text as sent to ElementSpec constructor and the above 
>> fix uses "offset" to copy the text instead of the full text.
>>
>> Fix is to copy the full text into ElementSpec.data and store the 
>> correct offset.
>>
>> It fixes the JCK issue and also 8241078 regression testcase. All JCK 
>> javax_swing/text/DefaultStyledDocument/ testcases pass after this fix.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241291
>>
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8241291/webrev.0/
>>
>> Regards
>> Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prasanta.sadhukhan at oracle.com  Fri Mar 20 03:15:16 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 20 Mar 2020 08:45:16 +0530
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <52539829-bdcd-09bd-967e-594a0b16c5b7@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
 <52539829-bdcd-09bd-967e-594a0b16c5b7@oracle.com>
Message-ID: <6a516237-17e7-3cc8-ab2a-272bbac2998e@oracle.com>

Not exactly. We are still copying the internal data before exposing to 
the user/external world in ElementSpec.getArray() so user does not get 
hold of our internal data structures.

Regards
Prasanta
On 20-Mar-20 6:22 AM, Sergey Bylokhov wrote:
>> Fix is to copy the full text into ElementSpec.data and store the 
>> correct offset.
>>
>> It fixes the JCK issue and also 8241078 regression testcase. All JCK 
>> javax_swing/text/DefaultStyledDocument/ testcases pass after this fix.
>
> But this will break JDK-8173123, isn't it?
>

From Sergey.Bylokhov at oracle.com  Fri Mar 20 04:57:43 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 19 Mar 2020 21:57:43 -0700
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <6a516237-17e7-3cc8-ab2a-272bbac2998e@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
 <52539829-bdcd-09bd-967e-594a0b16c5b7@oracle.com>
 <6a516237-17e7-3cc8-ab2a-272bbac2998e@oracle.com>
Message-ID: <39071db1-44aa-3ffa-dc50-7e5eba652260@oracle.com>

On 3/19/20 8:15 pm, Prasanta Sadhukhan wrote:
> Not exactly. We are still copying the internal data before exposing to the user/external world in ElementSpec.getArray() so user does not get hold of our internal data structures.

It will be possible to modify the array after passing to the constructor so the "get" method will return different results per call.

> 
> Regards
> Prasanta
> On 20-Mar-20 6:22 AM, Sergey Bylokhov wrote:
>>> Fix is to copy the full text into ElementSpec.data and store the correct offset.
>>>
>>> It fixes the JCK issue and also 8241078 regression testcase. All JCK javax_swing/text/DefaultStyledDocument/ testcases pass after this fix.
>>
>> But this will break JDK-8173123, isn't it?
>>


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Fri Mar 20 08:45:38 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 20 Mar 2020 14:15:38 +0530
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <39071db1-44aa-3ffa-dc50-7e5eba652260@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
 <52539829-bdcd-09bd-967e-594a0b16c5b7@oracle.com>
 <6a516237-17e7-3cc8-ab2a-272bbac2998e@oracle.com>
 <39071db1-44aa-3ffa-dc50-7e5eba652260@oracle.com>
Message-ID: <2c36e0c2-f315-1a40-cfea-f2ddba2dea0c@oracle.com>

Yes, logically it's possible. I am not sure how in that case, we can 
cater to both OOM and JCK issue so backing out the fix

http://cr.openjdk.java.net/~psadhukhan/8241291/webrev.1/

I am not sure if JCK test is testing correctly, as the check it has is

 ?int lengthes[] = { 0, 1, 10 };
 ??????? int offs[] = { 0, 1, 6 };
 ??????? String text = "The text";
 ??????? for (int i = 0; i < types.length; i++) {
 ??????????? for (int j = 0; j < lengthes.length; j++) {
 ??????????????? for (int k = 0; k < offs.length; k++) {
 ??????????????????? es = new DefaultStyledDocument.ElementSpec(a, 
types[i], text.toCharArray(),
 ??????????????????????????? offs[k], lengthes[j]);
 ??????????????????? if (!(es != null && es.getLength() == lengthes[j]
 ??????????????????????????? && es.getType() == types[i] 
&&*es.getOffset() *>= 0
 ??????????????????????????? &&*text.equals(new String(es.getArray()))*
 ??????????????????????????? && es.getAttributes() == a)) {

so it does not take into account the offset that is passed to 
constructor, so even if I store 0 (and not 1, 6 as shown in 2nd and 3rd 
offset) as offset in ElementSpec constructor (and dont return the passed 
offset) the jck test pass. I guess it should test es.getOffset == offs[k]

Also, getArray() expects the full text irrespective of offset it pass to 
ElementSpec.constructor, so if offset is 1, I believe we should store 
"he text" in ElementSpec.data (in which case OOM fix would have been 
fine) but JCK still expects "The text"

Regards
Prasanta
On 20-Mar-20 10:27 AM, Sergey Bylokhov wrote:
> On 3/19/20 8:15 pm, Prasanta Sadhukhan wrote:
>> Not exactly. We are still copying the internal data before exposing 
>> to the user/external world in ElementSpec.getArray() so user does not 
>> get hold of our internal data structures.
>
> It will be possible to modify the array after passing to the 
> constructor so the "get" method will return different results per call.
>
>>
>> Regards
>> Prasanta
>> On 20-Mar-20 6:22 AM, Sergey Bylokhov wrote:
>>>> Fix is to copy the full text into ElementSpec.data and store the 
>>>> correct offset.
>>>>
>>>> It fixes the JCK issue and also 8241078 regression testcase. All 
>>>> JCK javax_swing/text/DefaultStyledDocument/ testcases pass after 
>>>> this fix.
>>>
>>> But this will break JDK-8173123, isn't it?
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sitnikov.vladimir at gmail.com  Fri Mar 20 12:06:01 2020
From: sitnikov.vladimir at gmail.com (Vladimir Sitnikov)
Date: Fri, 20 Mar 2020 15:06:01 +0300
Subject:  Editable combobox vs LaF change:
	javax.swing.plaf.UIResource vs
	javax.swing.plaf.basic.BasicComboBoxEditor.UIResource
Message-ID: 

Hi,

I'm facing an issue that the editor for an editable combo box resets its
border as LaF changes.
It results in "textfield with border inside combobox" which looks weird.

Here are the screenshots of how it looks:
https://github.com/weisJ/darklaf/issues/104

While I analyzing the issue, I found an interesting code in the OpenJDK.

https://github.com/openjdk/jdk/blob/6dffcf753301385a5eeb869276967234126e509c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java#L155

    static class BorderlessTextField extends JTextField {
...
        public void setBorder(Border b) {
            if (!(b instanceof UIResource)) {
                super.setBorder(b);
            }
        }

Even though it looks OK, it is using **wrong** UIResource.
I think the author was supposed to use javax.swing.plaf.UIResource,
however, in practice the code is comparing the instance of
javax.swing.plaf.basic.BasicComboBoxEditor.UIResource
which is a simple class defined at the end of the file:

    public static class UIResource extends BasicComboBoxEditor
    implements javax.swing.plaf.UIResource {
    }

I think BorderlessTextField#setBorder should be updated to read if (!(b
instanceof javax.swing.plaf.UIResource)).

Any thoughts on that?

Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alexey.ivanov at oracle.com  Fri Mar 20 17:41:40 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 20 Mar 2020 17:41:40 +0000
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <2c36e0c2-f315-1a40-cfea-f2ddba2dea0c@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
 <52539829-bdcd-09bd-967e-594a0b16c5b7@oracle.com>
 <6a516237-17e7-3cc8-ab2a-272bbac2998e@oracle.com>
 <39071db1-44aa-3ffa-dc50-7e5eba652260@oracle.com>
 <2c36e0c2-f315-1a40-cfea-f2ddba2dea0c@oracle.com>
Message-ID: 

On 20/03/2020 08:45, Prasanta Sadhukhan wrote:
>
> Yes, logically it's possible. I am not sure how in that case, we can 
> cater to both OOM and JCK issue so backing out the fix
>
> http://cr.openjdk.java.net/~psadhukhan/8241291/webrev.1/
>
> I am not sure if JCK test is testing correctly, as the check it has is
>
> ?int lengthes[] = { 0, 1, 10 };
> ??????? int offs[] = { 0, 1, 6 };
> ??????? String text = "The text";
> ??????? for (int i = 0; i < types.length; i++) {
> ??????????? for (int j = 0; j < lengthes.length; j++) {
> ??????????????? for (int k = 0; k < offs.length; k++) {
> ??????????????????? es = new DefaultStyledDocument.ElementSpec(a, 
> types[i], text.toCharArray(),
> ??????????????????????????? offs[k], lengthes[j]);
> ??????????????????? if (!(es != null && es.getLength() == lengthes[j]
> ??????????????????????????? && es.getType() == types[i] 
> &&*es.getOffset() *>= 0
> ??????????????????????????? &&*text.equals(new String(es.getArray()))*
> ??????????????????????????? && es.getAttributes() == a)) {
>
> so it does not take into account the offset that is passed to 
> constructor, so even if I store 0 (and not 1, 6 as shown in 2nd and 
> 3rd offset) as offset in ElementSpec constructor (and dont return the 
> passed offset) the jck test pass. I guess it should test es.getOffset 
> == offs[k]
>
> Also, getArray() expects the full text irrespective of offset it pass 
> to ElementSpec.constructor, so if offset is 1, I believe we should 
> store "he text" in ElementSpec.data (in which case OOM fix would have 
> been fine) but JCK still expects "The text"
>

I agree, the JCK test should not expect the entire array to be returned. 
However, the test was correct: the ElementSpec didn't copy the chars but 
store the reference. (The test could be stricter in comparing the 
references of the passed array.)

Shall we submit a bug against JCK?


Is it a problem to store the reference to char array in ElementSpec? As 
far as I understand, ElementSpec is a short-lived object that is used to 
construct Element tree for a styled document, or an HTML document; the 
text stored in ElementSpec usually comes from a parser. As soon as the 
changes to the (HTML)Document (structure) are processed, the text is 
copied into the document itself.

If ElementSpec is long-lived object, we should copy the array, or the 
part of it; if it's a temporary object, we can store the array reference 
(as it was done before JDK-8173123). I strongly believe it's the latter. 
If the array content is changed, the ?stored? text in the ElementSpec 
object is also changed, which shouldn't be a problem because the 
ElementSpec object is not used after the spec it carries is incorporated 
into the Document.


Regards,
Alexey

> Regards
> Prasanta
> On 20-Mar-20 10:27 AM, Sergey Bylokhov wrote:
>> On 3/19/20 8:15 pm, Prasanta Sadhukhan wrote:
>>> Not exactly. We are still copying the internal data before exposing 
>>> to the user/external world in ElementSpec.getArray() so user does 
>>> not get hold of our internal data structures.
>>
>> It will be possible to modify the array after passing to the 
>> constructor so the "get" method will return different results per call.
>>
>>>
>>> Regards
>>> Prasanta
>>> On 20-Mar-20 6:22 AM, Sergey Bylokhov wrote:
>>>>> Fix is to copy the full text into ElementSpec.data and store the 
>>>>> correct offset.
>>>>>
>>>>> It fixes the JCK issue and also 8241078 regression testcase. All 
>>>>> JCK javax_swing/text/DefaultStyledDocument/ testcases pass after 
>>>>> this fix.
>>>>
>>>> But this will break JDK-8173123, isn't it?
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alexey.ivanov at oracle.com  Fri Mar 20 17:50:30 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 20 Mar 2020 17:50:30 +0000
Subject:  Editable combobox vs LaF change:
 javax.swing.plaf.UIResource vs
 javax.swing.plaf.basic.BasicComboBoxEditor.UIResource
In-Reply-To: 
References: 
Message-ID: 

Hi Vladimir,

Thank you for your report, could you please submit the bug here:
https://bugs.java.com/bugdatabase

We would greatly appreciate if you could provide a test case.


Regards,
Alexey

On 20/03/2020 12:06, Vladimir Sitnikov wrote:
> Hi,
>
> I'm facing an issue that the editor for an editable combo box resets 
> its border as LaF changes.
> It results in "textfield with border inside combobox" which looks weird.
>
> Here are the screenshots of how it looks: 
> https://github.com/weisJ/darklaf/issues/104
>
> While I analyzing the issue, I found an interesting?code in the OpenJDK.
>
> https://github.com/openjdk/jdk/blob/6dffcf753301385a5eeb869276967234126e509c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java#L155
>
> ? ? static class BorderlessTextField extends JTextField {
> ...
> ? ? ? ? public void setBorder(Border b) {
> ? ? ? ? ? ? if (!(b instanceof UIResource)) {
> ? ? ? ? ? ? ? ? super.setBorder(b);
> ? ? ? ? ? ? }
> ? ? ? ? }
>
> Even though it looks OK, it is using **wrong**?UIResource.
> I think the author was supposed to use?javax.swing.plaf.UIResource, 
> however, in practice the code is comparing the instance of
> javax.swing.plaf.basic.BasicComboBoxEditor.UIResource
> which is a simple class defined at the end of the file:
>
> ? ? public static class UIResource extends BasicComboBoxEditor
> ? ? implements javax.swing.plaf.UIResource {
> ? ? }
>
> I think BorderlessTextField#setBorder should be updated to read?if 
> (!(b instanceof javax.swing.plaf.UIResource)).
>
> Any thoughts on that?
>
> Vladimir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From philip.race at oracle.com  Fri Mar 20 17:56:27 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 20 Mar 2020 10:56:27 -0700
Subject:  RFR JDK-8241291: JCK test
 javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
In-Reply-To: <2c36e0c2-f315-1a40-cfea-f2ddba2dea0c@oracle.com>
References: <782921ba-59ae-b64b-6aa8-193ff6eff51f@oracle.com>
 <52539829-bdcd-09bd-967e-594a0b16c5b7@oracle.com>
 <6a516237-17e7-3cc8-ab2a-272bbac2998e@oracle.com>
 <39071db1-44aa-3ffa-dc50-7e5eba652260@oracle.com>
 <2c36e0c2-f315-1a40-cfea-f2ddba2dea0c@oracle.com>
Message-ID: <5E7503CB.8090802@oracle.com>

Clearly we need to fix the test failure ASAP and it seems the fastest way
to do that is to back out the change that caused the failure especially 
since the issue
being fixed is not critical and then reconsider all the issues raised 
with more time.

So +1 to the change below. One reviewer is enough for such a backout so 
go ahead.

-phil.

On 3/20/20, 1:45 AM, Prasanta Sadhukhan wrote:
>
> Yes, logically it's possible. I am not sure how in that case, we can 
> cater to both OOM and JCK issue so backing out the fix
>
> http://cr.openjdk.java.net/~psadhukhan/8241291/webrev.1/
>

From prasanta.sadhukhan at oracle.com  Sat Mar 21 05:07:18 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 21 Mar 2020 10:37:18 +0530
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken in
	JDK 11
Message-ID: 

Hi All,

Please review a fix for a mac issue where it is seen that Unified 
toolbar or textured background enabled by "apple.awt.brushMetalLook" is 
not working.

Issue is because of the fact that with migration to new SDK by 
JDK-8205424, the flags used to specify textured background for NSWindow 
is deprecated and we did not update the code with new flag.

Fix is to use new flags as specified by apple doc.

Bug: https://bugs.openjdk.java.net/browse/JDK-8240995

webrev: http://cr.openjdk.java.net/~psadhukhan/8240995/webrev.0/

Regards
Prasanta

From Sergey.Bylokhov at oracle.com  Sat Mar 21 22:47:51 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 21 Mar 2020 15:47:51 -0700
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken
 in JDK 11
In-Reply-To: 
References: 
Message-ID: <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>

Hi, Prasanta.

> Issue is because of the fact that with migration to new SDK by JDK-8205424, the flags used to specify textured background for NSWindow is deprecated and we did not update the code with new flag.>> Fix is to use new flags as specified by apple doc
Are you sure that the new flag is a replacement of "NSTexturedBackgroundWindowMask"?
I think that this new flag is a replacement of "NSFullSizeContentViewWindowMask" which is
also used in the AWTWindow:

209         if (IS(styleBits, FULL_WINDOW_CONTENT))  type |= NSFullSizeContentViewWindowMask;

I guess the old property "NSTexturedBackgroundWindowMask" should be replaced by the
"NSWindowStyleMaskTexturedBackground" but it is also deprecated since 10.14:

============================================
http://codeworkshop.net/objc-diff/sdkdiffs/macos/10.14/AppKit.html

Modified NSWindowStyleMaskTexturedBackground
	Availability	Deprecation Message
From	Available	none
To	Deprecated	Textured window style should no longer be used
============================================

So it looks like we already do our best, and should recommend everybody to not use the "Textured window style".

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Sun Mar 22 04:07:54 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sun, 22 Mar 2020 09:37:54 +0530
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken
 in JDK 11
In-Reply-To: <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>
References: 
 <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>
Message-ID: <94C0FBE8-318C-4C95-BABB-A1F9C9081DF3@oracle.com>

I knew that NSTexturedBackgroundMask is replaced with NSWindowStyleMaskTexturedBackground and I tried that but it did not work. But it seems we used to get an warning when it was deprecated "

WARNING: Textured window  is getting an implicitly transparent titlebar. This will break when linking against newer SDKs. Use NSWindow's -titlebarAppearsTransparent=YES instead."
So, I set that property instead. It was also mentioned in 

https://developer.apple.com/documentation/appkit/nswindow/1419167-titlebarappearstransparent?language=objc 
to set "tilebarAppearsTransparent" this property to YES when NSFullSizeContentViewWindowMask  is also set, so I used that. 

And if you see the output after my fix, it is showing brushMetalLook output correctly, 

Also NSWindow.h that my 10.14.6 has does not say ?textured background should no longer be used?. I am attaching the file

static const NSWindowStyleMask NSTexturedBackgroundWindowMask NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSWindowStyleMaskTexturedBackground", 10.0, 10.12) = NSWindowStyleMaskTexturedBackground;

Regards
Prasanta

> On 22-Mar-2020, at 4:17 AM, Sergey Bylokhov  wrote:
> 
> Hi, Prasanta.
> 
>> Issue is because of the fact that with migration to new SDK by JDK-8205424, the flags used to specify textured background for NSWindow is deprecated and we did not update the code with new flag.>> Fix is to use new flags as specified by apple doc
> Are you sure that the new flag is a replacement of "NSTexturedBackgroundWindowMask"?
> I think that this new flag is a replacement of "NSFullSizeContentViewWindowMask" which is
> also used in the AWTWindow:
> 
> 209         if (IS(styleBits, FULL_WINDOW_CONTENT))  type |= NSFullSizeContentViewWindowMask;
> 
> I guess the old property "NSTexturedBackgroundWindowMask" should be replaced by the
> "NSWindowStyleMaskTexturedBackground" but it is also deprecated since 10.14:
> 
> ============================================
> http://codeworkshop.net/objc-diff/sdkdiffs/macos/10.14/AppKit.html
> 
> Modified NSWindowStyleMaskTexturedBackground
> 	Availability	Deprecation Message
> From	Available	none
> To	Deprecated	Textured window style should no longer be used
> ============================================
> 
> So it looks like we already do our best, and should recommend everybody to not use the "Textured window style".
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSWindow.h
Type: application/octet-stream
Size: 70698 bytes
Desc: not available
URL: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Sun Mar 22 05:05:46 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 21 Mar 2020 22:05:46 -0700
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken
 in JDK 11
In-Reply-To: <94C0FBE8-318C-4C95-BABB-A1F9C9081DF3@oracle.com>
References: 
 <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>
 <94C0FBE8-318C-4C95-BABB-A1F9C9081DF3@oracle.com>
Message-ID: 

On 3/21/20 9:07 pm, Prasanta Sadhukhan wrote:
> And if you see the output after my fix, it is showing brushMetalLook output correctly,

But it is done via "TRANSPARENT_TITLE_BAR" and "FULL_WINDOW_CONTENT" properties
which are already implemented, not via "TEXTURED" property.


> 
> Also NSWindow.h that my 10.14.6 has does not say ?textured background should no longer be used?. I am attaching the file
> 
> static const NSWindowStyleMask NSTexturedBackgroundWindowMask NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSWindowStyleMaskTexturedBackground", 10.0, 10.12) = NSWindowStyleMaskTexturedBackground;
> 
> Regards
> Prasanta
> 
>> On 22-Mar-2020, at 4:17 AM, Sergey Bylokhov > wrote:
>>
>> Hi, Prasanta.
>>
>>> Issue is because of the fact that with migration to new SDK by JDK-8205424, the flags used to specify textured background for NSWindow is deprecated and we did not update the code with new flag.>> Fix is to use new flags as specified by apple doc
>> Are you sure that the new flag is a replacement of "NSTexturedBackgroundWindowMask"?
>> I think that this new flag is a replacement of "NSFullSizeContentViewWindowMask" which is
>> also used in the AWTWindow:
>>
>> 209 ????????if (IS(styleBits, FULL_WINDOW_CONTENT)) ?type |= NSFullSizeContentViewWindowMask;
>>
>> I guess the old property "NSTexturedBackgroundWindowMask" should be replaced by the
>> "NSWindowStyleMaskTexturedBackground" but it is also deprecated since 10.14:
>>
>> ============================================
>> http://codeworkshop.net/objc-diff/sdkdiffs/macos/10.14/AppKit.html
>>
>> Modified NSWindowStyleMaskTexturedBackground
>> AvailabilityDeprecation Message
>> FromAvailablenone
>> ToDeprecatedTextured window style should no longer be used
>> ============================================
>>
>> So it looks like we already do our best, and should recommend everybody to not use the "Textured window style".
>>
>> -- 
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Sun Mar 22 05:31:48 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sun, 22 Mar 2020 11:01:48 +0530
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken
 in JDK 11
In-Reply-To: 
References: 
 <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>
 <94C0FBE8-318C-4C95-BABB-A1F9C9081DF3@oracle.com>
 
Message-ID: <3465ddf0-25f5-3d60-67db-cc8223a2f124@oracle.com>


On 22-Mar-20 10:35 AM, Sergey Bylokhov wrote:
> On 3/21/20 9:07 pm, Prasanta Sadhukhan wrote:
>> And if you see the output after my fix, it is showing brushMetalLook 
>> output correctly,
>
> But it is done via "TRANSPARENT_TITLE_BAR" and "FULL_WINDOW_CONTENT" 
> properties
> which are already implemented, not via "TEXTURED" property.
>
Yes, but that is what was asked by the warning message to do for this 
support, no? and also the regression test is passing which is testing 
the textured frame after the fix!!
>
>>
>> Also NSWindow.h that my 10.14.6 has does not say ?textured background 
>> should no longer be used?. I am attaching the file
>>
>> static const NSWindowStyleMask NSTexturedBackgroundWindowMask 
>> NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSWindowStyleMaskTexturedBackground", 
>> 10.0, 10.12) = NSWindowStyleMaskTexturedBackground;
>>
>> Regards
>> Prasanta
>>
>>> On 22-Mar-2020, at 4:17 AM, Sergey Bylokhov 
>>> > wrote:
>>>
>>> Hi, Prasanta.
>>>
>>>> Issue is because of the fact that with migration to new SDK by 
>>>> JDK-8205424, the flags used to specify textured background for 
>>>> NSWindow is deprecated and we did not update the code with new 
>>>> flag.>> Fix is to use new flags as specified by apple doc
>>> Are you sure that the new flag is a replacement of 
>>> "NSTexturedBackgroundWindowMask"?
>>> I think that this new flag is a replacement of 
>>> "NSFullSizeContentViewWindowMask" which is
>>> also used in the AWTWindow:
>>>
>>> 209 ????????if (IS(styleBits, FULL_WINDOW_CONTENT)) ?type |= 
>>> NSFullSizeContentViewWindowMask;
>>>
>>> I guess the old property "NSTexturedBackgroundWindowMask" should be 
>>> replaced by the
>>> "NSWindowStyleMaskTexturedBackground" but it is also deprecated 
>>> since 10.14:
>>>
>>> ============================================
>>> http://codeworkshop.net/objc-diff/sdkdiffs/macos/10.14/AppKit.html
>>>
>>> Modified NSWindowStyleMaskTexturedBackground
>>> AvailabilityDeprecation Message
>>> FromAvailablenone
>>> ToDeprecatedTextured window style should no longer be used
>>> ============================================
>>>
>>> So it looks like we already do our best, and should recommend 
>>> everybody to not use the "Textured window style".
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>

From Sergey.Bylokhov at oracle.com  Sun Mar 22 06:23:45 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 21 Mar 2020 23:23:45 -0700
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken
 in JDK 11
In-Reply-To: <3465ddf0-25f5-3d60-67db-cc8223a2f124@oracle.com>
References: 
 <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>
 <94C0FBE8-318C-4C95-BABB-A1F9C9081DF3@oracle.com>
 
 <3465ddf0-25f5-3d60-67db-cc8223a2f124@oracle.com>
Message-ID: 

On 3/21/20 10:31 pm, Prasanta Sadhukhan wrote:
> 
> On 22-Mar-20 10:35 AM, Sergey Bylokhov wrote:
>> On 3/21/20 9:07 pm, Prasanta Sadhukhan wrote:
>>> And if you see the output after my fix, it is showing brushMetalLook output correctly,
>>
>> But it is done via "TRANSPARENT_TITLE_BAR" and "FULL_WINDOW_CONTENT" properties
>> which are already implemented, not via "TEXTURED" property.
>>
> Yes, but that is what was asked by the warning message to do for this support, no?

All these properties are mapped directly to some native macOS styles.
As far as I understand the Apple deprecate the textured property(+it
stop working) and replaced it by something else, it means the apps
which use the old property should start to use the new one.

Not sure that we should go beyond, and support something which is
unsupported by the Apple itself.

and also the regression test is passing which is testing the textured frame after the fix!!

The test was created to check how textured nswindow works, so it is
expected to fail since the props does not work. After the fix it will
check different properties which are checked by this test already:
jdk/java/awt/Window/FullWindowContentTest/FullWindowContentTest.java

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Sun Mar 22 06:29:06 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sun, 22 Mar 2020 11:59:06 +0530
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken
 in JDK 11
In-Reply-To: 
References: 
 <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>
 <94C0FBE8-318C-4C95-BABB-A1F9C9081DF3@oracle.com>
 
 <3465ddf0-25f5-3d60-67db-cc8223a2f124@oracle.com>
 
Message-ID: 

ok. I will close the bug as "Wont fix"

On 22-Mar-20 11:53 AM, Sergey Bylokhov wrote:
> On 3/21/20 10:31 pm, Prasanta Sadhukhan wrote:
>>
>> On 22-Mar-20 10:35 AM, Sergey Bylokhov wrote:
>>> On 3/21/20 9:07 pm, Prasanta Sadhukhan wrote:
>>>> And if you see the output after my fix, it is showing 
>>>> brushMetalLook output correctly,
>>>
>>> But it is done via "TRANSPARENT_TITLE_BAR" and "FULL_WINDOW_CONTENT" 
>>> properties
>>> which are already implemented, not via "TEXTURED" property.
>>>
>> Yes, but that is what was asked by the warning message to do for this 
>> support, no?
>
> All these properties are mapped directly to some native macOS styles.
> As far as I understand the Apple deprecate the textured property(+it
> stop working) and replaced it by something else, it means the apps
> which use the old property should start to use the new one.
>
> Not sure that we should go beyond, and support something which is
> unsupported by the Apple itself.
>
> and also the regression test is passing which is testing the textured 
> frame after the fix!!
>
> The test was created to check how textured nswindow works, so it is
> expected to fail since the props does not work. After the fix it will
> check different properties which are checked by this test already:
> jdk/java/awt/Window/FullWindowContentTest/FullWindowContentTest.java
>

From prasanta.sadhukhan at oracle.com  Sun Mar 22 06:50:02 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sun, 22 Mar 2020 12:20:02 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
Message-ID: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>

Hi All,

Since Textured JFrame property is not supported anymore by Apple, the test which is failing from osx10.14 onwards should be ignored from now onwards

diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
--- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java	Thu Mar 19 22:22:39 2020 -0700
+++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java	Sun Mar 22 12:17:37 2020 +0530
@@ -31,7 +31,7 @@
 import jdk.test.lib.Platform;
 
 /**
- * @test
+ * @ignore
  * @key headful
  * @bug 7124513
  * @requires (os.family == "mac?)

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pankaj.b.bansal at oracle.com  Mon Mar 23 05:13:23 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Sun, 22 Mar 2020 22:13:23 -0700 (PDT)
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
Message-ID: 

Hello Prasanta,

?

If I am not wrong, now this test will be ignored on all versions of osx and since it is only meant for Mac, basically this will never be run after this change. Can?t we just delete the test?

?

Regards,

Pankaj

?

From: Prasanta Sadhukhan 
Sent: Sunday, March 22, 2020 12:20 PM
To: swing-dev at openjdk.java.net
Subject:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

?

Hi All,

?

Since Textured JFrame property is not supported anymore by Apple, the test which is failing from osx10.14 onwards should be ignored from now onwards

?

diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

--- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java????????? Thu Mar 19 22:22:39 2020 -0700

+++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java?????? Sun Mar 22 12:17:37 2020 +0530

@@ -31,7 +31,7 @@

?import jdk.test.lib.Platform;

?

?/**

- * @test

+ * @ignore

? * @key headful

? * @bug 7124513

? * @requires (os.family == "mac?)





Regards

Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prasanta.sadhukhan at oracle.com  Mon Mar 23 05:23:55 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 23 Mar 2020 10:53:55 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
Message-ID: 

I prefer it not to be deleted as we can still use it as standalone mode 
for version lesser than 10.14 in case we need to test something on those 
versions for textured JFrame.

Regards
Prasanta
On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:
>
> Hello Prasanta,
>
> If I am not wrong, now this test will be ignored on all versions of 
> osx and since it is only meant for Mac, basically this will never be 
> run after this change. Can?t we just delete the test?
>
> Regards,
>
> Pankaj
>
> *From:*Prasanta Sadhukhan
> *Sent:* Sunday, March 22, 2020 12:20 PM
> *To:* swing-dev at openjdk.java.net
> *Subject:*  RFR JDK-8239312 [macos] 
> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>
> Hi All,
>
> Since Textured JFrame property is not supported anymore by Apple, the 
> test which is failing from osx10.14 onwards should be ignored from now 
> onwards
>
> diff -r 20374b37dd01 
> test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>
> --- 
> a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaThu 
> Mar 19 22:22:39 2020 -0700
>
> +++ 
> b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaSun 
> Mar 22 12:17:37 2020 +0530
>
> @@ -31,7 +31,7 @@
>
> ?import jdk.test.lib.Platform;
>
> ?/**
>
> - * @test
>
> + * @ignore
>
> * @key headful
>
> * @bug 7124513
>
> * @requires (os.family == "mac?)
>
>
>
> Regards
>
> Prasanta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pankaj.b.bansal at oracle.com  Mon Mar 23 05:25:11 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Sun, 22 Mar 2020 22:25:11 -0700 (PDT)
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
Message-ID: 

Ok, looks good to me.

?

-Pankaj

?

From: Prasanta Sadhukhan 
Sent: Monday, March 23, 2020 10:54 AM
To: Pankaj Bansal ; swing-dev at openjdk.java.net
Subject: Re:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

?

I prefer it not to be deleted as we can still use it as standalone mode for version lesser than 10.14 in case we need to test something on those versions for textured JFrame.

Regards
Prasanta

On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:

Hello Prasanta,

?

If I am not wrong, now this test will be ignored on all versions of osx and since it is only meant for Mac, basically this will never be run after this change. Can?t we just delete the test?

?

Regards,

Pankaj

?

From: Prasanta Sadhukhan 
Sent: Sunday, March 22, 2020 12:20 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

?

Hi All,

?

Since Textured JFrame property is not supported anymore by Apple, the test which is failing from osx10.14 onwards should be ignored from now onwards

?

diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

--- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java????????? Thu Mar 19 22:22:39 2020 -0700

+++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java?????? Sun Mar 22 12:17:37 2020 +0530

@@ -31,7 +31,7 @@

?import jdk.test.lib.Platform;

?

?/**

- * @test

+ * @ignore

? * @key headful

? * @bug 7124513

? * @requires (os.family == "mac?)






Regards

Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Mon Mar 23 06:20:27 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 22 Mar 2020 23:20:27 -0700
Subject:  RFR: 8238719 [macOS] Delete the property which use
 deprecated prefix "com.apple.macos."
Message-ID: 

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8238719
CSR: https://bugs.openjdk.java.net/browse/JDK-8238722
Fix: http://cr.openjdk.java.net/~serb/8238719/webrev.00

The "com.apple.macos." prefix for the "useScreenMenuBar" property
was deprecated a long time ago, even before the macOS port was
integrated to the OpenJDK 7.

if this property is used the next message is printed to the "err":

   "com.apple.macos.useScreenMenuBar has been deprecated. Please switch to apple.laf.useScreenMenuBar"

The earliest message about deprecation which I found was in 2006.
Its time to delete it.

-- 
Best regards, Sergey.

From JAYATHIRTH.D.V at ORACLE.COM  Mon Mar 23 06:28:50 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Mon, 23 Mar 2020 11:58:50 +0530
Subject:  RFR: 8238719 [macOS] Delete the property which use
 deprecated prefix "com.apple.macos."
In-Reply-To: 
References: 
Message-ID: <8F68031D-44BA-4FEE-8F7F-2FFAE4961813@ORACLE.COM>

Change looks good to me.

Thanks,
Jay

> On 23-Mar-2020, at 11:50 AM, Sergey Bylokhov  wrote:
> 
> Hello.
> Please review the fix for jdk/client.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238719
> CSR: https://bugs.openjdk.java.net/browse/JDK-8238722
> Fix: http://cr.openjdk.java.net/~serb/8238719/webrev.00
> 
> The "com.apple.macos." prefix for the "useScreenMenuBar" property
> was deprecated a long time ago, even before the macOS port was
> integrated to the OpenJDK 7.
> 
> if this property is used the next message is printed to the "err":
> 
>  "com.apple.macos.useScreenMenuBar has been deprecated. Please switch to apple.laf.useScreenMenuBar"
> 
> The earliest message about deprecation which I found was in 2006.
> Its time to delete it.
> 
> -- 
> Best regards, Sergey.


From ajit.ghaisas at oracle.com  Mon Mar 23 06:51:59 2020
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Sun, 22 Mar 2020 23:51:59 -0700 (PDT)
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
Message-ID: <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>

Instead of ignoring it on all versions of osx, can we configure it NOT to run on osx 10.14 onwards? 

?

From: Pankaj Bansal 
Sent: Monday, March 23, 2020 10:55 AM
To: Prasanta Sadhukhan ; swing-dev at openjdk.java.net
Subject: Re:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

?

Ok, looks good to me.

?

-Pankaj

?

From: Prasanta Sadhukhan 
Sent: Monday, March 23, 2020 10:54 AM
To: Pankaj Bansal ; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

?

I prefer it not to be deleted as we can still use it as standalone mode for version lesser than 10.14 in case we need to test something on those versions for textured JFrame.

Regards
Prasanta

On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:

Hello Prasanta,

?

If I am not wrong, now this test will be ignored on all versions of osx and since it is only meant for Mac, basically this will never be run after this change. Can?t we just delete the test?

?

Regards,

Pankaj

?

From: Prasanta Sadhukhan 
Sent: Sunday, March 22, 2020 12:20 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

?

Hi All,

?

Since Textured JFrame property is not supported anymore by Apple, the test which is failing from osx10.14 onwards should be ignored from now onwards

?

diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

--- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java????????? Thu Mar 19 22:22:39 2020 -0700

+++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java?????? Sun Mar 22 12:17:37 2020 +0530

@@ -31,7 +31,7 @@

?import jdk.test.lib.Platform;

?

?/**

- * @test

+ * @ignore

? * @key headful

? * @bug 7124513

? * @requires (os.family == "mac?)





Regards

Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prasanta.sadhukhan at oracle.com  Mon Mar 23 07:34:33 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 23 Mar 2020 13:04:33 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
Message-ID: 

we at present do have easy way to test for osx version, unlike windows 
through OSInfo class. I will like to hear from Sergey if that is needed 
for this test (as he was the author) before trying to write such code 
myself.

Regards
Prasanta
On 23-Mar-20 12:21 PM, Ajit Ghaisas wrote:
>
> Instead of ignoring it on all versions of osx, can we configure it NOT 
> to run on osx 10.14 onwards?
>
> *From:*Pankaj Bansal
> *Sent:* Monday, March 23, 2020 10:55 AM
> *To:* Prasanta Sadhukhan ; 
> swing-dev at openjdk.java.net
> *Subject:* Re:  RFR JDK-8239312 [macos] 
> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>
> Ok, looks good to me.
>
> -Pankaj
>
> *From:*Prasanta Sadhukhan
> *Sent:* Monday, March 23, 2020 10:54 AM
> *To:* Pankaj Bansal  >; swing-dev at openjdk.java.net 
> 
> *Subject:* Re:  RFR JDK-8239312 [macos] 
> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>
> I prefer it not to be deleted as we can still use it as standalone 
> mode for version lesser than 10.14 in case we need to test something 
> on those versions for textured JFrame.
>
> Regards
> Prasanta
>
> On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:
>
>     Hello Prasanta,
>
>     If I am not wrong, now this test will be ignored on all versions
>     of osx and since it is only meant for Mac, basically this will
>     never be run after this change. Can?t we just delete the test?
>
>     Regards,
>
>     Pankaj
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Sunday, March 22, 2020 12:20 PM
>     *To:* swing-dev at openjdk.java.net 
>     *Subject:*  RFR JDK-8239312 [macos]
>     javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>
>     Hi All,
>
>     Since Textured JFrame property is not supported anymore by Apple,
>     the test which is failing from osx10.14 onwards should be ignored
>     from now onwards
>
>     diff -r 20374b37dd01
>     test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>
>     ---
>     a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaThu
>     Mar 19 22:22:39 2020 -0700
>
>     +++
>     b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaSun
>     Mar 22 12:17:37 2020 +0530
>
>     @@ -31,7 +31,7 @@
>
>     ?import jdk.test.lib.Platform;
>
>     ?/**
>
>     - * @test
>
>     + * @ignore
>
>     * @key headful
>
>     * @bug 7124513
>
>     * @requires (os.family == "mac?)
>
>
>
>     Regards
>
>     Prasanta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prasanta.sadhukhan at oracle.com  Mon Mar 23 08:10:07 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 23 Mar 2020 13:40:07 +0530
Subject:  RFR: 8238719 [macOS] Delete the property which use
 deprecated prefix "com.apple.macos."
In-Reply-To: 
References: 
Message-ID: <062ccaa7-d597-598b-f84b-feda4ad23877@oracle.com>

Hi Sergey,

How about setting apple.laf.useScreenMenuBar to true even if the 
customer sets com.apple.macos.useScreenMenuBar in order to not 
inconvenience user who was using that property. With the message 
removed, there is now no way to know that is deprecated...

Regards
Prasanta
On 23-Mar-20 11:50 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238719
> CSR: https://bugs.openjdk.java.net/browse/JDK-8238722
> Fix: http://cr.openjdk.java.net/~serb/8238719/webrev.00
>
> The "com.apple.macos." prefix for the "useScreenMenuBar" property
> was deprecated a long time ago, even before the macOS port was
> integrated to the OpenJDK 7.
>
> if this property is used the next message is printed to the "err":
>
> ? "com.apple.macos.useScreenMenuBar has been deprecated. Please switch 
> to apple.laf.useScreenMenuBar"
>
> The earliest message about deprecation which I found was in 2006.
> Its time to delete it.
>

From ajit.ghaisas at oracle.com  Mon Mar 23 09:18:43 2020
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Mon, 23 Mar 2020 14:48:43 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
Message-ID: 

OK.
If we decide to add the check, this might help - test/jdk/java/nio/file/etc/MacVolumesTest.java.

Regards,
Ajit

> On 23-Mar-2020, at 1:04 PM, Prasanta Sadhukhan  wrote:
> 
> we at present do have easy way to test for osx version, unlike windows through OSInfo class. I will like to hear from Sergey if that is needed for this test (as he was the author) before trying to write such code myself.
> 
> Regards
> Prasanta
> On 23-Mar-20 12:21 PM, Ajit Ghaisas wrote:
>> Instead of ignoring it on all versions of osx, can we configure it NOT to run on osx 10.14 onwards? 
>>  
>> From: Pankaj Bansal 
>> Sent: Monday, March 23, 2020 10:55 AM
>> To: Prasanta Sadhukhan  ; swing-dev at openjdk.java.net 
>> Subject: Re:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>  
>> Ok, looks good to me.
>>  
>> -Pankaj
>>  
>> From: Prasanta Sadhukhan 
>> Sent: Monday, March 23, 2020 10:54 AM
>> To: Pankaj Bansal >; swing-dev at openjdk.java.net 
>> Subject: Re:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>  
>> I prefer it not to be deleted as we can still use it as standalone mode for version lesser than 10.14 in case we need to test something on those versions for textured JFrame.
>> 
>> Regards
>> Prasanta
>> On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:
>> Hello Prasanta,
>>  
>> If I am not wrong, now this test will be ignored on all versions of osx and since it is only meant for Mac, basically this will never be run after this change. Can?t we just delete the test?
>>  
>> Regards,
>> Pankaj
>>  
>> From: Prasanta Sadhukhan 
>> Sent: Sunday, March 22, 2020 12:20 PM
>> To: swing-dev at openjdk.java.net 
>> Subject:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>  
>> Hi All,
>>  
>> Since Textured JFrame property is not supported anymore by Apple, the test which is failing from osx10.14 onwards should be ignored from now onwards
>>  
>> diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>> --- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java          Thu Mar 19 22:22:39 2020 -0700
>> +++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java       Sun Mar 22 12:17:37 2020 +0530
>> @@ -31,7 +31,7 @@
>>  import jdk.test.lib.Platform;
>>  
>>  /**
>> - * @test
>> + * @ignore
>>   * @key headful
>>   * @bug 7124513
>>   * @requires (os.family == "mac?)
>> 
>> 
>> 
>> Regards
>> Prasanta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Mon Mar 23 09:22:58 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Mar 2020 02:22:58 -0700
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
Message-ID: 

On 3/22/20 11:51 pm, Ajit Ghaisas wrote:
> Instead of ignoring it on all versions of osx, can we configure it NOT to run on osx 10.14 onwards?

I think that the problem is not directly related to the OS where
we run the test, but to the SDK which we use to build jdk.

Does the current test works fine on 10.13?

> 
> *From:*Pankaj Bansal
> *Sent:* Monday, March 23, 2020 10:55 AM
> *To:* Prasanta Sadhukhan ; swing-dev at openjdk.java.net
> *Subject:* Re:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
> 
> Ok, looks good to me.
> 
> -Pankaj
> 
> *From:*Prasanta Sadhukhan
> *Sent:* Monday, March 23, 2020 10:54 AM
> *To:* Pankaj Bansal >; swing-dev at openjdk.java.net 
> *Subject:* Re:  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
> 
> I prefer it not to be deleted as we can still use it as standalone mode for version lesser than 10.14 in case we need to test something on those versions for textured JFrame.
> 
> Regards
> Prasanta
> 
> On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:
> 
>     Hello Prasanta,
> 
>     If I am not wrong, now this test will be ignored on all versions of osx and since it is only meant for Mac, basically this will never be run after this change. Can?t we just delete the test?
> 
>     Regards,
> 
>     Pankaj
> 
>     *From:*Prasanta Sadhukhan
>     *Sent:* Sunday, March 22, 2020 12:20 PM
>     *To:* swing-dev at openjdk.java.net 
>     *Subject:*  RFR JDK-8239312 [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
> 
>     Hi All,
> 
>     Since Textured JFrame property is not supported anymore by Apple, the test which is failing from osx10.14 onwards should be ignored from now onwards
> 
>     diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
> 
>     --- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaThu Mar 19 22:22:39 2020 -0700
> 
>     +++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaSun Mar 22 12:17:37 2020 +0530
> 
>     @@ -31,7 +31,7 @@
> 
>      ?import jdk.test.lib.Platform;
> 
>      ?/**
> 
>     - * @test
> 
>     + * @ignore
> 
>      ? * @key headful
> 
>      ? * @bug 7124513
> 
>      ? * @requires (os.family == "mac?)
> 
> 
> 
>     Regards
> 
>     Prasanta
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Mon Mar 23 09:52:57 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 23 Mar 2020 15:22:57 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
Message-ID: 


On 23-Mar-20 2:52 PM, Sergey Bylokhov wrote:
> On 3/22/20 11:51 pm, Ajit Ghaisas wrote:
>> Instead of ignoring it on all versions of osx, can we configure it 
>> NOT to run on osx 10.14 onwards?
>
> I think that the problem is not directly related to the OS where
> we run the test, but to the SDK which we use to build jdk.
>
> Does the current test works fine on 10.13?
>
Yes, it was already mentioned in the JBS.
>>
>> *From:*Pankaj Bansal
>> *Sent:* Monday, March 23, 2020 10:55 AM
>> *To:* Prasanta Sadhukhan ; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re:  RFR JDK-8239312 [macos] 
>> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>
>> Ok, looks good to me.
>>
>> -Pankaj
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Monday, March 23, 2020 10:54 AM
>> *To:* Pankaj Bansal > >; swing-dev at openjdk.java.net 
>> 
>> *Subject:* Re:  RFR JDK-8239312 [macos] 
>> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>
>> I prefer it not to be deleted as we can still use it as standalone 
>> mode for version lesser than 10.14 in case we need to test something 
>> on those versions for textured JFrame.
>>
>> Regards
>> Prasanta
>>
>> On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:
>>
>> ??? Hello Prasanta,
>>
>> ??? If I am not wrong, now this test will be ignored on all versions 
>> of osx and since it is only meant for Mac, basically this will never 
>> be run after this change. Can?t we just delete the test?
>>
>> ??? Regards,
>>
>> ??? Pankaj
>>
>> ??? *From:*Prasanta Sadhukhan
>> ??? *Sent:* Sunday, March 22, 2020 12:20 PM
>> ??? *To:* swing-dev at openjdk.java.net 
>> ??? *Subject:*  RFR JDK-8239312 [macos] 
>> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>
>> ??? Hi All,
>>
>> ??? Since Textured JFrame property is not supported anymore by Apple, 
>> the test which is failing from osx10.14 onwards should be ignored 
>> from now onwards
>>
>> ??? diff -r 20374b37dd01 
>> test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>
>> ??? --- 
>> a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaThu 
>> Mar 19 22:22:39 2020 -0700
>>
>> ??? +++ 
>> b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaSun 
>> Mar 22 12:17:37 2020 +0530
>>
>> ??? @@ -31,7 +31,7 @@
>>
>> ???? ?import jdk.test.lib.Platform;
>>
>> ???? ?/**
>>
>> ??? - * @test
>>
>> ??? + * @ignore
>>
>> ???? ? * @key headful
>>
>> ???? ? * @bug 7124513
>>
>> ???? ? * @requires (os.family == "mac?)
>>
>>
>>
>> ??? Regards
>>
>> ??? Prasanta
>>
>
>

From prasanta.sadhukhan at oracle.com  Mon Mar 23 10:00:06 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 23 Mar 2020 15:30:06 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
Message-ID: <3b65cd88-1d7f-ac95-d3f7-700095e797b2@oracle.com>

Thanks. I had thought of another way of using 
ProcessBuilder("system_profiler", "SPSoftwareDataType") but this one 
seems to be easier.

Regards
Prasanta
On 23-Mar-20 2:48 PM, Ajit Ghaisas wrote:
> OK.
> If we decide to add the check, this might help - 
> test/jdk/java/nio/file/etc/MacVolumesTest.java.
>
> Regards,
> Ajit
>
>> On 23-Mar-2020, at 1:04 PM, Prasanta Sadhukhan 
>> > > wrote:
>>
>> we at present do have easy way to test for osx version, unlike 
>> windows through OSInfo class. I will like to hear from Sergey if that 
>> is needed for this test (as he was the author) before trying to write 
>> such code myself.
>>
>> Regards
>> Prasanta
>> On 23-Mar-20 12:21 PM, Ajit Ghaisas wrote:
>>> Instead of ignoring it on all versions of osx, can we configure it 
>>> NOT to run on osx 10.14 onwards?
>>> *From:*Pankaj Bansal
>>> *Sent:*Monday, March 23, 2020 10:55 AM
>>> *To:*Prasanta 
>>> Sadhukhan;swing-dev at openjdk.java.net
>>> *Subject:*Re:  RFR JDK-8239312 [macos] 
>>> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>> Ok, looks good to me.
>>> -Pankaj
>>> *From:*Prasanta Sadhukhan
>>> *Sent:*Monday, March 23, 2020 10:54 AM
>>> *To:*Pankaj Bansal >> >;swing-dev at openjdk.java.net 
>>> 
>>> *Subject:*Re:  RFR JDK-8239312 [macos] 
>>> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>>
>>> I prefer it not to be deleted as we can still use it as standalone 
>>> mode for version lesser than 10.14 in case we need to test something 
>>> on those versions for textured JFrame.
>>>
>>> Regards
>>> Prasanta
>>> On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:
>>>
>>>     Hello Prasanta,
>>>     If I am not wrong, now this test will be ignored on all versions
>>>     of osx and since it is only meant for Mac, basically this will
>>>     never be run after this change. Can?t we just delete the test?
>>>     Regards,
>>>     Pankaj
>>>     *From:*Prasanta Sadhukhan
>>>     *Sent:*Sunday, March 22, 2020 12:20 PM
>>>     *To:*swing-dev at openjdk.java.net 
>>>     *Subject:* RFR JDK-8239312 [macos]
>>>     javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>>     Hi All,
>>>     Since Textured JFrame property is not supported anymore by
>>>     Apple, the test which is failing from osx10.14 onwards should be
>>>     ignored from now onwards
>>>     diff -r 20374b37dd01
>>>     test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>>     ---
>>>     a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaThu
>>>     Mar 19 22:22:39 2020 -0700
>>>     +++
>>>     b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaSun
>>>     Mar 22 12:17:37 2020 +0530
>>>     @@ -31,7 +31,7 @@
>>>     ?import jdk.test.lib.Platform;
>>>     ?/**
>>>     - * @test
>>>     + * @ignore
>>>     * @key headful
>>>     * @bug 7124513
>>>     * @requires (os.family == "mac?)
>>>
>>>
>>>
>>>     Regards
>>>     Prasanta
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Mon Mar 23 10:03:02 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Mar 2020 03:03:02 -0700
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
Message-ID: <0f589ed7-2c51-8f0d-237c-776c39764534@oracle.com>

On 3/23/20 2:52 am, Prasanta Sadhukhan wrote:
> 
> On 23-Mar-20 2:52 PM, Sergey Bylokhov wrote:
>> On 3/22/20 11:51 pm, Ajit Ghaisas wrote:
>>> Instead of ignoring it on all versions of osx, can we configure it NOT to run on osx 10.14 onwards?
>>
>> I think that the problem is not directly related to the OS where
>> we run the test, but to the SDK which we use to build jdk.
>>
>> Does the current test works fine on 10.13?
>>
> Yes, it was already mentioned in the JBS.

Then it would be useful to run it on macOS 10.13.

BTW probably we should file the bug to the Apple?

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Mon Mar 23 10:26:46 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 23 Mar 2020 15:56:46 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <0f589ed7-2c51-8f0d-237c-776c39764534@oracle.com>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
 <0f589ed7-2c51-8f0d-237c-776c39764534@oracle.com>
Message-ID: <3115167B-EAF0-4607-9E3D-08EE47002DFB@oracle.com>



> On 23-Mar-2020, at 3:33 PM, Sergey Bylokhov  wrote:
> 
> On 3/23/20 2:52 am, Prasanta Sadhukhan wrote:
>> On 23-Mar-20 2:52 PM, Sergey Bylokhov wrote:
>>> On 3/22/20 11:51 pm, Ajit Ghaisas wrote:
>>>> Instead of ignoring it on all versions of osx, can we configure it NOT to run on osx 10.14 onwards?
>>> 
>>> I think that the problem is not directly related to the OS where
>>> we run the test, but to the SDK which we use to build jdk.
>>> 
>>> Does the current test works fine on 10.13?
>>> 
>> Yes, it was already mentioned in the JBS.
> 
> Then it would be useful to run it on macOS 10.13.
> 
OK. Updated diff
diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
--- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java	Thu Mar 19 22:22:39 2020 -0700
+++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java	Mon Mar 23 15:55:22 2020 +0530
@@ -57,6 +57,12 @@
             System.out.println("This test is for OSX, considered passed.");
             return;
         }
+        String[] osv = System.getProperty("os.version").split("\\.");
+        int minor = Integer.valueOf(osv[1]);
+        if (minor >= 14) {
+            System.out.println("Test should be ignored from osx 10.14 onwards");
+            return;
+        }
> BTW probably we should file the bug to the Apple?
> 
But we already established in 8240995 that Apple has decided not to support Textured Frame from osx10.14 onwards, right?

Regards
Prasanta
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Mon Mar 23 18:14:52 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Mar 2020 11:14:52 -0700
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
Message-ID: 

On 3/23/20 2:52 am, Prasanta Sadhukhan wrote:
> 
> On 23-Mar-20 2:52 PM, Sergey Bylokhov wrote:
>> On 3/22/20 11:51 pm, Ajit Ghaisas wrote:
>>> Instead of ignoring it on all versions of osx, can we configure it NOT to run on osx 10.14 onwards?
>>
>> I think that the problem is not directly related to the OS where
>> we run the test, but to the SDK which we use to build jdk.
>>
>> Does the current test works fine on 10.13?
>>
> Yes, it was already mentioned in the JBS.

Actually that was a surprise to me and I decided to check it deeper.

Are you sure that the failure of the test is related to the reported bug? I cannot
check macOS 10.13, but on macOS 10.14+ the reason of the failure is that the gradient
background(dark appearance) of the frame when these options are specified are
different(the test expected it to be the same). However the test confirms that the
colors are still different when these property set/unset. The test cannot check the case
from the bug becaouse it uses undecorated window. Looks like it is a separate testbug.


I also modified the SwingSet2 to use "apple.awt.brushMetalLook" and confirm that the
unified toolbar works -> the gradient is applied, the toolbar is transparent. The only
problem I see is that the title of frame is visible.

Using the SwingSet2 I also confirm that
"apple.awt.transparentTitleBar=true" + "apple.awt.fullWindowContent=true" are not a
proper replacement of "apple.awt.brushMetalLook". The "apple.awt.fullWindowContent"
cause "wrong" frame layout, because the NSView occupy the whole frame, and content
appears under the title buttons. Also gradient is not applied.

So the conclusion:
  - The NSTexturedJFrame test has a bug and it should be fixed. The expectation that
    the gradient will be the same all the time is incorrect.
  - The "textured background" still works, it uses gradient color. The toolbar
    and frame content are transparent.
  - The bug reported here about visible title of the frame is not a bug in the jdk, but
    a behavior change in macOS sdk, it could be fixed by using "apple.awt.transparentTitleBar=true"
    in the application.


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Mar 24 01:02:06 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Mar 2020 18:02:06 -0700
Subject:  RFR: 8238719 [macOS] Delete the property which use
 deprecated prefix "com.apple.macos."
In-Reply-To: <062ccaa7-d597-598b-f84b-feda4ad23877@oracle.com>
References: 
 <062ccaa7-d597-598b-f84b-feda4ad23877@oracle.com>
Message-ID: 

On 3/23/20 1:10 am, Prasanta Sadhukhan wrote:
> How about setting apple.laf.useScreenMenuBar to true even if the customer sets com.apple.macos.useScreenMenuBar in order to not inconvenience user who was using that property. With the message removed, there is now no way to know that is deprecated...

Did you mean to remove the error message and set the "apple.laf.useScreenMenuBar"
to "true" when "com.apple.macos.useScreenMenuBar" is set?

I guess, without the stderr, it will make an appearance that
"com.apple.macos.useScreenMenuBar" even more supported than before this fix.

This error message was added as part of the deprecation of the property,
the purpose of this fix is to remove the "com.apple.macos."
So the error and property should be there or both removed.

> 
> Regards
> Prasanta
> On 23-Mar-20 11:50 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238719
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238722
>> Fix: http://cr.openjdk.java.net/~serb/8238719/webrev.00
>>
>> The "com.apple.macos." prefix for the "useScreenMenuBar" property
>> was deprecated a long time ago, even before the macOS port was
>> integrated to the OpenJDK 7.
>>
>> if this property is used the next message is printed to the "err":
>>
>> ? "com.apple.macos.useScreenMenuBar has been deprecated. Please switch to apple.laf.useScreenMenuBar"
>>
>> The earliest message about deprecation which I found was in 2006.
>> Its time to delete it.
>>


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Tue Mar 24 04:36:28 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 24 Mar 2020 10:06:28 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
 
Message-ID: <35305d9c-81d8-df4f-3873-e0e3bb6cc01e@oracle.com>


On 23-Mar-20 11:44 PM, Sergey Bylokhov wrote:
> On 3/23/20 2:52 am, Prasanta Sadhukhan wrote:
>>
>> On 23-Mar-20 2:52 PM, Sergey Bylokhov wrote:
>>> On 3/22/20 11:51 pm, Ajit Ghaisas wrote:
>>>> Instead of ignoring it on all versions of osx, can we configure it 
>>>> NOT to run on osx 10.14 onwards?
>>>
>>> I think that the problem is not directly related to the OS where
>>> we run the test, but to the SDK which we use to build jdk.
>>>
>>> Does the current test works fine on 10.13?
>>>
>> Yes, it was already mentioned in the JBS.
>
> Actually that was a surprise to me and I decided to check it deeper.
>
> Are you sure that the failure of the test is related to the reported 
> bug? I cannot
> check macOS 10.13, but on macOS 10.14+ the reason of the failure is 
> that the gradient
> background(dark appearance) of the frame when these options are 
> specified are
> different(the test expected it to be the same). However the test 
> confirms that the
> colors are still different when these property set/unset. The test 
> cannot check the case
> from the bug becaouse it uses undecorated window. Looks like it is a 
> separate testbug.
>
>
> I also modified the SwingSet2 to use "apple.awt.brushMetalLook" and 
> confirm that the
> unified toolbar works -> the gradient is applied, the toolbar is 
> transparent. The only
> problem I see is that the title of frame is visible.
>
> Using the SwingSet2 I also confirm that
> "apple.awt.transparentTitleBar=true" + 
> "apple.awt.fullWindowContent=true" are not a
> proper replacement of "apple.awt.brushMetalLook". The 
> "apple.awt.fullWindowContent"
> cause "wrong" frame layout, because the NSView occupy the whole frame, 
> and content
> appears under the title buttons. Also gradient is not applied.
>
> So the conclusion:
> ?- The NSTexturedJFrame test has a bug and it should be fixed. The 
> expectation that
> ?? the gradient will be the same all the time is incorrect.

I did not get this point. "apple.awt.brushMetalLook" and "window.style" 
both set TEXTURED property of NSWindow so it's gradient should be the 
same, no?

So, at what time do you think they will not be same?

Regards
Prasanta
> ?- The "textured background" still works, it uses gradient color. The 
> toolbar
> ?? and frame content are transparent.
> ?- The bug reported here about visible title of the frame is not a bug 
> in the jdk, but
> ?? a behavior change in macOS sdk, it could be fixed by using 
> "apple.awt.transparentTitleBar=true"
> ?? in the application.
>
>

From prasanta.sadhukhan at oracle.com  Tue Mar 24 04:37:43 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 24 Mar 2020 10:07:43 +0530
Subject:  RFR: 8238719 [macOS] Delete the property which use
 deprecated prefix "com.apple.macos."
In-Reply-To: 
References: 
 <062ccaa7-d597-598b-f84b-feda4ad23877@oracle.com>
 
Message-ID: 


On 24-Mar-20 6:32 AM, Sergey Bylokhov wrote:
> On 3/23/20 1:10 am, Prasanta Sadhukhan wrote:
>> How about setting apple.laf.useScreenMenuBar to true even if the 
>> customer sets com.apple.macos.useScreenMenuBar in order to not 
>> inconvenience user who was using that property. With the message 
>> removed, there is now no way to know that is deprecated...
>
> Did you mean to remove the error message and set the 
> "apple.laf.useScreenMenuBar"
> to "true" when "com.apple.macos.useScreenMenuBar" is set?
>
> I guess, without the stderr, it will make an appearance that
> "com.apple.macos.useScreenMenuBar" even more supported than before 
> this fix.
>
> This error message was added as part of the deprecation of the property,
> the purpose of this fix is to remove the "com.apple.macos."
> So the error and property should be there or both removed.

OK. Fair enough.

Regards
Prasanta
>
>>
>> Regards
>> Prasanta
>> On 23-Mar-20 11:50 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk/client.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238719
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238722
>>> Fix: http://cr.openjdk.java.net/~serb/8238719/webrev.00
>>>
>>> The "com.apple.macos." prefix for the "useScreenMenuBar" property
>>> was deprecated a long time ago, even before the macOS port was
>>> integrated to the OpenJDK 7.
>>>
>>> if this property is used the next message is printed to the "err":
>>>
>>> ? "com.apple.macos.useScreenMenuBar has been deprecated. Please 
>>> switch to apple.laf.useScreenMenuBar"
>>>
>>> The earliest message about deprecation which I found was in 2006.
>>> Its time to delete it.
>>>
>
>

From Sergey.Bylokhov at oracle.com  Tue Mar 24 04:47:06 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Mar 2020 21:47:06 -0700
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <35305d9c-81d8-df4f-3873-e0e3bb6cc01e@oracle.com>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
 
 <35305d9c-81d8-df4f-3873-e0e3bb6cc01e@oracle.com>
Message-ID: <8042eb92-0488-e5cd-287e-18f0bcd91431@oracle.com>

On 3/23/20 9:36 pm, Prasanta Sadhukhan wrote:
> I did not get this point. "apple.awt.brushMetalLook" and "window.style" both set TEXTURED property of NSWindow so it's gradient should be the same, no?
> 
> So, at what time do you think they will not be same?

It seems every time the window becomes visible the background gradient
draws slightly differently(it is drawn by the macOS, not java). It fails
even if the "apple.awt.brushMetalLook" used twice.

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Tue Mar 24 05:04:36 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 24 Mar 2020 10:34:36 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <8042eb92-0488-e5cd-287e-18f0bcd91431@oracle.com>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
 
 <35305d9c-81d8-df4f-3873-e0e3bb6cc01e@oracle.com>
 <8042eb92-0488-e5cd-287e-18f0bcd91431@oracle.com>
Message-ID: 


On 24-Mar-20 10:17 AM, Sergey Bylokhov wrote:
> On 3/23/20 9:36 pm, Prasanta Sadhukhan wrote:
>> I did not get this point. "apple.awt.brushMetalLook" and 
>> "window.style" both set TEXTURED property of NSWindow so it's 
>> gradient should be the same, no?
>>
>> So, at what time do you think they will not be same?
>
> It seems every time the window becomes visible the background gradient
> draws slightly differently(it is drawn by the macOS, not java). It fails
> even if the "apple.awt.brushMetalLook" used twice.
>
There's a 2 sec gap between window being visible and image is captured 
by robot, so if it is momentary macos draw problem, it should not have 
been there as we wait long enough after the window is visible. If it's 
permanent macos draw problem, then do we need to file a bug to apple?

Regards
Prasanta

From philip.race at oracle.com  Tue Mar 24 15:06:06 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 24 Mar 2020 08:06:06 -0700
Subject:  RFR: 8238719 [macOS] Delete the property which use
 deprecated prefix "com.apple.macos."
In-Reply-To: 
References: 
 <062ccaa7-d597-598b-f84b-feda4ad23877@oracle.com>
 
Message-ID: <5E7A21DE.8090105@oracle.com>

I agree.  +1 to the change.
I have updated the CSR text as well as adding a compatibility section and
adding scope and type  and marked it as reviewed so you can move it to 
final.

-phil.

On 3/23/20, 6:02 PM, Sergey Bylokhov wrote:
> On 3/23/20 1:10 am, Prasanta Sadhukhan wrote:
>> How about setting apple.laf.useScreenMenuBar to true even if the 
>> customer sets com.apple.macos.useScreenMenuBar in order to not 
>> inconvenience user who was using that property. With the message 
>> removed, there is now no way to know that is deprecated...
>
> Did you mean to remove the error message and set the 
> "apple.laf.useScreenMenuBar"
> to "true" when "com.apple.macos.useScreenMenuBar" is set?
>
> I guess, without the stderr, it will make an appearance that
> "com.apple.macos.useScreenMenuBar" even more supported than before 
> this fix.
>
> This error message was added as part of the deprecation of the property,
> the purpose of this fix is to remove the "com.apple.macos."
> So the error and property should be there or both removed.
>
>>
>> Regards
>> Prasanta
>> On 23-Mar-20 11:50 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk/client.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238719
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238722
>>> Fix: http://cr.openjdk.java.net/~serb/8238719/webrev.00
>>>
>>> The "com.apple.macos." prefix for the "useScreenMenuBar" property
>>> was deprecated a long time ago, even before the macOS port was
>>> integrated to the OpenJDK 7.
>>>
>>> if this property is used the next message is printed to the "err":
>>>
>>>   "com.apple.macos.useScreenMenuBar has been deprecated. Please 
>>> switch to apple.laf.useScreenMenuBar"
>>>
>>> The earliest message about deprecation which I found was in 2006.
>>> Its time to delete it.
>>>
>
>

From philip.race at oracle.com  Tue Mar 24 16:09:43 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 24 Mar 2020 09:09:43 -0700
Subject:  RFR JDK-8239312 [macos]
	javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
Message-ID: <5E7A30C7.8030801@oracle.com>

I realise this thread has moved on to a more important topic but
I don't understand why it is "difficult" to get the os version

public class V {
public static void main(String[] args) {
  System.out.println(System.getProperty("os.version"));
  }
}

$ java V
10.13.6

On 3/23/20, 2:18 AM, Ajit Ghaisas wrote:
> OK.
> If we decide to add the check, this might help - 
> test/jdk/java/nio/file/etc/MacVolumesTest.java.
>
> Regards,
> Ajit
>
>> On 23-Mar-2020, at 1:04 PM, Prasanta Sadhukhan 
>> > > wrote:
>>
>> we at present do have easy way to test for osx version, unlike 
>> windows through OSInfo class. I will like to hear from Sergey if that 
>> is needed for this test (as he was the author) before trying to write 
>> such code myself.
>>
>> Regards
>> Prasanta
>> On 23-Mar-20 12:21 PM, Ajit Ghaisas wrote:
>>> Instead of ignoring it on all versions of osx, can we configure it 
>>> NOT to run on osx 10.14 onwards?
>>> *From:*Pankaj Bansal
>>> *Sent:*Monday, March 23, 2020 10:55 AM
>>> *To:*Prasanta 
>>> Sadhukhan;swing-dev at openjdk.java.net
>>> *Subject:*Re:  RFR JDK-8239312 [macos] 
>>> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>> Ok, looks good to me.
>>> -Pankaj
>>> *From:*Prasanta Sadhukhan
>>> *Sent:*Monday, March 23, 2020 10:54 AM
>>> *To:*Pankaj Bansal >> >;swing-dev at openjdk.java.net 
>>> 
>>> *Subject:*Re:  RFR JDK-8239312 [macos] 
>>> javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>>
>>> I prefer it not to be deleted as we can still use it as standalone 
>>> mode for version lesser than 10.14 in case we need to test something 
>>> on those versions for textured JFrame.
>>>
>>> Regards
>>> Prasanta
>>> On 23-Mar-20 10:43 AM, Pankaj Bansal wrote:
>>>
>>>     Hello Prasanta,
>>>     If I am not wrong, now this test will be ignored on all versions
>>>     of osx and since it is only meant for Mac, basically this will
>>>     never be run after this change. Can?t we just delete the test?
>>>     Regards,
>>>     Pankaj
>>>     *From:*Prasanta Sadhukhan
>>>     *Sent:*Sunday, March 22, 2020 12:20 PM
>>>     *To:*swing-dev at openjdk.java.net 
>>>     *Subject:* RFR JDK-8239312 [macos]
>>>     javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>>     Hi All,
>>>     Since Textured JFrame property is not supported anymore by
>>>     Apple, the test which is failing from osx10.14 onwards should be
>>>     ignored from now onwards
>>>     diff -r 20374b37dd01
>>>     test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
>>>     ---
>>>     a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaThu
>>>     Mar 19 22:22:39 2020 -0700
>>>     +++
>>>     b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaSun
>>>     Mar 22 12:17:37 2020 +0530
>>>     @@ -31,7 +31,7 @@
>>>      import jdk.test.lib.Platform;
>>>      /**
>>>     - * @test
>>>     + * @ignore
>>>     * @key headful
>>>     * @bug 7124513
>>>     * @requires (os.family == "mac?)
>>>
>>>
>>>
>>>     Regards
>>>     Prasanta
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Tue Mar 24 23:52:18 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 24 Mar 2020 16:52:18 -0700
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: 
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
 
 <35305d9c-81d8-df4f-3873-e0e3bb6cc01e@oracle.com>
 <8042eb92-0488-e5cd-287e-18f0bcd91431@oracle.com>
 
Message-ID: <149dca1e-e89c-cd81-7902-449f8629becd@oracle.com>

On 3/23/20 10:04 pm, Prasanta Sadhukhan wrote:
> 
> On 24-Mar-20 10:17 AM, Sergey Bylokhov wrote:
>> On 3/23/20 9:36 pm, Prasanta Sadhukhan wrote:
>>> I did not get this point. "apple.awt.brushMetalLook" and "window.style" both set TEXTURED property of NSWindow so it's gradient should be the same, no?
>>>
>>> So, at what time do you think they will not be same?
>>
>> It seems every time the window becomes visible the background gradient
>> draws slightly differently(it is drawn by the macOS, not java). It fails
>> even if the "apple.awt.brushMetalLook" used twice.
>>
> There's a 2 sec gap between window being visible and image is captured by robot, so if it is momentary macos draw problem, it should not have been there as we wait long enough after the window is visible. If it's permanent macos draw problem, then do we need to file a bug to apple?

I am not sure this is a bug, it looks like the gradient is generated on the fly,
and it is different every time. But it will be helpful to compare the diff pixel by pixel.


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Mar 25 14:09:35 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 25 Mar 2020 19:39:35 +0530
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <149dca1e-e89c-cd81-7902-449f8629becd@oracle.com>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
 
 <35305d9c-81d8-df4f-3873-e0e3bb6cc01e@oracle.com>
 <8042eb92-0488-e5cd-287e-18f0bcd91431@oracle.com>
 
 <149dca1e-e89c-cd81-7902-449f8629becd@oracle.com>
Message-ID: <00519191-8439-43DF-B05E-6541B405CA63@oracle.com>



> On 25-Mar-2020, at 5:22 AM, Sergey Bylokhov  wrote:
> 
> On 3/23/20 10:04 pm, Prasanta Sadhukhan wrote:
>> On 24-Mar-20 10:17 AM, Sergey Bylokhov wrote:
>>> On 3/23/20 9:36 pm, Prasanta Sadhukhan wrote:
>>>> I did not get this point. "apple.awt.brushMetalLook" and "window.style" both set TEXTURED property of NSWindow so it's gradient should be the same, no?
>>>> 
>>>> So, at what time do you think they will not be same?
>>> 
>>> It seems every time the window becomes visible the background gradient
>>> draws slightly differently(it is drawn by the macOS, not java). It fails
>>> even if the "apple.awt.brushMetalLook" used twice.
>>> 
>> There's a 2 sec gap between window being visible and image is captured by robot, so if it is momentary macos draw problem, it should not have been there as we wait long enough after the window is visible. If it's permanent macos draw problem, then do we need to file a bug to apple?
> 
> I am not sure this is a bug, it looks like the gradient is generated on the fly,
> and it is different every time. But it will be helpful to compare the diff pixel by pixel.
> 
> 
It seems there is a difference of 1 in all the color components 
x 0 y 1 img1.getRGB(x,y) ff9e9e9e img2.getRGB(x,y) ff9f9f9f
 x 0 y 2 img1.getRGB(x,y) ffa2a2a2 img2.getRGB(x,y) ffa1a1a1
 x 1 y 0 img1.getRGB(x,y) fff8f8f8 img2.getRGB(x,y) fff7f7f7
 x 1 y 1 img1.getRGB(x,y) ff9d9d9d img2.getRGB(x,y) ff9e9e9e
 x 2 y 0 img1.getRGB(x,y) fff7f7f7 img2.getRGB(x,y) fff6f6f6
 x 2 y 1 img1.getRGB(x,y) ff9d9d9d img2.getRGB(x,y) ff9e9e9e
 x 2 y 3 img1.getRGB(x,y) ffdadada img2.getRGB(x,y) ffd9d9d9
 x 3 y 0 img1.getRGB(x,y) fff5f5f5 img2.getRGB(x,y) fff6f6f6
 x 3 y 3 img1.getRGB(x,y) ffd9d9d9 img2.getRGB(x,y) ffdadada
 x 4 y 2 img1.getRGB(x,y) ffa1a1a1 img2.getRGB(x,y) ff9f9f9f
 x 5 y 0 img1.getRGB(x,y) fff4f4f4 img2.getRGB(x,y) fff3f3f3
??.
?...

so I added a tolerance check for each color. The test now passes in osx10.14 and without the fix of 7124513, the test fails.

diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
--- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java	Thu Mar 19 22:22:39 2020 -0700
+++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java	Wed Mar 25 19:36:05 2020 +0530
@@ -23,6 +23,7 @@
 
 import java.awt.Rectangle;
 import java.awt.Toolkit;
+import java.awt.Color;
 import java.awt.image.BufferedImage;
 
 import javax.swing.JFrame;
@@ -78,9 +79,16 @@
     private static void testImages(BufferedImage img1, BufferedImage img2,
                                    boolean shouldbeDifferent) {
         boolean different = false;
+        int tol = 5;
         for (int x = 0; x < img1.getWidth(); ++x) {
             for (int y = 0; y < img1.getHeight(); ++y) {
-                if (img1.getRGB(x, y) != img2.getRGB(x, y)) {
+                Color c1 = new Color(img1.getRGB(x, y));
+                Color c2 = new Color(img2.getRGB(x, y));
+		
+                if ((Math.abs(c1.getRed() - c2.getRed()) > tol) &&
+                    (Math.abs(c1.getBlue() - c2.getBlue()) > tol) &&
+                    (Math.abs(c1.getGreen() - c2.getGreen()) > tol )) {
+		    
                     different = true;
                 }
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Wed Mar 25 23:41:48 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 25 Mar 2020 16:41:48 -0700
Subject:  RFR JDK-8239312 [macos]
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
In-Reply-To: <00519191-8439-43DF-B05E-6541B405CA63@oracle.com>
References: <7C24721E-92A8-4F60-A6A7-3D56B951CB97@oracle.com>
 
 
 
 <31d806c7-0e8e-4e83-9218-5b70f2fae6a2@default>
 
 
 
 <35305d9c-81d8-df4f-3873-e0e3bb6cc01e@oracle.com>
 <8042eb92-0488-e5cd-287e-18f0bcd91431@oracle.com>
 
 <149dca1e-e89c-cd81-7902-449f8629becd@oracle.com>
 <00519191-8439-43DF-B05E-6541B405CA63@oracle.com>
Message-ID: <82e42ff6-8cfd-fcd6-8e0b-c206b2713715@oracle.com>

On 3/25/20 7:09 am, Prasanta Sadhukhan wrote:
>>
> It seems there is a difference of 1 in all the color components

ok +1

> x 0 y 1 img1.getRGB(x,y) ff9e9e9e img2.getRGB(x,y) ff9f9f9f
>  ?x 0 y 2 img1.getRGB(x,y) ffa2a2a2 img2.getRGB(x,y) ffa1a1a1
>  ?x 1 y 0 img1.getRGB(x,y) fff8f8f8 img2.getRGB(x,y) fff7f7f7
>  ?x 1 y 1 img1.getRGB(x,y) ff9d9d9d img2.getRGB(x,y) ff9e9e9e
>  ?x 2 y 0 img1.getRGB(x,y) fff7f7f7 img2.getRGB(x,y) fff6f6f6
>  ?x 2 y 1 img1.getRGB(x,y) ff9d9d9d img2.getRGB(x,y) ff9e9e9e
>  ?x 2 y 3 img1.getRGB(x,y) ffdadada img2.getRGB(x,y) ffd9d9d9
>  ?x 3 y 0 img1.getRGB(x,y) fff5f5f5 img2.getRGB(x,y) fff6f6f6
>  ?x 3 y 3 img1.getRGB(x,y) ffd9d9d9 img2.getRGB(x,y) ffdadada
>  ?x 4 y 2 img1.getRGB(x,y) ffa1a1a1 img2.getRGB(x,y) ff9f9f9f
>  ?x 5 y 0 img1.getRGB(x,y) fff4f4f4 img2.getRGB(x,y) fff3f3f3
> ??.
> ?...
> 
> so I added a tolerance check for each color. The test now passes in osx10.14 and without the fix of 7124513, the test fails.
> 
> diff -r 20374b37dd01 test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
> --- a/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaThu Mar 19 22:22:39 2020 -0700
> +++ b/test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.javaWed Mar 25 19:36:05 2020 +0530
> @@ -23,6 +23,7 @@
> 
> 
>  ?import java.awt.Rectangle;
>  ?import java.awt.Toolkit;
> +import java.awt.Color;
>  ?import java.awt.image.BufferedImage;
> 
> 
>  ?import javax.swing.JFrame;
> @@ -78,9 +79,16 @@
>  ?? ? private static void testImages(BufferedImage img1, BufferedImage img2,
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? boolean shouldbeDifferent) {
>  ?? ? ? ? boolean different = false;
> +? ? ? ? int tol = 5;
>  ?? ? ? ? for (int x = 0; x < img1.getWidth(); ++x) {
>  ?? ? ? ? ? ? for (int y = 0; y < img1.getHeight(); ++y) {
> -? ? ? ? ? ? ? ? if (img1.getRGB(x, y) != img2.getRGB(x, y)) {
> +? ? ? ? ? ? ? ? Color c1 = new Color(img1.getRGB(x, y));
> +? ? ? ? ? ? ? ? Color c2 = new Color(img2.getRGB(x, y));
> +
> +? ? ? ? ? ? ? ? if ((Math.abs(c1.getRed() - c2.getRed()) > tol) &&
> +? ? ? ? ? ? ? ? ? ? (Math.abs(c1.getBlue() - c2.getBlue()) > tol) &&
> +? ? ? ? ? ? ? ? ? ? (Math.abs(c1.getGreen() - c2.getGreen()) > tol )) {
> +
>  ?? ? ? ? ? ? ? ? ? ? different = true;
>  ?? ? ? ? ? ? ? ? }
>> -- 
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Fri Mar 27 10:27:46 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 27 Mar 2020 15:57:46 +0530
Subject:  [13] RFR JDK-8213535:Windows HiDPI html lightweight
 tooltips are truncated
In-Reply-To: <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com>
References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com>
 <5C9F6E0B-BBEE-458F-BF6F-0CFE6D0C5D35@oracle.com>
 
 <2b39d545-0f0c-d6da-cfc0-f989a071fe4d@oracle.com>
 <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com>
 <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com>
 
 <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>
 
 
 <2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>
 
 
 <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com>
Message-ID: <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com>


On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote:
> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote:
>>> How other components which may use HTML inside calculates its 
>>> preferred size? I do not remember that they additionally scale the 
>>> values returned by the View.
>>
>> Maybe those components does not use preferredSize calculation as 
>> JTooltip does.
>
> Even if it not used, the preferredSize of the components and views 
> should return correct values.
>
>
getPreferredSize() is called from ToolTipManager but it is done *before 
*calling Tooltip.show() which actually triggers PropertyChangeEvent with 
"graphicsConfiguration" property.

Now, View is updated by calling BasicHTML.updateRenderer() when 
"graphicsConfiguration" property is fired to notify transform is 
changed, so during preferredSize() call, the View has not yet been 
updated with correct transform.

So, my proposed fix is still same

http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Sat Mar 28 03:19:05 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 27 Mar 2020 20:19:05 -0700
Subject:  [13] RFR JDK-8213535:Windows HiDPI html lightweight
 tooltips are truncated
In-Reply-To: <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com>
References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com>
 <5C9F6E0B-BBEE-458F-BF6F-0CFE6D0C5D35@oracle.com>
 
 <2b39d545-0f0c-d6da-cfc0-f989a071fe4d@oracle.com>
 <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com>
 <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com>
 
 <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>
 
 
 <2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>
 
 
 <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com>
 <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com>
Message-ID: <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com>

On 3/27/20 3:27 am, Prasanta Sadhukhan wrote:
> 
> On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote:
>> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote:
>>>> How other components which may use HTML inside calculates its preferred size? I do not remember that they additionally scale the values returned by the View.
>>>
>>> Maybe those components does not use preferredSize calculation as JTooltip does.
>>
>> Even if it not used, the preferredSize of the components and views should return correct values.
>>
>>
> getPreferredSize() is called from ToolTipManager but it is done *before *calling Tooltip.show() which actually triggers PropertyChangeEvent with "graphicsConfiguration" property.
> 
> Now, View is updated by calling BasicHTML.updateRenderer() when "graphicsConfiguration" property is fired to notify transform is changed, so during preferredSize() call, the View has not yet been updated with correct transform.

It means that the View should use GCOnfig of its parent-parent-etc, which is default/main GC if the components/windows are invisible or the GC of the real screen where the component/window is located. Or the size of the tooltip should be revalidated at the moment we found that the preferred size was calculated using the wrong GC.

I think we should do both steps above.


Note that we should never calculate "coordinate_XY * scale" and return this value to the user. The result of "coord*scale" should be only used when we pass the data to the native code, in all other places we should use just plain coordinates in the user's space.

> So, my proposed fix is still same
> 
> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/
> 
> Regards
> Prasanta


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Mar 28 03:46:17 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 27 Mar 2020 20:46:17 -0700
Subject:  RFR JDK-8240995:[macos] Unified toolbar is broken
 in JDK 11
In-Reply-To: 
References: 
 <50c8fd27-3d9c-9880-7481-362c98dfd251@oracle.com>
 <94C0FBE8-318C-4C95-BABB-A1F9C9081DF3@oracle.com>
 
 <3465ddf0-25f5-3d60-67db-cc8223a2f124@oracle.com>
 
 
Message-ID: <0c719ae0-f85f-0289-3408-11d7667978b0@oracle.com>

On 3/21/20 11:29 pm, Prasanta Sadhukhan wrote:
> ok. I will close the bug as "Wont fix"

Note that these TRANSPARENT_TITLE_BAR and FULL_WINDOW_CONTENT are not
present in the jdk11/jdk8, so you probably need to backport some other
fixes.

> 
> On 22-Mar-20 11:53 AM, Sergey Bylokhov wrote:
>> On 3/21/20 10:31 pm, Prasanta Sadhukhan wrote:
>>>
>>> On 22-Mar-20 10:35 AM, Sergey Bylokhov wrote:
>>>> On 3/21/20 9:07 pm, Prasanta Sadhukhan wrote:
>>>>> And if you see the output after my fix, it is showing brushMetalLook output correctly,
>>>>
>>>> But it is done via "TRANSPARENT_TITLE_BAR" and "FULL_WINDOW_CONTENT" properties
>>>> which are already implemented, not via "TEXTURED" property.
>>>>
>>> Yes, but that is what was asked by the warning message to do for this support, no?
>>
>> All these properties are mapped directly to some native macOS styles.
>> As far as I understand the Apple deprecate the textured property(+it
>> stop working) and replaced it by something else, it means the apps
>> which use the old property should start to use the new one.
>>
>> Not sure that we should go beyond, and support something which is
>> unsupported by the Apple itself.
>>
>> and also the regression test is passing which is testing the textured frame after the fix!!
>>
>> The test was created to check how textured nswindow works, so it is
>> expected to fail since the props does not work. After the fix it will
>> check different properties which are checked by this test already:
>> jdk/java/awt/Window/FullWindowContentTest/FullWindowContentTest.java
>>


-- 
Best regards, Sergey.

From tejpal.rebari at oracle.com  Mon Mar 30 05:52:02 2020
From: tejpal.rebari at oracle.com (Tejpal Rebari)
Date: Mon, 30 Mar 2020 11:22:02 +0530
Subject:  RFR: 8241228 Test
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing
Message-ID: 

Hi All,
Please review the following test only fix for jdk15.

Bug : https://bugs.openjdk.java.net/browse/JDK-8241228 
Fix : http://cr.openjdk.java.net/~trebari/swing/8241228/webrev00/ 

Issue : The test UIDefaultKeySizeTest.java is failing in nightly headless 
testing on Solaris and Linux.
It throws javax.swing.UnspportedLookAndFeelException.

Fix : Fix is to catch the UnspportedLookAndFeelException when it is thrown 
by some LookAndFeel and skip for that LookAndFeel.
Also added headful keyword to run test on machines which has all the 
Supported lookAndFeel installed.

Regards
Tejpal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Tue Mar 31 05:44:23 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 30 Mar 2020 22:44:23 -0700
Subject:  RFR: 8241228 Test
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing
In-Reply-To: 
References: 
Message-ID: <524b95bf-d8f5-727d-8f33-303e21254dc8@oracle.com>

Hi, Tejpal.

The fix looks fine, but you need to wait until the fix for JDK-8241491
will not be merged to JDK/client, otherwise, the merge conflict will occur.

On 3/29/20 10:52 pm, Tejpal Rebari wrote:
> Hi All,
> Please review the following test only fix for jdk15.
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8241228
> Fix : http://cr.openjdk.java.net/~trebari/swing/8241228/webrev00/
> 
> Issue : The test?UIDefaultKeySizeTest.java is failing in nightly headless
> testing on Solaris and Linux.
> It throws javax.swing.UnspportedLookAndFeelException.
> 
> Fix : Fix is to catch the UnspportedLookAndFeelException when it is thrown
> by some LookAndFeel and skip for that LookAndFeel.
> Also added headful keyword to run test on machines which has all the
> Supported lookAndFeel installed.
> 
> Regards
> Tejpal
> 


-- 
Best regards, Sergey.

From tejpal.rebari at oracle.com  Tue Mar 31 06:05:21 2020
From: tejpal.rebari at oracle.com (Tejpal Rebari)
Date: Tue, 31 Mar 2020 11:35:21 +0530
Subject:  RFR: 8241228 Test
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing
In-Reply-To: <524b95bf-d8f5-727d-8f33-303e21254dc8@oracle.com>
References: 
 <524b95bf-d8f5-727d-8f33-303e21254dc8@oracle.com>
Message-ID: <7EFC3577-65F8-45D0-A085-A5B0B4EC3220@oracle.com>

Hi Sergey,

> On 31-Mar-2020, at 11:14 AM, Sergey Bylokhov  wrote:
> 
> Hi, Tejpal.
> 
> The fix looks fine, but you need to wait until the fix for JDK-8241491
> will not be merged to JDK/client, otherwise, the merge conflict will occur.


JDK-8241491 is problem listing  the test for aix-all.
I think after the merge we need to remove aix-all from the problemlist as well.

Regards
Tejpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pankaj.b.bansal at oracle.com  Tue Mar 31 07:03:55 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 31 Mar 2020 12:33:55 +0530
Subject:  RFR: 8241228 Test
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing
In-Reply-To: 
References: 
Message-ID: 

Look good to me.


On 30/03/20 11:22 AM, Tejpal Rebari wrote:
> Hi All,
> Please review the following test only fix for jdk15.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8241228
> Fix : http://cr.openjdk.java.net/~trebari/swing/8241228/webrev00/ 
> 
>
> Issue : The test?UIDefaultKeySizeTest.java is failing in nightly headless
> testing on Solaris and Linux.
> It throws javax.swing.UnspportedLookAndFeelException.
>
> Fix : Fix is to catch the UnspportedLookAndFeelException when it is 
> thrown
> by some LookAndFeel and skip for that LookAndFeel.
> Also added headful keyword to run test on machines which has all the
> Supported lookAndFeel installed.
>
> Regards
> Tejpal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prasanta.sadhukhan at oracle.com  Tue Mar 31 07:24:39 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 31 Mar 2020 12:54:39 +0530
Subject:  RFR: 8241228 Test
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing
In-Reply-To: <7EFC3577-65F8-45D0-A085-A5B0B4EC3220@oracle.com>
References: 
 <524b95bf-d8f5-727d-8f33-303e21254dc8@oracle.com>
 <7EFC3577-65F8-45D0-A085-A5B0B4EC3220@oracle.com>
Message-ID: <82efc12f-8738-a100-0143-5cce95531218@oracle.com>

I think for this bug only, you can create a webrev out of jdk/jdk with 
this fix? and an updated problem list removing aix-all and commit that 
in jdk/jdk directly.

Regards
Prasanta
On 31-Mar-20 11:35 AM, Tejpal Rebari wrote:
> Hi Sergey,
>
>> On 31-Mar-2020, at 11:14 AM, Sergey Bylokhov 
>> > wrote:
>>
>> Hi, Tejpal.
>>
>> The fix looks fine, but you need to wait until the fix for JDK-8241491
>> will not be merged to JDK/client, otherwise, the merge conflict will 
>> occur.
>
> JDK-8241491 is problem listing ?the test for aix-all.
> I think after the merge we need to remove aix-all from the problemlist 
> as well.
>
> Regards
> Tejpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prasanta.sadhukhan at oracle.com  Tue Mar 31 08:13:10 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 31 Mar 2020 13:43:10 +0530
Subject:  [13] RFR JDK-8213535:Windows HiDPI html lightweight
 tooltips are truncated
In-Reply-To: <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com>
References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com>
 <5C9F6E0B-BBEE-458F-BF6F-0CFE6D0C5D35@oracle.com>
 
 <2b39d545-0f0c-d6da-cfc0-f989a071fe4d@oracle.com>
 <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com>
 <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com>
 
 <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>
 
 
 <2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>
 
 
 <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com>
 <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com>
 <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com>
Message-ID: 

View is updated by calling BasicHTML.updateRenderer when 
"graphicsConfiguration" property is fired when tooltip is shown via 
tip.show() in ToolTipManager. Now, we should be using the updated 
preferredSize calculated by View.getPreferredSpan but BasicToolTip#paint 
still uses the old size. Proposed fix is to use the updated preferredSize.

http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.2/

Regards
Prasanta
On 28-Mar-20 8:49 AM, Sergey Bylokhov wrote:
> On 3/27/20 3:27 am, Prasanta Sadhukhan wrote:
>>
>> On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote:
>>> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote:
>>>>> How other components which may use HTML inside calculates its 
>>>>> preferred size? I do not remember that they additionally scale the 
>>>>> values returned by the View.
>>>>
>>>> Maybe those components does not use preferredSize calculation as 
>>>> JTooltip does.
>>>
>>> Even if it not used, the preferredSize of the components and views 
>>> should return correct values.
>>>
>>>
>> getPreferredSize() is called from ToolTipManager but it is done 
>> *before *calling Tooltip.show() which actually triggers 
>> PropertyChangeEvent with "graphicsConfiguration" property.
>>
>> Now, View is updated by calling BasicHTML.updateRenderer() when 
>> "graphicsConfiguration" property is fired to notify transform is 
>> changed, so during preferredSize() call, the View has not yet been 
>> updated with correct transform.
>
> It means that the View should use GCOnfig of its parent-parent-etc, 
> which is default/main GC if the components/windows are invisible or 
> the GC of the real screen where the component/window is located. Or 
> the size of the tooltip should be revalidated at the moment we found 
> that the preferred size was calculated using the wrong GC.
>
> I think we should do both steps above.
>
>
> Note that we should never calculate "coordinate_XY * scale" and return 
> this value to the user. The result of "coord*scale" should be only 
> used when we pass the data to the native code, in all other places we 
> should use just plain coordinates in the user's space.
>
>> So, my proposed fix is still same
>>
>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/
>>
>> Regards
>> Prasanta
>
>

From bhawesh.choudhary at oracle.com  Tue Mar 31 09:16:12 2020
From: bhawesh.choudhary at oracle.com (Bhawesh Choudhary)
Date: Tue, 31 Mar 2020 14:46:12 +0530
Subject:  RFR: 8233584: [Win LAF] When navigating the
 contents of the file list changes in Win LAF
In-Reply-To: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com>
References: 
 <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com>
Message-ID: <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com>

Hi,

Please find updated Webrev as per suggestions [Test case updates for 
WindowsLookAndFeel]

JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584
Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/

-Bhawesh

On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote:
> Hi,
>
> Please find updated Webrev as per suggestions [Test name update and 
> Code formatting]
>
> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584
> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/
>
> -Bhawesh
>
> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote:
>> Hi,
>>
>> Please review this fix,
>> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584
>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/
>>
>> Issue:
>> In Windows LookAndFeel, When navigating Combobox's list of 
>> JFileChooser via keys, the contents of JFileChooser changes.
>>
>> Fix:
>> Set flag "JComboBox.isTableCellEditor" to True which prohibits 
>> JCombobox from sending selection change event when JCombobox's list 
>> selection change happens via keys.
>>
>>
>> Verification:
>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as 
>> well as BasicLookAndFeel with keys navigation. also added a test case 
>> to verify the same.
>>
>> Did not find any misbehavior with the fix.
>>
>> Regards
>> Bhawesh
>


From Sergey.Bylokhov at oracle.com  Tue Mar 31 22:24:50 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 31 Mar 2020 15:24:50 -0700
Subject:  RFR: 8233584: [Win LAF] When navigating the
 contents of the file list changes in Win LAF
In-Reply-To: <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com>
References: 
 <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com>
 <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com>
Message-ID: <92020cc2-abf1-785f-5fb3-c7d066a383eb@oracle.com>

Looks fine.

On 3/31/20 2:16 am, Bhawesh Choudhary wrote:
> Hi,
> 
> Please find updated Webrev as per suggestions [Test case updates for WindowsLookAndFeel]
> 
> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584
> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/
> 
> -Bhawesh
> 
> On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote:
>> Hi,
>>
>> Please find updated Webrev as per suggestions [Test name update and Code formatting]
>>
>> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584
>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/
>>
>> -Bhawesh
>>
>> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote:
>>> Hi,
>>>
>>> Please review this fix,
>>> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584
>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/
>>>
>>> Issue:
>>> In Windows LookAndFeel, When navigating Combobox's list of JFileChooser via keys, the contents of JFileChooser changes.
>>>
>>> Fix:
>>> Set flag "JComboBox.isTableCellEditor" to True which prohibits JCombobox from sending selection change event when JCombobox's list selection change happens via keys.
>>>
>>>
>>> Verification:
>>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as well as BasicLookAndFeel with keys navigation. also added a test case to verify the same.
>>>
>>> Did not find any misbehavior with the fix.
>>>
>>> Regards
>>> Bhawesh
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Mar 31 23:41:31 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 31 Mar 2020 16:41:31 -0700
Subject:  [13] RFR JDK-8213535:Windows HiDPI html lightweight
 tooltips are truncated
In-Reply-To: 
References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com>
 <5C9F6E0B-BBEE-458F-BF6F-0CFE6D0C5D35@oracle.com>
 
 <2b39d545-0f0c-d6da-cfc0-f989a071fe4d@oracle.com>
 <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com>
 <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com>
 
 <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>
 
 
 <2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>
 
 
 <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com>
 <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com>
 <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com>
 
Message-ID: <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com>

That looks much better! The only question I have is why the size is not updated - is it intentional behaviour or we can tweak it somehow.

On 3/31/20 1:13 am, Prasanta Sadhukhan wrote:
> View is updated by calling BasicHTML.updateRenderer when "graphicsConfiguration" property is fired when tooltip is shown via tip.show() in ToolTipManager. Now, we should be using the updated preferredSize calculated by View.getPreferredSpan but BasicToolTip#paint still uses the old size. Proposed fix is to use the updated preferredSize.
> 
> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.2/
> 
> Regards
> Prasanta
> On 28-Mar-20 8:49 AM, Sergey Bylokhov wrote:
>> On 3/27/20 3:27 am, Prasanta Sadhukhan wrote:
>>>
>>> On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote:
>>>> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote:
>>>>>> How other components which may use HTML inside calculates its preferred size? I do not remember that they additionally scale the values returned by the View.
>>>>>
>>>>> Maybe those components does not use preferredSize calculation as JTooltip does.
>>>>
>>>> Even if it not used, the preferredSize of the components and views should return correct values.
>>>>
>>>>
>>> getPreferredSize() is called from ToolTipManager but it is done *before *calling Tooltip.show() which actually triggers PropertyChangeEvent with "graphicsConfiguration" property.
>>>
>>> Now, View is updated by calling BasicHTML.updateRenderer() when "graphicsConfiguration" property is fired to notify transform is changed, so during preferredSize() call, the View has not yet been updated with correct transform.
>>
>> It means that the View should use GCOnfig of its parent-parent-etc, which is default/main GC if the components/windows are invisible or the GC of the real screen where the component/window is located. Or the size of the tooltip should be revalidated at the moment we found that the preferred size was calculated using the wrong GC.
>>
>> I think we should do both steps above.
>>
>>
>> Note that we should never calculate "coordinate_XY * scale" and return this value to the user. The result of "coord*scale" should be only used when we pass the data to the native code, in all other places we should use just plain coordinates in the user's space.
>>
>>> So, my proposed fix is still same
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/
>>>
>>> Regards
>>> Prasanta
>>
>>


-- 
Best regards, Sergey.

From kwong at proofpoint.com  Mon Mar 16 17:43:46 2020
From: kwong at proofpoint.com (Kenny Wong)
Date: Mon, 16 Mar 2020 17:43:46 -0000
Subject:  OOM error parsing HTML with large 
 Tag text
In-Reply-To: <9e07bca6-4a88-615d-b0e2-c61b8a7d9823@oracle.com>
References: <8114B407-4158-4FA6-A8EA-52AED7C4BA30@proofpoint.com>
 <9e07bca6-4a88-615d-b0e2-c61b8a7d9823@oracle.com>
Message-ID: <23619218-A154-4897-A0D4-1D24197198B2@proofpoint.com>

Sure, just did:

"We will review your report and have assigned it an internal review ID : 9064026."

?On 3/16/20, 1:30 PM, "Sergey Bylokhov"  wrote:

    Hi, Kenny.
    
    Thank you for your report, can you please file the bug here:
    https://bugs.java.com/bugdatabase