From dingxmin at linux.vnet.ibm.com Thu Nov 1 06:35:54 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 01 Nov 2012 14:35:54 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <508FD85D.6010600@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> Message-ID: <5092184A.2040303@linux.vnet.ibm.com> Hi Alexandr, Thanks for your review. The problem that the JButton does not release itself as you mentioned is, after taking closer look at relevant code again, that I removed instance AbstractButton.Handler as change listener where repainting the button press animation is defined. So this time I get around this issue and here comes v6 patch @ http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ Below are answers to what you have raised in previous email. 1. if ( if (!listener.equals(this)) { that 'this' means the JButtonWrapper instead of an action listener. 'this' refers to JButtonWrapper.this because the closest class definition is JButtonWrapper. I also verified it during my debugging. 2. Why are two FormViews created in this sample? SwingUtilities.updateComponentTreeUI() triggers html View hierarchy to update by instantiating new UI instances involved in the html form. It could have been avoided to have 2 View instances but we are restricted to current design that LF change causes creation of View instance which further leads to creation of new UI instances. Creation of new UI instances upon LF change can be referenced in BasicTextUI.modelChanged(). 3. Why are there 2 listeners added to the button model in this sample? The issue is caused by combination of the 2 factors. First, a shared ButtonModel is created per html Element. Second, JButton.setModel() automatically registers its private Handler in the new model but no way to deregister it. The first is a design choice but the second is a design flaw. Consequence is that the shared ButtonModel instance bears more and more JButton.Handler. I think v6 patch is promising as a final fix. If you have any further concern or comment, please don't hesitate to let me know. Thanks again for your careful review. Best regards, Frank On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: > Hi Frank, > > I tried your V5 patch and run the test described in the issue (see > below). > I pressed the button and it does not release. This is because the > AbstractButton.Handler listener is removed because of the fix. > You could check the line > 941 if (!listener.equals(this)) { > that 'this' means the JButtonWrapper instead of an action listener. > > Could you also look deeper in the code and say why two FormViews are > created (and each adds it's own listener to the button model) in this > sample? > > ----------------------------------------------- > import java.awt.*; > import javax.swing.*; > > public class FormSubmit { > > public static void main(String[] args) throws Exception { > SwingUtilities.invokeAndWait(new Runnable() { > > @Override > public void run() { > > JEditorPane html = new JEditorPane("text/html", > "
value=\"Submit\">
"); > JFrame frame = new JFrame() > frame.setLayout(new BorderLayout()); > frame.add(html, BorderLayout.CENTER); > frame.setSize(200, 100); > frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); > frame.setVisible(true); // Uncomment this line to see > the Exception on JDK 7 > SwingUtilities.updateComponentTreeUI(html); > } > }); > } > } > ----------------------------------------------- > > Thanks, > Alexandr. > > On 10/29/2012 11:48 AM, Frank Ding wrote: >> Hi all, >> Seems Pavel has been busy these days. Is anybody willing to review >> v5 change? >> >> Thanks, >> Frank >> From alexandr.scherbatiy at oracle.com Thu Nov 1 12:08:42 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 01 Nov 2012 16:08:42 +0400 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <5092184A.2040303@linux.vnet.ibm.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> Message-ID: <5092664A.4010504@oracle.com> On 11/1/2012 10:35 AM, Frank Ding wrote: > Hi Alexandr, > Thanks for your review. The problem that the JButton does not > release itself as you mentioned is, after taking closer look at > relevant code again, that I removed instance AbstractButton.Handler as > change listener where repainting the button press animation is > defined. So this time I get around this issue and here comes v6 patch @ > http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ > > Below are answers to what you have raised in previous email. > 1. if ( if (!listener.equals(this)) { that 'this' means the > JButtonWrapper instead of an action listener. > 'this' refers to JButtonWrapper.this because the closest class > definition is JButtonWrapper. I also verified it during my debugging. Could you give an example there this check is useful? It seems that the JButtonWrapper does not implement ActionListener interface and so the listener and the this always should not be equal. I dumped action listeners from the button and model before the fix and after it. Before the fix the button has the latest FormView listener and the model has AbstractButton$Handler added each time after a component input creation. After the fix both the button and the model have the FormView listener and the button does not have the AbstractButton$Handler. Could you preserve the listeners location and just remove old listeners from the model? The fix sets the model to the JButtonWrapper first and than removes unneccessary listeners from the model. Is it possible to rearrange order of these operations? I see that you check number of the listeners in the test. Could you add the check that the action listener is invoked only once after a component tree updating and the action does the same that it does before a component tree updating. Thanks, Alexandr. > > 2. Why are two FormViews created in this sample? > SwingUtilities.updateComponentTreeUI() triggers html View hierarchy to > update by instantiating new UI instances involved in the html form. > It could have been avoided to have 2 View instances but we are > restricted to current design that LF change causes creation of View > instance which further leads to creation of new UI instances. > Creation of new UI instances upon LF change can be referenced in > BasicTextUI.modelChanged(). > > 3. Why are there 2 listeners added to the button model in this sample? > The issue is caused by combination of the 2 factors. First, a shared > ButtonModel is created per html Element. Second, JButton.setModel() > automatically registers its private Handler in the new model but no > way to deregister it. The first is a design choice but the second is > a design flaw. Consequence is that the shared ButtonModel instance > bears more and more JButton.Handler. > > I think v6 patch is promising as a final fix. If you have any further > concern or comment, please don't hesitate to let me know. Thanks again > for your careful review. > > Best regards, > Frank > > On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >> Hi Frank, >> >> I tried your V5 patch and run the test described in the issue (see >> below). >> I pressed the button and it does not release. This is because the >> AbstractButton.Handler listener is removed because of the fix. >> You could check the line >> 941 if (!listener.equals(this)) { >> that 'this' means the JButtonWrapper instead of an action listener. >> >> Could you also look deeper in the code and say why two FormViews are >> created (and each adds it's own listener to the button model) in this >> sample? >> >> ----------------------------------------------- >> import java.awt.*; >> import javax.swing.*; >> >> public class FormSubmit { >> >> public static void main(String[] args) throws Exception { >> SwingUtilities.invokeAndWait(new Runnable() { >> >> @Override >> public void run() { >> >> JEditorPane html = new JEditorPane("text/html", >> "
> type=\"submit\" value=\"Submit\">
"); >> JFrame frame = new JFrame() >> frame.setLayout(new BorderLayout()); >> frame.add(html, BorderLayout.CENTER); >> frame.setSize(200, 100); >> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >> frame.setVisible(true); // Uncomment this line to see >> the Exception on JDK 7 >> SwingUtilities.updateComponentTreeUI(html); >> } >> }); >> } >> } >> ----------------------------------------------- >> >> Thanks, >> Alexandr. >> >> On 10/29/2012 11:48 AM, Frank Ding wrote: >>> Hi all, >>> Seems Pavel has been busy these days. Is anybody willing to >>> review v5 change? >>> >>> Thanks, >>> Frank >>> > From alexandr.scherbatiy at oracle.com Thu Nov 1 13:30:13 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 01 Nov 2012 17:30:13 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract Message-ID: <50927965.3030402@oracle.com> Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001423 webrev: http://cr.openjdk.java.net/~alexsch/8001423/webrev.00 The 'equals' method from the SmallAttributeSet class compares local attributes from the current set with all attributes (local and parent) from the second set if local counts are equal. So if we check the following text attributes: attr1: [ elem1 = value1] // getAttributeCount = 1 attr2: [ Parent = [ elem1 = value1] ] // getAttributeCount = 1 The results are: attr1.equals(attr2) = false // attr1 does not contain element with name Parent attr2.equals(attr1) = true // attr2 has element elem1 in the parent set All other classes that implement AttributeSet interface has the same problems with the hashcode/equals contract. The fix compares all local attributes from one set with all local attributes from the another set in the equals method. If both sets have parents, they will be compared automatically (in the same way as it was before). SimpleAttributeSet: Hashtable returns hashcode based on both keys and values. The fix redefines it to return a hash code only for values. MuxingAttributeSet: There is no direct way to get all local attributes. The getLocalAttribute method returns a value only if name is local. AbstractElement: If both attribute sets are AbstractElement they are compared by reference. In other case they are compared by checking local attributes. This preserves the old AbstractElement behaviour. The javax/swing/text/AttributeSet/8001423/bug8001423.java test is added. I run the javax/swing/text tests and there is no new failures after the fix. Thanks, Alexandr. From vera.akulova at oracle.com Thu Nov 1 15:34:50 2012 From: vera.akulova at oracle.com (vera akulova) Date: Thu, 01 Nov 2012 19:34:50 +0400 Subject: [8] Review request for JDK-8001808: Create a test for 8000327 Message-ID: <5092969A.3060304@oracle.com> Hello, Please review a fix for the issue: JDK-8001808: Create a test for 8000327 The webrev is http://cr.openjdk.java.net/~kshefov/8001808/webrev/ The new automatic regression test checking that ActionListener called just once for screen menu item on macosx. Thanks, Vera. From vera.akulova at oracle.com Thu Nov 1 15:37:25 2012 From: vera.akulova at oracle.com (vera akulova) Date: Thu, 01 Nov 2012 19:37:25 +0400 Subject: [8] Review request for JDK-8001876: Create regtest for 8000283 Message-ID: <50929735.9030807@oracle.com> Hello, Please review a fix for the issue: JDK-8001876: Create regtest for 8000283 The webrev is http://cr.openjdk.java.net/~kshefov/8001876/webrev/ The new manual regression test is for checking that shorcuts are displayed in the screen menu on macosx. Thanks, Vera. From dingxmin at linux.vnet.ibm.com Fri Nov 2 09:45:49 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Fri, 02 Nov 2012 17:45:49 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <5092664A.4010504@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> Message-ID: <5093964D.3000808@linux.vnet.ibm.com> Hi Alexandr, Thanks for your quick reply. I will refine the patch and address all your concerns ASAP. Best regards, Frank On 11/1/2012 8:08 PM, Alexander Scherbatiy wrote: > On 11/1/2012 10:35 AM, Frank Ding wrote: >> Hi Alexandr, >> Thanks for your review. The problem that the JButton does not >> release itself as you mentioned is, after taking closer look at >> relevant code again, that I removed instance AbstractButton.Handler >> as change listener where repainting the button press animation is >> defined. So this time I get around this issue and here comes v6 patch @ >> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ >> >> Below are answers to what you have raised in previous email. >> 1. if ( if (!listener.equals(this)) { that 'this' means the >> JButtonWrapper instead of an action listener. >> 'this' refers to JButtonWrapper.this because the closest class >> definition is JButtonWrapper. I also verified it during my debugging. > > Could you give an example there this check is useful? It seems > that the JButtonWrapper does not implement ActionListener interface > and so the listener and the this always should not be equal. > > > I dumped action listeners from the button and model before the fix > and after it. > Before the fix the button has the latest FormView listener and the > model has AbstractButton$Handler added each time after a component > input creation. > After the fix both the button and the model have the FormView > listener and the button does not have the AbstractButton$Handler. > Could you preserve the listeners location and just remove old > listeners from the model? > > The fix sets the model to the JButtonWrapper first and than removes > unneccessary listeners from the model. Is it possible to rearrange > order of these operations? > > I see that you check number of the listeners in the test. Could you > add the check that the action listener is invoked only once after a > component tree updating and > the action does the same that it does before a component tree > updating. > > Thanks, > Alexandr. >> >> 2. Why are two FormViews created in this sample? >> SwingUtilities.updateComponentTreeUI() triggers html View hierarchy >> to update by instantiating new UI instances involved in the html >> form. It could have been avoided to have 2 View instances but we are >> restricted to current design that LF change causes creation of View >> instance which further leads to creation of new UI instances. >> Creation of new UI instances upon LF change can be referenced in >> BasicTextUI.modelChanged(). >> >> 3. Why are there 2 listeners added to the button model in this sample? >> The issue is caused by combination of the 2 factors. First, a shared >> ButtonModel is created per html Element. Second, JButton.setModel() >> automatically registers its private Handler in the new model but no >> way to deregister it. The first is a design choice but the second is >> a design flaw. Consequence is that the shared ButtonModel instance >> bears more and more JButton.Handler. >> >> I think v6 patch is promising as a final fix. If you have any >> further concern or comment, please don't hesitate to let me know. >> Thanks again for your careful review. >> >> Best regards, >> Frank >> >> On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >>> Hi Frank, >>> >>> I tried your V5 patch and run the test described in the issue (see >>> below). >>> I pressed the button and it does not release. This is because the >>> AbstractButton.Handler listener is removed because of the fix. >>> You could check the line >>> 941 if (!listener.equals(this)) { >>> that 'this' means the JButtonWrapper instead of an action listener. >>> >>> Could you also look deeper in the code and say why two FormViews are >>> created (and each adds it's own listener to the button model) in >>> this sample? >>> >>> ----------------------------------------------- >>> import java.awt.*; >>> import javax.swing.*; >>> >>> public class FormSubmit { >>> >>> public static void main(String[] args) throws Exception { >>> SwingUtilities.invokeAndWait(new Runnable() { >>> >>> @Override >>> public void run() { >>> >>> JEditorPane html = new JEditorPane("text/html", >>> "
>> type=\"submit\" value=\"Submit\">
"); >>> JFrame frame = new JFrame() >>> frame.setLayout(new BorderLayout()); >>> frame.add(html, BorderLayout.CENTER); >>> frame.setSize(200, 100); >>> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >>> frame.setVisible(true); // Uncomment this line to >>> see the Exception on JDK 7 >>> SwingUtilities.updateComponentTreeUI(html); >>> } >>> }); >>> } >>> } >>> ----------------------------------------------- >>> >>> Thanks, >>> Alexandr. >>> >>> On 10/29/2012 11:48 AM, Frank Ding wrote: >>>> Hi all, >>>> Seems Pavel has been busy these days. Is anybody willing to >>>> review v5 change? >>>> >>>> Thanks, >>>> Frank >>>> >> > From alexandr.scherbatiy at oracle.com Fri Nov 2 10:21:02 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 2 Nov 2012 03:21:02 -0700 (PDT) Subject: [8] Review request for JDK-8001808: Create a test for 8000327 In-Reply-To: <5092969A.3060304@oracle.com> References: <5092969A.3060304@oracle.com> Message-ID: <50939E8E.2080703@oracle.com> The fix looks good for me. Thanks, Alexandr. On 11/1/2012 7:34 PM, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-8001808: Create a test for 8000327 > > The webrev is http://cr.openjdk.java.net/~kshefov/8001808/webrev/ > > The new automatic regression test checking that ActionListener called > just once for screen menu item on macosx. > > Thanks, > Vera. > From alexandr.scherbatiy at oracle.com Fri Nov 2 10:45:02 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 02 Nov 2012 14:45:02 +0400 Subject: [8] Review request for JDK-8001876: Create regtest for 8000283 In-Reply-To: <50929735.9030807@oracle.com> References: <50929735.9030807@oracle.com> Message-ID: <5093A42E.5030608@oracle.com> The fix looks good for me. Thanks, Alexandr. On 11/1/2012 7:37 PM, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-8001876: Create regtest for 8000283 > > The webrev is http://cr.openjdk.java.net/~kshefov/8001876/webrev/ > > The new manual regression test is for checking that shorcuts are > displayed in the screen menu on macosx. > > Thanks, > Vera. From alexander.zuev at oracle.com Fri Nov 2 14:12:12 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 02 Nov 2012 18:12:12 +0400 Subject: [8] Please teview fix for 7600365: Create a test for https://jbs.oracle.com/bugs/browse/JDK-8000286 Message-ID: <5093D4BC.3090006@oracle.com> Please review my test for CR 7600365: Create a test for https://jbs.oracle.com/bugs/browse/JDK-8000286 The new regression test can be found at http://cr.openjdk.java.net/~kizune/7600365/webrev.00/ Test description is available only at https://jbs.oracle.com/bugs/browse/INTJDK-7600365 because this CR is considered internal and it is not going to be available on public mirror. With best regards, Alex From Sergey.Bylokhov at oracle.com Fri Nov 2 15:26:22 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 02 Nov 2012 19:26:22 +0400 Subject: [8] Review request for JDK-8001876: Create regtest for 8000283 In-Reply-To: <50929735.9030807@oracle.com> References: <50929735.9030807@oracle.com> Message-ID: <5093E61E.5010903@oracle.com> Hi, Vera. Fix looks good. 01.11.2012 19:37, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-8001876: Create regtest for 8000283 > > The webrev is http://cr.openjdk.java.net/~kshefov/8001876/webrev/ > > The new manual regression test is for checking that shorcuts are > displayed in the screen menu on macosx. > > Thanks, > Vera. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Nov 2 15:26:36 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 02 Nov 2012 19:26:36 +0400 Subject: [8] Review request for JDK-8001808: Create a test for 8000327 In-Reply-To: <5092969A.3060304@oracle.com> References: <5092969A.3060304@oracle.com> Message-ID: <5093E62C.6020301@oracle.com> Hi, Vera. Fix looks good. 01.11.2012 19:34, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-8001808: Create a test for 8000327 > > The webrev is http://cr.openjdk.java.net/~kshefov/8001808/webrev/ > > The new automatic regression test checking that ActionListener called > just once for screen menu item on macosx. > > Thanks, > Vera. > -- Best regards, Sergey. From dingxmin at linux.vnet.ibm.com Mon Nov 5 07:20:16 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Mon, 05 Nov 2012 15:20:16 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <5092664A.4010504@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> Message-ID: <509768B0.6000802@linux.vnet.ibm.com> Hi Alexander, Based on your comments last time, I refined my patch of v6 and offered v7 @ http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ v7 preserves AbstractButton$Handler listener in the model and only makes sure only stale listeners are removed. Your questions and concerns are answered below one by one 1. Could you give an example there this check is useful? Answer: Ops, it's a mistake and the check is, as you pointed out, useless. It has been removed in v7. 2. Could you preserve the listeners location and just remove old listeners from the model? Answer: done in v7. 3. The fix sets the model to the JButtonWrapper first and than removes unnecessary listeners from the model. Is it possible to rearrange order of these operations? Answer: Excellent comment. Done in v7. 4. Could you add the check that the action listener is invoked only once after a component tree updating and the action does the same that it does before a component tree updating? Answer: I am afraid I could not make it in the auto test (bug7189299.java) but I can achieve it to some degree in manual test FormSubmit, the one you illustrated below. My idea of checking it in FormSubmit.java is subclassing JEditorPane and overriding 'public EditorKit getEditorKit()' where stack traces can be examined in the overridden method to make sure FormView.submitData occurs only once. This approach works because FormView.submitData() calls JEditorPane.getEditorKit but is tricky. However, it's the only way I can think of without any additional framework support. If you are in favor of adding the check in FormSubmit.java, I am willing to do that. Thanks again for all your comments and your support. Once again, if you have any further concern or comment, please don't hesitate to let me know. Best regards, Frank On 11/1/2012 8:08 PM, Alexander Scherbatiy wrote: > On 11/1/2012 10:35 AM, Frank Ding wrote: >> Hi Alexandr, >> Thanks for your review. The problem that the JButton does not >> release itself as you mentioned is, after taking closer look at >> relevant code again, that I removed instance AbstractButton.Handler >> as change listener where repainting the button press animation is >> defined. So this time I get around this issue and here comes v6 patch @ >> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ >> >> Below are answers to what you have raised in previous email. >> 1. if ( if (!listener.equals(this)) { that 'this' means the >> JButtonWrapper instead of an action listener. >> 'this' refers to JButtonWrapper.this because the closest class >> definition is JButtonWrapper. I also verified it during my debugging. > > Could you give an example there this check is useful? It seems > that the JButtonWrapper does not implement ActionListener interface > and so the listener and the this always should not be equal. > > > I dumped action listeners from the button and model before the fix > and after it. > Before the fix the button has the latest FormView listener and the > model has AbstractButton$Handler added each time after a component > input creation. > After the fix both the button and the model have the FormView > listener and the button does not have the AbstractButton$Handler. > Could you preserve the listeners location and just remove old > listeners from the model? > > The fix sets the model to the JButtonWrapper first and than removes > unneccessary listeners from the model. Is it possible to rearrange > order of these operations? > > I see that you check number of the listeners in the test. Could you > add the check that the action listener is invoked only once after a > component tree updating and > the action does the same that it does before a component tree > updating. > > Thanks, > Alexandr. >> >> 2. Why are two FormViews created in this sample? >> SwingUtilities.updateComponentTreeUI() triggers html View hierarchy >> to update by instantiating new UI instances involved in the html >> form. It could have been avoided to have 2 View instances but we are >> restricted to current design that LF change causes creation of View >> instance which further leads to creation of new UI instances. >> Creation of new UI instances upon LF change can be referenced in >> BasicTextUI.modelChanged(). >> >> 3. Why are there 2 listeners added to the button model in this sample? >> The issue is caused by combination of the 2 factors. First, a shared >> ButtonModel is created per html Element. Second, JButton.setModel() >> automatically registers its private Handler in the new model but no >> way to deregister it. The first is a design choice but the second is >> a design flaw. Consequence is that the shared ButtonModel instance >> bears more and more JButton.Handler. >> >> I think v6 patch is promising as a final fix. If you have any >> further concern or comment, please don't hesitate to let me know. >> Thanks again for your careful review. >> >> Best regards, >> Frank >> >> On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >>> Hi Frank, >>> >>> I tried your V5 patch and run the test described in the issue (see >>> below). >>> I pressed the button and it does not release. This is because the >>> AbstractButton.Handler listener is removed because of the fix. >>> You could check the line >>> 941 if (!listener.equals(this)) { >>> that 'this' means the JButtonWrapper instead of an action listener. >>> >>> Could you also look deeper in the code and say why two FormViews are >>> created (and each adds it's own listener to the button model) in >>> this sample? >>> >>> ----------------------------------------------- >>> import java.awt.*; >>> import javax.swing.*; >>> >>> public class FormSubmit { >>> >>> public static void main(String[] args) throws Exception { >>> SwingUtilities.invokeAndWait(new Runnable() { >>> >>> @Override >>> public void run() { >>> >>> JEditorPane html = new JEditorPane("text/html", >>> "
>> type=\"submit\" value=\"Submit\">
"); >>> JFrame frame = new JFrame() >>> frame.setLayout(new BorderLayout()); >>> frame.add(html, BorderLayout.CENTER); >>> frame.setSize(200, 100); >>> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >>> frame.setVisible(true); // Uncomment this line to >>> see the Exception on JDK 7 >>> SwingUtilities.updateComponentTreeUI(html); >>> } >>> }); >>> } >>> } >>> ----------------------------------------------- >>> >>> Thanks, >>> Alexandr. From alexandr.scherbatiy at oracle.com Tue Nov 6 13:26:53 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 06 Nov 2012 17:26:53 +0400 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <509768B0.6000802@linux.vnet.ibm.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> Message-ID: <5099101D.1020507@oracle.com> On 11/5/2012 11:20 AM, Frank Ding wrote: > Hi Alexander, > Based on your comments last time, I refined my patch of v6 and > offered v7 @ > http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ This version of the fix looks good for me. It seems that it is the only good way to check that a button model contains AbstarctButton.Handler listener. Could you also check that others models used in the createComponent() method do not have such memory leaks (even the NPE is not thrown)? > 4. Could you add the check that the action listener is invoked only > once after a component tree updating and the action does the same that > it does before a component tree updating? > Answer: I am afraid I could not make it in the auto test > (bug7189299.java) but I can achieve it to some degree in manual test > FormSubmit, the one you illustrated below. > My idea of checking it in FormSubmit.java is subclassing JEditorPane > and overriding 'public EditorKit getEditorKit()' where stack traces > can be examined in the overridden method to make sure > FormView.submitData occurs only once. This approach works because > FormView.submitData() calls JEditorPane.getEditorKit but is tricky. > However, it's the only way I can think of without any additional > framework support. If you are in favor of adding the check in > FormSubmit.java, I am willing to do that. At least a separated manual test can be added that asks a user to put a response.html file to a server and according to the server url checks that JTeditor pane show the response text after a button pressing. html = new JEditorPane("text/html", "
" + "" + "
"); response.html: Hello World! Thanks, Alexandr. > Thanks again for all your comments and your support. Once again, if > you have any further concern or comment, please don't hesitate to let > me know. > > Best regards, > Frank > > > On 11/1/2012 8:08 PM, Alexander Scherbatiy wrote: >> On 11/1/2012 10:35 AM, Frank Ding wrote: >>> Hi Alexandr, >>> Thanks for your review. The problem that the JButton does not >>> release itself as you mentioned is, after taking closer look at >>> relevant code again, that I removed instance AbstractButton.Handler >>> as change listener where repainting the button press animation is >>> defined. So this time I get around this issue and here comes v6 >>> patch @ >>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ >>> >>> Below are answers to what you have raised in previous email. >>> 1. if ( if (!listener.equals(this)) { that 'this' means the >>> JButtonWrapper instead of an action listener. >>> 'this' refers to JButtonWrapper.this because the closest class >>> definition is JButtonWrapper. I also verified it during my debugging. >> >> Could you give an example there this check is useful? It seems >> that the JButtonWrapper does not implement ActionListener interface >> and so the listener and the this always should not be equal. >> >> >> I dumped action listeners from the button and model before the fix >> and after it. >> Before the fix the button has the latest FormView listener and the >> model has AbstractButton$Handler added each time after a component >> input creation. >> After the fix both the button and the model have the FormView >> listener and the button does not have the AbstractButton$Handler. >> Could you preserve the listeners location and just remove old >> listeners from the model? >> >> The fix sets the model to the JButtonWrapper first and than >> removes unneccessary listeners from the model. Is it possible to >> rearrange order of these operations? >> >> I see that you check number of the listeners in the test. Could >> you add the check that the action listener is invoked only once after >> a component tree updating and >> the action does the same that it does before a component tree >> updating. >> >> Thanks, >> Alexandr. >>> >>> 2. Why are two FormViews created in this sample? >>> SwingUtilities.updateComponentTreeUI() triggers html View hierarchy >>> to update by instantiating new UI instances involved in the html >>> form. It could have been avoided to have 2 View instances but we >>> are restricted to current design that LF change causes creation of >>> View instance which further leads to creation of new UI instances. >>> Creation of new UI instances upon LF change can be referenced in >>> BasicTextUI.modelChanged(). >>> >>> 3. Why are there 2 listeners added to the button model in this sample? >>> The issue is caused by combination of the 2 factors. First, a >>> shared ButtonModel is created per html Element. Second, >>> JButton.setModel() automatically registers its private Handler in >>> the new model but no way to deregister it. The first is a design >>> choice but the second is a design flaw. Consequence is that the >>> shared ButtonModel instance bears more and more JButton.Handler. >>> >>> I think v6 patch is promising as a final fix. If you have any >>> further concern or comment, please don't hesitate to let me know. >>> Thanks again for your careful review. >>> >>> Best regards, >>> Frank >>> >>> On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >>>> Hi Frank, >>>> >>>> I tried your V5 patch and run the test described in the issue (see >>>> below). >>>> I pressed the button and it does not release. This is because the >>>> AbstractButton.Handler listener is removed because of the fix. >>>> You could check the line >>>> 941 if (!listener.equals(this)) { >>>> that 'this' means the JButtonWrapper instead of an action listener. >>>> >>>> Could you also look deeper in the code and say why two FormViews >>>> are created (and each adds it's own listener to the button model) >>>> in this sample? >>>> >>>> ----------------------------------------------- >>>> import java.awt.*; >>>> import javax.swing.*; >>>> >>>> public class FormSubmit { >>>> >>>> public static void main(String[] args) throws Exception { >>>> SwingUtilities.invokeAndWait(new Runnable() { >>>> >>>> @Override >>>> public void run() { >>>> >>>> JEditorPane html = new JEditorPane("text/html", >>>> "
>>> type=\"submit\" value=\"Submit\">
"); >>>> JFrame frame = new JFrame() >>>> frame.setLayout(new BorderLayout()); >>>> frame.add(html, BorderLayout.CENTER); >>>> frame.setSize(200, 100); >>>> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >>>> frame.setVisible(true); // Uncomment this line to >>>> see the Exception on JDK 7 >>>> SwingUtilities.updateComponentTreeUI(html); >>>> } >>>> }); >>>> } >>>> } >>>> ----------------------------------------------- >>>> >>>> Thanks, >>>> Alexandr. > From dingxmin at linux.vnet.ibm.com Wed Nov 7 06:56:57 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 07 Nov 2012 14:56:57 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <5099101D.1020507@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com> Message-ID: <509A0639.1030806@linux.vnet.ibm.com> Hi Alexandr, Unfortunately, all the JComponents involved in FormView.createComponent() have bugs! I have done tests for all other swing components, i.e. JCheckBox, JRadioButton, JPasswordField, JTextField, JList, JComboBox and JTextField. Sadder news is that if we fix all components in the same way as I did for JButton, we need to subclass them all, resulting in JCheckBoxWrapper, JRadioButtonWrapper, JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, JComboBoxWrapper, JTextFieldWrapper plus JButtonWrapper! This approach becomes unacceptable when all swing components are affected. Shall we fix it in other way illustrated below? 1. Whenever a swing component is created, it is kept in AttributeSet, as what is now for model. 2. In FormView.createComponent(), the old swing component can be retrieved via attr.getAttribute(StyleConstants.ComponentAttribute). Note that ComponentAttribute is newly added. 3. Before setting shared model to a newly initialized swing component, call oldComp.setModel(null), delegating deregistration to setModel method. 4. Seems some setModel such as AbstractButton.setModel() can function well when the param, new model, is null while JComboBox.setModel() will throw NPE in case of null param. 5. Add null check code in those problematic setModel or setDocument methods. Any idea is appreciated. Thanks. Best regards, Frank On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote: > On 11/5/2012 11:20 AM, Frank Ding wrote: >> Hi Alexander, >> Based on your comments last time, I refined my patch of v6 and >> offered v7 @ >> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ > > This version of the fix looks good for me. > It seems that it is the only good way to check that a button > model contains AbstarctButton.Handler listener. > > Could you also check that others models used in the > createComponent() method do not have such memory leaks (even the NPE > is not thrown)? > >> 4. Could you add the check that the action listener is invoked >> only once after a component tree updating and the action does the >> same that it does before a component tree updating? >> Answer: I am afraid I could not make it in the auto test >> (bug7189299.java) but I can achieve it to some degree in manual test >> FormSubmit, the one you illustrated below. >> My idea of checking it in FormSubmit.java is subclassing >> JEditorPane and overriding 'public EditorKit getEditorKit()' where >> stack traces can be examined in the overridden method to make sure >> FormView.submitData occurs only once. This approach works because >> FormView.submitData() calls JEditorPane.getEditorKit but is tricky. >> However, it's the only way I can think of without any additional >> framework support. If you are in favor of adding the check in >> FormSubmit.java, I am willing to do that. > > At least a separated manual test can be added that asks a user > to put a response.html file to a server and according to the server > url checks that JTeditor pane show the response text after a button > pressing. > > html = new JEditorPane("text/html", > "
" > + " value=\"submit\"/>" > + "
"); > > response.html: > Hello World! > > Thanks, > Alexandr. > >> Thanks again for all your comments and your support. Once again, >> if you have any further concern or comment, please don't hesitate to >> let me know. >> >> Best regards, >> Frank >> >> >> On 11/1/2012 8:08 PM, Alexander Scherbatiy wrote: >>> On 11/1/2012 10:35 AM, Frank Ding wrote: >>>> Hi Alexandr, >>>> Thanks for your review. The problem that the JButton does not >>>> release itself as you mentioned is, after taking closer look at >>>> relevant code again, that I removed instance AbstractButton.Handler >>>> as change listener where repainting the button press animation is >>>> defined. So this time I get around this issue and here comes v6 >>>> patch @ >>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ >>>> >>>> Below are answers to what you have raised in previous email. >>>> 1. if ( if (!listener.equals(this)) { that 'this' means the >>>> JButtonWrapper instead of an action listener. >>>> 'this' refers to JButtonWrapper.this because the closest class >>>> definition is JButtonWrapper. I also verified it during my debugging. >>> >>> Could you give an example there this check is useful? It seems >>> that the JButtonWrapper does not implement ActionListener interface >>> and so the listener and the this always should not be equal. >>> >>> >>> I dumped action listeners from the button and model before the >>> fix and after it. >>> Before the fix the button has the latest FormView listener and >>> the model has AbstractButton$Handler added each time after a >>> component input creation. >>> After the fix both the button and the model have the FormView >>> listener and the button does not have the AbstractButton$Handler. >>> Could you preserve the listeners location and just remove old >>> listeners from the model? >>> >>> The fix sets the model to the JButtonWrapper first and than >>> removes unneccessary listeners from the model. Is it possible to >>> rearrange order of these operations? >>> >>> I see that you check number of the listeners in the test. Could >>> you add the check that the action listener is invoked only once >>> after a component tree updating and >>> the action does the same that it does before a component tree >>> updating. >>> >>> Thanks, >>> Alexandr. >>>> >>>> 2. Why are two FormViews created in this sample? >>>> SwingUtilities.updateComponentTreeUI() triggers html View hierarchy >>>> to update by instantiating new UI instances involved in the html >>>> form. It could have been avoided to have 2 View instances but we >>>> are restricted to current design that LF change causes creation of >>>> View instance which further leads to creation of new UI instances. >>>> Creation of new UI instances upon LF change can be referenced in >>>> BasicTextUI.modelChanged(). >>>> >>>> 3. Why are there 2 listeners added to the button model in this sample? >>>> The issue is caused by combination of the 2 factors. First, a >>>> shared ButtonModel is created per html Element. Second, >>>> JButton.setModel() automatically registers its private Handler in >>>> the new model but no way to deregister it. The first is a design >>>> choice but the second is a design flaw. Consequence is that the >>>> shared ButtonModel instance bears more and more JButton.Handler. >>>> >>>> I think v6 patch is promising as a final fix. If you have any >>>> further concern or comment, please don't hesitate to let me know. >>>> Thanks again for your careful review. >>>> >>>> Best regards, >>>> Frank >>>> >>>> On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >>>>> Hi Frank, >>>>> >>>>> I tried your V5 patch and run the test described in the issue (see >>>>> below). >>>>> I pressed the button and it does not release. This is because the >>>>> AbstractButton.Handler listener is removed because of the fix. >>>>> You could check the line >>>>> 941 if (!listener.equals(this)) { >>>>> that 'this' means the JButtonWrapper instead of an action listener. >>>>> >>>>> Could you also look deeper in the code and say why two FormViews >>>>> are created (and each adds it's own listener to the button model) >>>>> in this sample? >>>>> >>>>> ----------------------------------------------- >>>>> import java.awt.*; >>>>> import javax.swing.*; >>>>> >>>>> public class FormSubmit { >>>>> >>>>> public static void main(String[] args) throws Exception { >>>>> SwingUtilities.invokeAndWait(new Runnable() { >>>>> >>>>> @Override >>>>> public void run() { >>>>> >>>>> JEditorPane html = new JEditorPane("text/html", >>>>> "
>>>> type=\"submit\" value=\"Submit\">
"); >>>>> JFrame frame = new JFrame() >>>>> frame.setLayout(new BorderLayout()); >>>>> frame.add(html, BorderLayout.CENTER); >>>>> frame.setSize(200, 100); >>>>> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >>>>> frame.setVisible(true); // Uncomment this line to >>>>> see the Exception on JDK 7 >>>>> SwingUtilities.updateComponentTreeUI(html); >>>>> } >>>>> }); >>>>> } >>>>> } >>>>> ----------------------------------------------- >>>>> >>>>> Thanks, >>>>> Alexandr. >> > From denis.fokin at oracle.com Tue Nov 6 14:26:24 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Tue, 06 Nov 2012 18:26:24 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50927965.3030402@oracle.com> References: <50927965.3030402@oracle.com> Message-ID: <50991E10.5090202@oracle.com> Hi Alexander, I found several places that could be improved, in my opinion. SimpleAttributeSet.java 120 boolean result = true; I would not assign 'true' as a default value. If the 'names' enumeration does not have any elements, we return true even not trying to compare anything. // Does not have elements, so returns true. 123 while (result && names.hasMoreElements()) { MuxingAttributeSet.java 130 for (int i = 0; i < as.length; i++) { Why we do not use foreach loop here? AbstractDocument.java 1874 && !(obj instanceof AbstractElement)) { I am not an expert in Swing, so this check is not quite clear to me. Why we check AbstractDocument.AbstractElement and do not check, for instance, SimpleAttributeSet? Is it only because of "the old AbstractElement behaviour"? By the way, I would say that we should check for equality by reference in the first place to get rid of comparing attributes if we call equals method for the same object. Thank you, Denis. On 11/1/2012 5:30 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001423 > webrev: http://cr.openjdk.java.net/~alexsch/8001423/webrev.00 > > The 'equals' method from the SmallAttributeSet class compares local > attributes from the current set with all attributes (local and parent) > from the second set if local counts are equal. > So if we check the following text attributes: > attr1: [ elem1 = value1] // getAttributeCount = 1 > attr2: [ Parent = [ elem1 = value1] ] // getAttributeCount = 1 > > The results are: > attr1.equals(attr2) = false // attr1 does not contain element with name > Parent > attr2.equals(attr1) = true // attr2 has element elem1 in the parent set > > All other classes that implement AttributeSet interface has the same > problems with the hashcode/equals contract. > > The fix compares all local attributes from one set with all local > attributes from the another set in the equals method. > If both sets have parents, they will be compared automatically (in the > same way as it was before). > > > SimpleAttributeSet: Hashtable returns hashcode based on both keys and > values. The fix redefines it to return a hash code only for values. > MuxingAttributeSet: There is no direct way to get all local attributes. > The getLocalAttribute method returns a value only if name is local. > AbstractElement: If both attribute sets are AbstractElement they are > compared by reference. In other case they are compared by checking local > attributes. This preserves the old AbstractElement behaviour. > > The javax/swing/text/AttributeSet/8001423/bug8001423.java test is added. > > I run the javax/swing/text tests and there is no new failures after the > fix. > > Thanks, > Alexandr. > From konstantin.shefov at oracle.com Wed Nov 7 14:59:43 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 07 Nov 2012 18:59:43 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <5092816F.20006@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> Message-ID: <509A775F.7010305@oracle.com> I made modifications you suggested. http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ Konstantin On 01-Nov-12 18:04, Alexander Scherbatiy wrote: > > - The test needs to create and use Swing components only on EDT. > The same is for JApplet (see > http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). > In the same way the following variable initialization is not > correct because the JEditorPane is not created on the EDT: > private JEditorPane jep = new JEditorPane(); > > - The test fails with the compilation error: cannot find symbol > Util.blockTillDisplayed(jep); > Use the toolkit realSync() method instead: > SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); > ... > toolkit.realSync(); > > Thanks, > Alexandr. > > > On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >> On 30-Oct-12 16:43, Anthony Petrov wrote: >>> Looks fine to me. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>> Hello, >>>> >>>> Please review a fix for the issue: >>>> >>>> 7147408 [macosx] Add autodelay to fix a regression test >>>> >>>> The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>> >>>> It is suggested to move the test to open jdk. >>>> >>>> Thanks, >>>> Konstantin >>>> > From konstantin.shefov at oracle.com Wed Nov 7 15:00:48 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 07 Nov 2012 19:00:48 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <50927D0F.1070609@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> Message-ID: <509A77A0.4080901@oracle.com> Please, look at modified fix: http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ On 01-Nov-12 17:45, Alexander Scherbatiy wrote: > > - Please, remove comments and unnecessary System.out from the fix > - Create and check swing components on EDT. Avoiding this rule can > leads to unpredictable test failures. > - Swing tests usually have bugBugID.java or some meaningful name. > - It is better to use the swing-dev at openjdk.java.net alias to > review the swing tests. > > Thanks, > Alexandr. > > On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >> Hello, >> >> Please review a fix for the issue: >> >> 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: >> [NORTH, SOUTH] >> >> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >> >> It is suggested to move the test to open jdk. >> >> Thanks, >> Konstantin >> > From alexandr.scherbatiy at oracle.com Thu Nov 8 12:02:31 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 08 Nov 2012 16:02:31 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <509A77A0.4080901@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> Message-ID: <509B9F57.4000304@oracle.com> On 11/7/2012 7:00 PM, Konstantin Shefov wrote: > Please, look at modified fix: > http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ > Try/catch block in the main method catches RuntimeException as well. So the jtreg passes the test even it really fails. It is also a good idea to fail the test if the SwingUtilities.invokeAndWait() throws an exception because it is also a wrong situation. Thanks, Alexandr. > > On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >> >> - Please, remove comments and unnecessary System.out from the fix >> - Create and check swing components on EDT. Avoiding this rule can >> leads to unpredictable test failures. >> - Swing tests usually have bugBugID.java or some meaningful name. >> - It is better to use the swing-dev at openjdk.java.net alias to >> review the swing tests. >> >> Thanks, >> Alexandr. >> >> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>> Hello, >>> >>> Please review a fix for the issue: >>> >>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: >>> [NORTH, SOUTH] >>> >>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>> >>> It is suggested to move the test to open jdk. >>> >>> Thanks, >>> Konstantin >>> >> From konstantin.shefov at oracle.com Thu Nov 8 12:25:27 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 08 Nov 2012 16:25:27 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <509B9F57.4000304@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> Message-ID: <509BA4B7.2060506@oracle.com> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ On 08-Nov-12 16:02, Alexander Scherbatiy wrote: > On 11/7/2012 7:00 PM, Konstantin Shefov wrote: >> Please, look at modified fix: >> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ >> > > Try/catch block in the main method catches RuntimeException as > well. So the jtreg passes the test even it really fails. > It is also a good idea to fail the test if the > SwingUtilities.invokeAndWait() throws an exception because it is also > a wrong situation. > > Thanks, > Alexandr. > >> >> On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >>> >>> - Please, remove comments and unnecessary System.out from the fix >>> - Create and check swing components on EDT. Avoiding this rule can >>> leads to unpredictable test failures. >>> - Swing tests usually have bugBugID.java or some meaningful name. >>> - It is better to use the swing-dev at openjdk.java.net alias to >>> review the swing tests. >>> >>> Thanks, >>> Alexandr. >>> >>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>>> Hello, >>>> >>>> Please review a fix for the issue: >>>> >>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: >>>> [NORTH, SOUTH] >>>> >>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>>> >>>> It is suggested to move the test to open jdk. >>>> >>>> Thanks, >>>> Konstantin >>>> >>> > From alexandr.scherbatiy at oracle.com Thu Nov 8 12:44:23 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 08 Nov 2012 16:44:23 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509A775F.7010305@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> Message-ID: <509BA927.6020509@oracle.com> On 11/7/2012 6:59 PM, Konstantin Shefov wrote: > I made modifications you suggested. > http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ > Could you also fix the issue with the catched RuntimeException? All others looks good for me. Thanks, Alexandr. > > Konstantin > > On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >> >> - The test needs to create and use Swing components only on EDT. >> The same is for JApplet (see >> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >> In the same way the following variable initialization is not >> correct because the JEditorPane is not created on the EDT: >> private JEditorPane jep = new JEditorPane(); >> >> - The test fails with the compilation error: cannot find symbol >> Util.blockTillDisplayed(jep); >> Use the toolkit realSync() method instead: >> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >> ... >> toolkit.realSync(); >> >> Thanks, >> Alexandr. >> >> >> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>> Looks fine to me. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for the issue: >>>>> >>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>> >>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>> >>>>> It is suggested to move the test to open jdk. >>>>> >>>>> Thanks, >>>>> Konstantin >>>>> >> From konstantin.shefov at oracle.com Thu Nov 8 13:20:29 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 08 Nov 2012 17:20:29 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509BA927.6020509@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> <509BA927.6020509@oracle.com> Message-ID: <509BB19D.20802@oracle.com> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ On 08-Nov-12 16:44, Alexander Scherbatiy wrote: > On 11/7/2012 6:59 PM, Konstantin Shefov wrote: >> I made modifications you suggested. >> http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ >> > > Could you also fix the issue with the catched RuntimeException? > All others looks good for me. > > Thanks, > Alexandr. > >> >> Konstantin >> >> On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >>> >>> - The test needs to create and use Swing components only on EDT. >>> The same is for JApplet (see >>> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >>> In the same way the following variable initialization is not >>> correct because the JEditorPane is not created on the EDT: >>> private JEditorPane jep = new JEditorPane(); >>> >>> - The test fails with the compilation error: cannot find symbol >>> Util.blockTillDisplayed(jep); >>> Use the toolkit realSync() method instead: >>> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >>> ... >>> toolkit.realSync(); >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>>> Looks fine to me. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for the issue: >>>>>> >>>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>>> >>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>>> >>>>>> It is suggested to move the test to open jdk. >>>>>> >>>>>> Thanks, >>>>>> Konstantin >>>>>> >>> > From alexandr.scherbatiy at oracle.com Thu Nov 8 14:55:42 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 08 Nov 2012 18:55:42 +0400 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <509A0639.1030806@linux.vnet.ibm.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com> <509A0639.1030806@linux.vnet.ibm.com> Message-ID: <509BC7EE.7000801@oracle.com> On 11/7/2012 10:56 AM, Frank Ding wrote: > Hi Alexandr, > Unfortunately, all the JComponents involved in > FormView.createComponent() have bugs! > I have done tests for all other swing components, i.e. JCheckBox, > JRadioButton, JPasswordField, JTextField, JList, JComboBox and > JTextField. Sadder news is that if we fix all components in the same > way as I did for JButton, we need to subclass them all, resulting in > JCheckBoxWrapper, JRadioButtonWrapper, JPasswordFieldWrapper, > JTextFieldWrapper, JListWrapper, JComboBoxWrapper, JTextFieldWrapper > plus JButtonWrapper! This approach becomes unacceptable when all > swing components are affected. > Shall we fix it in other way illustrated below? > 1. Whenever a swing component is created, it is kept in AttributeSet, > as what is now for model. > 2. In FormView.createComponent(), the old swing component can be > retrieved via attr.getAttribute(StyleConstants.ComponentAttribute). > Note that ComponentAttribute is newly added. This way should be carefully investigated that it does not introduce new memory leaks. Could you also check that the StyleConstants.ComponentAttribute property value can't be rewritten by the JDK code or by public methods. > 3. Before setting shared model to a newly initialized swing component, > call oldComp.setModel(null), delegating deregistration to setModel > method. > 4. Seems some setModel such as AbstractButton.setModel() can function > well when the param, new model, is null while JComboBox.setModel() > will throw NPE in case of null param. Could you create an issue that a JComboBox.setModel(null) call throws NPE? You could fix it before the 7189299 issue. Thanks, Alexandr. > 5. Add null check code in those problematic setModel or setDocument > methods. > > Any idea is appreciated. Thanks. > > Best regards, > Frank > > On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote: >> On 11/5/2012 11:20 AM, Frank Ding wrote: >>> Hi Alexander, >>> Based on your comments last time, I refined my patch of v6 and >>> offered v7 @ >>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ >> >> This version of the fix looks good for me. >> It seems that it is the only good way to check that a button >> model contains AbstarctButton.Handler listener. >> >> Could you also check that others models used in the >> createComponent() method do not have such memory leaks (even the NPE >> is not thrown)? >> >>> 4. Could you add the check that the action listener is invoked >>> only once after a component tree updating and the action does the >>> same that it does before a component tree updating? >>> Answer: I am afraid I could not make it in the auto test >>> (bug7189299.java) but I can achieve it to some degree in manual test >>> FormSubmit, the one you illustrated below. >>> My idea of checking it in FormSubmit.java is subclassing >>> JEditorPane and overriding 'public EditorKit getEditorKit()' where >>> stack traces can be examined in the overridden method to make sure >>> FormView.submitData occurs only once. This approach works because >>> FormView.submitData() calls JEditorPane.getEditorKit but is tricky. >>> However, it's the only way I can think of without any additional >>> framework support. If you are in favor of adding the check in >>> FormSubmit.java, I am willing to do that. >> >> At least a separated manual test can be added that asks a user >> to put a response.html file to a server and according to the server >> url checks that JTeditor pane show the response text after a button >> pressing. >> >> html = new JEditorPane("text/html", >> "
" >> + "> value=\"submit\"/>" >> + "
"); >> >> response.html: >> Hello World! >> >> Thanks, >> Alexandr. >> >>> Thanks again for all your comments and your support. Once again, >>> if you have any further concern or comment, please don't hesitate to >>> let me know. >>> >>> Best regards, >>> Frank >>> >>> >>> On 11/1/2012 8:08 PM, Alexander Scherbatiy wrote: >>>> On 11/1/2012 10:35 AM, Frank Ding wrote: >>>>> Hi Alexandr, >>>>> Thanks for your review. The problem that the JButton does not >>>>> release itself as you mentioned is, after taking closer look at >>>>> relevant code again, that I removed instance >>>>> AbstractButton.Handler as change listener where repainting the >>>>> button press animation is defined. So this time I get around this >>>>> issue and here comes v6 patch @ >>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ >>>>> >>>>> Below are answers to what you have raised in previous email. >>>>> 1. if ( if (!listener.equals(this)) { that 'this' means the >>>>> JButtonWrapper instead of an action listener. >>>>> 'this' refers to JButtonWrapper.this because the closest class >>>>> definition is JButtonWrapper. I also verified it during my >>>>> debugging. >>>> >>>> Could you give an example there this check is useful? It seems >>>> that the JButtonWrapper does not implement ActionListener interface >>>> and so the listener and the this always should not be equal. >>>> >>>> >>>> I dumped action listeners from the button and model before the >>>> fix and after it. >>>> Before the fix the button has the latest FormView listener and >>>> the model has AbstractButton$Handler added each time after a >>>> component input creation. >>>> After the fix both the button and the model have the FormView >>>> listener and the button does not have the AbstractButton$Handler. >>>> Could you preserve the listeners location and just remove old >>>> listeners from the model? >>>> >>>> The fix sets the model to the JButtonWrapper first and than >>>> removes unneccessary listeners from the model. Is it possible to >>>> rearrange order of these operations? >>>> >>>> I see that you check number of the listeners in the test. Could >>>> you add the check that the action listener is invoked only once >>>> after a component tree updating and >>>> the action does the same that it does before a component tree >>>> updating. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> 2. Why are two FormViews created in this sample? >>>>> SwingUtilities.updateComponentTreeUI() triggers html View >>>>> hierarchy to update by instantiating new UI instances involved in >>>>> the html form. It could have been avoided to have 2 View >>>>> instances but we are restricted to current design that LF change >>>>> causes creation of View instance which further leads to creation >>>>> of new UI instances. Creation of new UI instances upon LF change >>>>> can be referenced in BasicTextUI.modelChanged(). >>>>> >>>>> 3. Why are there 2 listeners added to the button model in this >>>>> sample? >>>>> The issue is caused by combination of the 2 factors. First, a >>>>> shared ButtonModel is created per html Element. Second, >>>>> JButton.setModel() automatically registers its private Handler in >>>>> the new model but no way to deregister it. The first is a design >>>>> choice but the second is a design flaw. Consequence is that the >>>>> shared ButtonModel instance bears more and more JButton.Handler. >>>>> >>>>> I think v6 patch is promising as a final fix. If you have any >>>>> further concern or comment, please don't hesitate to let me know. >>>>> Thanks again for your careful review. >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >>>>>> Hi Frank, >>>>>> >>>>>> I tried your V5 patch and run the test described in the issue >>>>>> (see below). >>>>>> I pressed the button and it does not release. This is because the >>>>>> AbstractButton.Handler listener is removed because of the fix. >>>>>> You could check the line >>>>>> 941 if (!listener.equals(this)) { >>>>>> that 'this' means the JButtonWrapper instead of an action listener. >>>>>> >>>>>> Could you also look deeper in the code and say why two FormViews >>>>>> are created (and each adds it's own listener to the button model) >>>>>> in this sample? >>>>>> >>>>>> ----------------------------------------------- >>>>>> import java.awt.*; >>>>>> import javax.swing.*; >>>>>> >>>>>> public class FormSubmit { >>>>>> >>>>>> public static void main(String[] args) throws Exception { >>>>>> SwingUtilities.invokeAndWait(new Runnable() { >>>>>> >>>>>> @Override >>>>>> public void run() { >>>>>> >>>>>> JEditorPane html = new JEditorPane("text/html", >>>>>> "
>>>>> type=\"submit\" value=\"Submit\">
"); >>>>>> JFrame frame = new JFrame() >>>>>> frame.setLayout(new BorderLayout()); >>>>>> frame.add(html, BorderLayout.CENTER); >>>>>> frame.setSize(200, 100); >>>>>> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >>>>>> frame.setVisible(true); // Uncomment this line to >>>>>> see the Exception on JDK 7 >>>>>> SwingUtilities.updateComponentTreeUI(html); >>>>>> } >>>>>> }); >>>>>> } >>>>>> } >>>>>> ----------------------------------------------- >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>> >> > From peter.brunet at oracle.com Thu Nov 8 21:51:19 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 08 Nov 2012 15:51:19 -0600 Subject: Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners Message-ID: <509C2957.9070200@oracle.com> Hi Everyone, Please review the following fix planned for 7u12. It will also go into 8 under 7179482. Problem: When an AT (Assistive Technology) accesses a Java application with several nested frames, too many property change listeners are added resulting in a severe performance impact for an AT user. The issue is due to the fact that there is an accessibleContainerHandler field in both javax.swing.JComponent.AccessibleJComponent and its superclass, java.awt.Container.AccessibleAWTContainer. When an AT calls JComponent.AccessibleJComponent.addPropertyChangeListener a handler is new'd and assigned to its accessibleContainerHandler field and then the same method in the superclass is called and it also new's and assigns a handler to its accessibleContainerHandler field. Since there are two handlers, when a child component is later added there are two callbacks and for each one the AT will call addPropertyChangeListener, each of which will add two handlers. For deeply nested trees the explosion of events has a negative impact on performance, i.e. there are 2 handlers added for the first level, 4 for the second level, 8 for the third level, etc. Solution: Remove protected field javax.swing.JComponent.AccessibleJComponent.accessibleContainerHandler. Instead, the protected field of the same name in java.awt.Container.AWTAccessibleContainer will be used. Webrev: http://cr.openjdk.java.net/~ptbrunet/7177111/webrev.03/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177111 http://monaco.us.oracle.com/detail.jsf?cr=7177111 CCC: http://ccc.us.oracle.com/7177111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Nov 9 08:46:25 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 09 Nov 2012 12:46:25 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509BB19D.20802@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> <509BA927.6020509@oracle.com> <509BB19D.20802@oracle.com> Message-ID: <509CC2E1.8090601@oracle.com> On 11/8/2012 5:20 PM, Konstantin Shefov wrote: > http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ > The fix looks good for me. Thanks, Alexandr. > > On 08-Nov-12 16:44, Alexander Scherbatiy wrote: >> On 11/7/2012 6:59 PM, Konstantin Shefov wrote: >>> I made modifications you suggested. >>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ >>> >> >> Could you also fix the issue with the catched RuntimeException? >> All others looks good for me. >> >> Thanks, >> Alexandr. >> >>> >>> Konstantin >>> >>> On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >>>> >>>> - The test needs to create and use Swing components only on EDT. >>>> The same is for JApplet (see >>>> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >>>> >>>> In the same way the following variable initialization is not >>>> correct because the JEditorPane is not created on the EDT: >>>> private JEditorPane jep = new JEditorPane(); >>>> >>>> - The test fails with the compilation error: cannot find symbol >>>> Util.blockTillDisplayed(jep); >>>> Use the toolkit realSync() method instead: >>>> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >>>> ... >>>> toolkit.realSync(); >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>>>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>>>> Looks fine to me. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for the issue: >>>>>>> >>>>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>>>> >>>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>>>> >>>>>>> It is suggested to move the test to open jdk. >>>>>>> >>>>>>> Thanks, >>>>>>> Konstantin >>>>>>> >>>> >> From alexandr.scherbatiy at oracle.com Fri Nov 9 08:47:49 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 09 Nov 2012 12:47:49 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <509BA4B7.2060506@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> Message-ID: <509CC335.2010908@oracle.com> On 11/8/2012 4:25 PM, Konstantin Shefov wrote: > http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ > The fix looks good for me. Thanks, Alexandr. > > On 08-Nov-12 16:02, Alexander Scherbatiy wrote: >> On 11/7/2012 7:00 PM, Konstantin Shefov wrote: >>> Please, look at modified fix: >>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ >>> >> >> Try/catch block in the main method catches RuntimeException as >> well. So the jtreg passes the test even it really fails. >> It is also a good idea to fail the test if the >> SwingUtilities.invokeAndWait() throws an exception because it is also >> a wrong situation. >> >> Thanks, >> Alexandr. >> >>> >>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >>>> >>>> - Please, remove comments and unnecessary System.out from the fix >>>> - Create and check swing components on EDT. Avoiding this rule >>>> can leads to unpredictable test failures. >>>> - Swing tests usually have bugBugID.java or some meaningful name. >>>> - It is better to use the swing-dev at openjdk.java.net alias to >>>> review the swing tests. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for the issue: >>>>> >>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: >>>>> [NORTH, SOUTH] >>>>> >>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>>>> >>>>> It is suggested to move the test to open jdk. >>>>> >>>>> Thanks, >>>>> Konstantin >>>>> >>>> >> From konstantin.shefov at oracle.com Fri Nov 9 08:59:41 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 09 Nov 2012 12:59:41 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509CC2E1.8090601@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> <509BA927.6020509@oracle.com> <509BB19D.20802@oracle.com> <509CC2E1.8090601@oracle.com> Message-ID: <509CC5FD.2020606@oracle.com> Could you please look at this test fix? http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ On 09-Nov-12 12:46, Alexander Scherbatiy wrote: > On 11/8/2012 5:20 PM, Konstantin Shefov wrote: >> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ >> > > The fix looks good for me. > > Thanks, > Alexandr. > >> >> On 08-Nov-12 16:44, Alexander Scherbatiy wrote: >>> On 11/7/2012 6:59 PM, Konstantin Shefov wrote: >>>> I made modifications you suggested. >>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ >>>> >>> >>> Could you also fix the issue with the catched RuntimeException? >>> All others looks good for me. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Konstantin >>>> >>>> On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >>>>> >>>>> - The test needs to create and use Swing components only on EDT. >>>>> The same is for JApplet (see >>>>> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >>>>> >>>>> In the same way the following variable initialization is not >>>>> correct because the JEditorPane is not created on the EDT: >>>>> private JEditorPane jep = new JEditorPane(); >>>>> >>>>> - The test fails with the compilation error: cannot find symbol >>>>> Util.blockTillDisplayed(jep); >>>>> Use the toolkit realSync() method instead: >>>>> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >>>>> ... >>>>> toolkit.realSync(); >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>>>>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>>>>> Looks fine to me. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a fix for the issue: >>>>>>>> >>>>>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>>>>> >>>>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>>>>> >>>>>>>> It is suggested to move the test to open jdk. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Konstantin >>>>>>>> >>>>> >>> > From konstantin.shefov at oracle.com Fri Nov 9 09:00:15 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 09 Nov 2012 13:00:15 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <509CC335.2010908@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> Message-ID: <509CC61F.5050206@oracle.com> Could you please look at this test fix? http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ On 09-Nov-12 12:47, Alexander Scherbatiy wrote: > On 11/8/2012 4:25 PM, Konstantin Shefov wrote: >> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ >> > > The fix looks good for me. > > Thanks, > Alexandr. > >> >> On 08-Nov-12 16:02, Alexander Scherbatiy wrote: >>> On 11/7/2012 7:00 PM, Konstantin Shefov wrote: >>>> Please, look at modified fix: >>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ >>>> >>> >>> Try/catch block in the main method catches RuntimeException as >>> well. So the jtreg passes the test even it really fails. >>> It is also a good idea to fail the test if the >>> SwingUtilities.invokeAndWait() throws an exception because it is >>> also a wrong situation. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >>>>> >>>>> - Please, remove comments and unnecessary System.out from the fix >>>>> - Create and check swing components on EDT. Avoiding this rule >>>>> can leads to unpredictable test failures. >>>>> - Swing tests usually have bugBugID.java or some meaningful name. >>>>> - It is better to use the swing-dev at openjdk.java.net alias to >>>>> review the swing tests. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for the issue: >>>>>> >>>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the >>>>>> range: [NORTH, SOUTH] >>>>>> >>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>>>>> >>>>>> It is suggested to move the test to open jdk. >>>>>> >>>>>> Thanks, >>>>>> Konstantin >>>>>> >>>>> >>> > From Sergey.Bylokhov at oracle.com Fri Nov 9 12:30:11 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 09 Nov 2012 16:30:11 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509CC5FD.2020606@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> <509BA927.6020509@oracle.com> <509BB19D.20802@oracle.com> <509CC2E1.8090601@oracle.com> <509CC5FD.2020606@oracle.com> Message-ID: <509CF753.7080007@oracle.com> 09.11.2012 12:59, Konstantin Shefov wrote: > Could you please look at this test fix? > http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ Where finished and timer is used? 44 private Timer timer; 46 private boolean finished = false; passed used in destroy method w/o synchronization. > > On 09-Nov-12 12:46, Alexander Scherbatiy wrote: >> On 11/8/2012 5:20 PM, Konstantin Shefov wrote: >>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ >>> >> >> The fix looks good for me. >> >> Thanks, >> Alexandr. >> >>> >>> On 08-Nov-12 16:44, Alexander Scherbatiy wrote: >>>> On 11/7/2012 6:59 PM, Konstantin Shefov wrote: >>>>> I made modifications you suggested. >>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ >>>>> >>>> >>>> Could you also fix the issue with the catched RuntimeException? >>>> All others looks good for me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Konstantin >>>>> >>>>> On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >>>>>> >>>>>> - The test needs to create and use Swing components only on EDT. >>>>>> The same is for JApplet (see >>>>>> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >>>>>> >>>>>> In the same way the following variable initialization is not >>>>>> correct because the JEditorPane is not created on the EDT: >>>>>> private JEditorPane jep = new JEditorPane(); >>>>>> >>>>>> - The test fails with the compilation error: cannot find symbol >>>>>> Util.blockTillDisplayed(jep); >>>>>> Use the toolkit realSync() method instead: >>>>>> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >>>>>> ... >>>>>> toolkit.realSync(); >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>>>>>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>>>>>> Looks fine to me. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review a fix for the issue: >>>>>>>>> >>>>>>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>>>>>> >>>>>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>>>>>> >>>>>>>>> It is suggested to move the test to open jdk. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Konstantin >>>>>>>>> >>>>>> >>>> >> -- Best regards, Sergey. From konstantin.shefov at oracle.com Fri Nov 9 13:26:43 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 09 Nov 2012 17:26:43 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509CF753.7080007@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> <509BA927.6020509@oracle.com> <509BB19D.20802@oracle.com> <509CC2E1.8090601@oracle.com> <509CC5FD.2020606@oracle.com> <509CF753.7080007@oracle.com> Message-ID: <509D0493.5010606@oracle.com> http://cr.openjdk.java.net/~kshefov/7147408/webrev.03/ On 09-Nov-12 16:30, Sergey Bylokhov wrote: > 09.11.2012 12:59, Konstantin Shefov wrote: >> Could you please look at this test fix? >> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ > Where finished and timer is used? > > 44 private Timer timer; > 46 private boolean finished = false; > > passed used in destroy method w/o synchronization. >> >> On 09-Nov-12 12:46, Alexander Scherbatiy wrote: >>> On 11/8/2012 5:20 PM, Konstantin Shefov wrote: >>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ >>>> >>> >>> The fix looks good for me. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 08-Nov-12 16:44, Alexander Scherbatiy wrote: >>>>> On 11/7/2012 6:59 PM, Konstantin Shefov wrote: >>>>>> I made modifications you suggested. >>>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ >>>>>> >>>>> >>>>> Could you also fix the issue with the catched RuntimeException? >>>>> All others looks good for me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> Konstantin >>>>>> >>>>>> On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> - The test needs to create and use Swing components only on EDT. >>>>>>> The same is for JApplet (see >>>>>>> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >>>>>>> >>>>>>> In the same way the following variable initialization is not >>>>>>> correct because the JEditorPane is not created on the EDT: >>>>>>> private JEditorPane jep = new JEditorPane(); >>>>>>> >>>>>>> - The test fails with the compilation error: cannot find symbol >>>>>>> Util.blockTillDisplayed(jep); >>>>>>> Use the toolkit realSync() method instead: >>>>>>> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >>>>>>> ... >>>>>>> toolkit.realSync(); >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>>>>>>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>>>>>>> Looks fine to me. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review a fix for the issue: >>>>>>>>>> >>>>>>>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>>>>>>> >>>>>>>>>> The webrev is >>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>>>>>>> >>>>>>>>>> It is suggested to move the test to open jdk. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Konstantin >>>>>>>>>> >>>>>>> >>>>> >>> > > From Sergey.Bylokhov at oracle.com Fri Nov 9 18:48:28 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 09 Nov 2012 22:48:28 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509D0493.5010606@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> <509BA927.6020509@oracle.com> <509BB19D.20802@oracle.com> <509CC2E1.8090601@oracle.com> <509CC5FD.2020606@oracle.com> <509CF753.7080007@oracle.com> <509D0493.5010606@oracle.com> Message-ID: <509D4FFC.20803@oracle.com> Hi, Konstantin. Fix looks good. 09.11.2012 17:26, Konstantin Shefov wrote: > http://cr.openjdk.java.net/~kshefov/7147408/webrev.03/ > > On 09-Nov-12 16:30, Sergey Bylokhov wrote: >> 09.11.2012 12:59, Konstantin Shefov wrote: >>> Could you please look at this test fix? >>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ >> Where finished and timer is used? >> >> 44 private Timer timer; >> 46 private boolean finished = false; >> >> passed used in destroy method w/o synchronization. >>> >>> On 09-Nov-12 12:46, Alexander Scherbatiy wrote: >>>> On 11/8/2012 5:20 PM, Konstantin Shefov wrote: >>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ >>>>> >>>> >>>> The fix looks good for me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> On 08-Nov-12 16:44, Alexander Scherbatiy wrote: >>>>>> On 11/7/2012 6:59 PM, Konstantin Shefov wrote: >>>>>>> I made modifications you suggested. >>>>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ >>>>>>> >>>>>> >>>>>> Could you also fix the issue with the catched RuntimeException? >>>>>> All others looks good for me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> Konstantin >>>>>>> >>>>>>> On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> - The test needs to create and use Swing components only on EDT. >>>>>>>> The same is for JApplet (see >>>>>>>> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >>>>>>>> >>>>>>>> In the same way the following variable initialization is not >>>>>>>> correct because the JEditorPane is not created on the EDT: >>>>>>>> private JEditorPane jep = new JEditorPane(); >>>>>>>> >>>>>>>> - The test fails with the compilation error: cannot find symbol >>>>>>>> Util.blockTillDisplayed(jep); >>>>>>>> Use the toolkit realSync() method instead: >>>>>>>> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >>>>>>>> ... >>>>>>>> toolkit.realSync(); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>>>>>>>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>>>>>>>> Looks fine to me. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for the issue: >>>>>>>>>>> >>>>>>>>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>>>>>>>> >>>>>>>>>>> The webrev is >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>>>>>>>> >>>>>>>>>>> It is suggested to move the test to open jdk. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Konstantin >>>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >> -- Best regards, Sergey. From peter.brunet at oracle.com Fri Nov 9 21:27:33 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 09 Nov 2012 15:27:33 -0600 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <509C2957.9070200@oracle.com> References: <509C2957.9070200@oracle.com> Message-ID: <509D7545.6020903@oracle.com> Please review the following fix planned for JDK8. Part of the fix will go into 7u12 under 7177111. Problem: In the process of evaluating 7177111 the following problems were noticed: - Both Component and JComponent have field "accessibleContext". In Component it is package-private and accessed by other classes from java.awt, but in JComponent it is protected and therefore this field hides the same superclass field from any subclass. These two fields should be refactored to a single protected field in Component. - Container.AccessibleAWTContainer has an addPropertyChangeListener but not a removePropertyChangeListener. This method is needed so stale listeners can be removed when AT are no longer attached to a Java process. - The JComponent.AccessibleJComponent.accessibleFocusHandler field functionally duplicates its superclass field, Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this field is used properly there are no logical issues. However, the existence of this field could cause confusion for a developer trying to understand the code. The superclass field is sufficient. Solution: - Change java.awt.Component.accessibleContext from package-private to protected. This will allow use by subclasses and the removal of the duplicate field in javax.swing.JComponent. - Add java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener so stale listeners can be removed when an Assistive Technology is no longer attached to a Java process. - Remove the protected field javax.swing.JComponent.accessibleContext. Instead the protected field java.awt.Component.accessibleContext, will be used. With the change subclasses would now use the protected field in the Component superclass. - Remove public method javax.swing.JComponent.getAccessibleContext. Instead it superclass public method java.awt.Component.getAccessibleContext method would be used. - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler field will be deprecated. Developers should use the java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler field instead. Webrev: http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 CCC: http://ccc.us.oracle.com/7179482 From shetyeakash at gmail.com Sun Nov 11 19:27:27 2012 From: shetyeakash at gmail.com (Akash Shetye) Date: Mon, 12 Nov 2012 00:57:27 +0530 Subject: Need some direction with regards to a college project (extracting component info from Swing engine?) Message-ID: Hey guys, I am planning to be able to extract component data and attributes of everything that Swing manages to be able to replicate them in HTML. (For example a swing JFrame with a JButton would be examined and its components i.e, JButton be drawn as a Button on an HTML page and this page can be communicated to the client.) This is purely a research/college project and I am looking for a "Yes you can, try this ....this " or "No its too complicated and cannot be done" kind of an answer. The functionality I want to achieve is something similar to AjaxSwing which is a proprietary solution. I would really appreciate to receive some directions with this regards. Please note I am willing get down and dirty with Open JDK and Swing to achieve this and will love to help around in contributions for Swing. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens.limasoftware at gmail.com Sun Nov 11 19:58:34 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 11 Nov 2012 20:58:34 +0100 Subject: Need some direction with regards to a college project (extracting component info from Swing engine?) In-Reply-To: References: Message-ID: 2012/11/11 Akash Shetye Hi Akash, > Hey guys, There are likely also some ladies on the list ;) > I am planning to be able to extract component data and attributes of > everything that Swing manages to be able to replicate them in HTML. (For > example a swing JFrame with a JButton would be examined and its components > i.e, JButton be drawn as a Button on an HTML page and this page can be > communicated to the client.) > It seems to me a lot of what you can achieve from CacioWeb too. This is basically a project to render Swing into an HTML 5 canvas. The website for the project is here: http://openjdk.java.net/projects/caciocavallo/ The website doc is not that useful, but you can give a try at the code (most is explained in the the README files) and see if it fits what you are trying to do. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Nov 12 08:43:45 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 12 Nov 2012 12:43:45 +0400 Subject: [8] Review request for 7147408 [macosx] Add autodelay to fix a regression test In-Reply-To: <509D0493.5010606@oracle.com> References: <508FBF32.7020308@oracle.com> <508FCB5B.20607@oracle.com> <5090F658.4000802@oracle.com> <5092816F.20006@oracle.com> <509A775F.7010305@oracle.com> <509BA927.6020509@oracle.com> <509BB19D.20802@oracle.com> <509CC2E1.8090601@oracle.com> <509CC5FD.2020606@oracle.com> <509CF753.7080007@oracle.com> <509D0493.5010606@oracle.com> Message-ID: <50A0B6C1.9060308@oracle.com> On 11/9/2012 5:26 PM, Konstantin Shefov wrote: > http://cr.openjdk.java.net/~kshefov/7147408/webrev.03/ The fix looks good for me. Thanks, Alexandr. > > On 09-Nov-12 16:30, Sergey Bylokhov wrote: >> 09.11.2012 12:59, Konstantin Shefov wrote: >>> Could you please look at this test fix? >>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ >> Where finished and timer is used? >> >> 44 private Timer timer; >> 46 private boolean finished = false; >> >> passed used in destroy method w/o synchronization. >>> >>> On 09-Nov-12 12:46, Alexander Scherbatiy wrote: >>>> On 11/8/2012 5:20 PM, Konstantin Shefov wrote: >>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.02/ >>>>> >>>> >>>> The fix looks good for me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> On 08-Nov-12 16:44, Alexander Scherbatiy wrote: >>>>>> On 11/7/2012 6:59 PM, Konstantin Shefov wrote: >>>>>>> I made modifications you suggested. >>>>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev.01/ >>>>>>> >>>>>> >>>>>> Could you also fix the issue with the catched RuntimeException? >>>>>> All others looks good for me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> Konstantin >>>>>>> >>>>>>> On 01-Nov-12 18:04, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> - The test needs to create and use Swing components only on EDT. >>>>>>>> The same is for JApplet (see >>>>>>>> http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). >>>>>>>> >>>>>>>> In the same way the following variable initialization is not >>>>>>>> correct because the JEditorPane is not created on the EDT: >>>>>>>> private JEditorPane jep = new JEditorPane(); >>>>>>>> >>>>>>>> - The test fails with the compilation error: cannot find symbol >>>>>>>> Util.blockTillDisplayed(jep); >>>>>>>> Use the toolkit realSync() method instead: >>>>>>>> SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); >>>>>>>> ... >>>>>>>> toolkit.realSync(); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> On 10/31/2012 1:58 PM, Konstantin Shefov wrote: >>>>>>>>> On 30-Oct-12 16:43, Anthony Petrov wrote: >>>>>>>>>> Looks fine to me. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 10/30/2012 3:51 PM, Konstantin Shefov wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for the issue: >>>>>>>>>>> >>>>>>>>>>> 7147408 [macosx] Add autodelay to fix a regression test >>>>>>>>>>> >>>>>>>>>>> The webrev is >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7147408/webrev/ >>>>>>>>>>> >>>>>>>>>>> It is suggested to move the test to open jdk. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Konstantin >>>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >> From alexandr.scherbatiy at oracle.com Mon Nov 12 13:31:55 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 12 Nov 2012 17:31:55 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50991E10.5090202@oracle.com> References: <50927965.3030402@oracle.com> <50991E10.5090202@oracle.com> Message-ID: <50A0FA4B.9010402@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8001423/webrev.01/ See my comments below: On 11/6/2012 6:26 PM, Denis S. Fokin wrote: > Hi Alexander, > > I found several places that could be improved, in my opinion. > > SimpleAttributeSet.java > 120 boolean result = true; > > I would not assign 'true' as a default value. If the 'names' > enumeration does not have any elements, we return true even not trying > to compare anything. We always check before that both attribute sets have the same count. So if the second attribute set is empty that means that the first set also empty. > > // Does not have elements, so returns true. > 123 while (result && names.hasMoreElements()) { That is ok. Comparing two empty attribute sets should return true because they are equal to each other. > > > MuxingAttributeSet.java > 130 for (int i = 0; i < as.length; i++) { > Why we do not use foreach loop here? Fixed. > > > AbstractDocument.java > 1874 && !(obj instanceof AbstractElement)) { > I am not an expert in Swing, so this check is not quite clear to me. > Why we check AbstractDocument.AbstractElement and do not check, for > instance, SimpleAttributeSet? Is it only because of "the old > AbstractElement behaviour"? There is a theory how to implement equals/hashCode methods correctly in Java. For example, If there is a class Point{ double x; double y; } the equals method can be: -------------------------------------------- public boolean equals(Object obj) { if (obj instanceof Point) { Point point = (Point) obj; return x == point.x && y == point.y; } return false; } -------------------------------------------- And there is a child class -------------------------------------------- class ColorPoint extends Point{ Color color; } -------------------------------------------- Point point = new Point(3,4); ColorPoint c = new ColorPoint(3, 4, Color.GREEN); ColorPoint bluePoint = new ColorPoint(3, 4, Color.BLUE); What we want that the greenPoint was different from the bluePoint. And we know that the check point.equals(greenPoint) returns true because Point 'equals' method checks only coordinates. So the ColorPoint equals method could look like: ----------------------------------------------- public boolean equals(Object obj) { if (obj instanceof ColorPoint) { return (((ColorPoint) obj).color == this.color) && super.equals(obj); } else if (obj instanceof Point) { return super.equals(obj); } return false; } ----------------------------------------------- The idea is that a child class should add an additional check for objects that have the same instance. The check 'if ((obj instanceof AttributeSet) && !(obj instanceof AbstractElement))' in the AbstractDocument has been added for the same reason. If an object is an instance of AbstractDocument we return just (this == obj) in other case if the object is and instance of AttributeSet we return isEqual((AttributeSet) obj). The theory also says that it is better to add 'isEqual' rather to override the 'equals' method because in the second case the hashCode method should be overriden accordingly and for mutable object it could have troubles. I decided to changed the fix to: - make the equals and isEqual method symmetrically - updated the hashCode method only if they were implemented And leave all others as is to not break the backward compatibility. > By the way, I would say that we should check for equality by reference > in the first place to get rid of comparing attributes if we call > equals method for the same object. Fixed. Thanks, Alexandr. > > Thank you, > Denis. > > > On 11/1/2012 5:30 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001423 >> webrev: http://cr.openjdk.java.net/~alexsch/8001423/webrev.00 >> >> The 'equals' method from the SmallAttributeSet class compares local >> attributes from the current set with all attributes (local and parent) >> from the second set if local counts are equal. >> So if we check the following text attributes: >> attr1: [ elem1 = value1] // getAttributeCount = 1 >> attr2: [ Parent = [ elem1 = value1] ] // getAttributeCount = 1 >> >> The results are: >> attr1.equals(attr2) = false // attr1 does not contain element with name >> Parent >> attr2.equals(attr1) = true // attr2 has element elem1 in the parent set >> >> All other classes that implement AttributeSet interface has the same >> problems with the hashcode/equals contract. >> >> The fix compares all local attributes from one set with all local >> attributes from the another set in the equals method. >> If both sets have parents, they will be compared automatically (in the >> same way as it was before). >> >> >> SimpleAttributeSet: Hashtable returns hashcode based on both keys and >> values. The fix redefines it to return a hash code only for values. >> MuxingAttributeSet: There is no direct way to get all local attributes. >> The getLocalAttribute method returns a value only if name is local. >> AbstractElement: If both attribute sets are AbstractElement they are >> compared by reference. In other case they are compared by checking local >> attributes. This preserves the old AbstractElement behaviour. >> >> The javax/swing/text/AttributeSet/8001423/bug8001423.java test is added. >> >> I run the javax/swing/text tests and there is no new failures after the >> fix. >> >> Thanks, >> Alexandr. >> > From anthony.petrov at oracle.com Mon Nov 12 13:53:11 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 12 Nov 2012 17:53:11 +0400 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <509D7545.6020903@oracle.com> References: <509C2957.9070200@oracle.com> <509D7545.6020903@oracle.com> Message-ID: <50A0FF47.7060608@oracle.com> Looks good to me. -- best regards, Anthony On 11/10/12 01:27, Pete Brunet wrote: > Please review the following fix planned for JDK8. Part of the fix will > go into 7u12 under 7177111. > > Problem: > In the process of evaluating 7177111 the following problems were noticed: > - Both Component and JComponent have field "accessibleContext". In > Component it is package-private and accessed by other classes from > java.awt, but in JComponent it is protected and therefore this field > hides the same superclass field from any subclass. These two fields > should be refactored to a single protected field in Component. > - Container.AccessibleAWTContainer has an addPropertyChangeListener but > not a removePropertyChangeListener. This method is needed so stale > listeners can be removed when AT are no longer attached to a Java process. > - The JComponent.AccessibleJComponent.accessibleFocusHandler field > functionally duplicates its superclass field, > Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this > field is used properly there are no logical issues. However, the > existence of this field could cause confusion for a developer trying to > understand the code. The superclass field is sufficient. > > Solution: > - Change java.awt.Component.accessibleContext from package-private to > protected. This will allow use by subclasses and the removal of the > duplicate field in javax.swing.JComponent. > - Add > java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener > so stale listeners can be removed when an Assistive Technology is no > longer attached to a Java process. > - Remove the protected field javax.swing.JComponent.accessibleContext. > Instead the protected field java.awt.Component.accessibleContext, will > be used. With the change subclasses would now use the protected field > in the Component superclass. > - Remove public method javax.swing.JComponent.getAccessibleContext. > Instead it superclass public method > java.awt.Component.getAccessibleContext method would be used. > - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler > field will be deprecated. Developers should use the > java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler > field instead. > > Webrev: http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 > CCC: http://ccc.us.oracle.com/7179482 From anthony.petrov at oracle.com Mon Nov 12 14:47:10 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 12 Nov 2012 18:47:10 +0400 Subject: Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners In-Reply-To: <509C2957.9070200@oracle.com> References: <509C2957.9070200@oracle.com> Message-ID: <50A10BEE.8080108@oracle.com> Looks fine. -- best regards, Anthony On 11/09/12 01:51, Pete Brunet wrote: > Hi Everyone, Please review the following fix planned for 7u12. It will > also go into 8 under 7179482. > > Problem: > When an AT (Assistive Technology) accesses a Java application with > several nested frames, too many property change listeners are added > resulting in a severe performance impact for an AT user. > > The issue is due to the fact that there is an accessibleContainerHandler > field in both javax.swing.JComponent.AccessibleJComponent and its > superclass, java.awt.Container.AccessibleAWTContainer. When an AT calls > JComponent.AccessibleJComponent.addPropertyChangeListener a handler is > new'd and assigned to its accessibleContainerHandler field and then the > same method in the superclass is called and it also new's and assigns a > handler to its accessibleContainerHandler field. Since there are two > handlers, when a child component is later added there are two callbacks > and for each one the AT will call addPropertyChangeListener, each of > which will add two handlers. For deeply nested trees the explosion of > events has a negative impact on performance, i.e. there are 2 handlers > added for the first level, 4 for the second level, 8 for the third > level, etc. > > Solution: > Remove protected field > javax.swing.JComponent.AccessibleJComponent.accessibleContainerHandler. > Instead, the protected field of the same name in > java.awt.Container.AWTAccessibleContainer will be used. > > Webrev: http://cr.openjdk.java.net/~ptbrunet/7177111/webrev.03/ > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177111 > http://monaco.us.oracle.com/detail.jsf?cr=7177111 > CCC: http://ccc.us.oracle.com/7177111 From artem.ananiev at oracle.com Mon Nov 12 20:00:30 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 12 Nov 2012 12:00:30 -0800 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <509D7545.6020903@oracle.com> References: <509C2957.9070200@oracle.com> <509D7545.6020903@oracle.com> Message-ID: <50A1555E.7020306@oracle.com> Hi, Pete, let me provide more information here. There are two different bugs about the same problem: 7177111: Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners 7179482: Component.accessibleContext and JComponent.accessibleContext refactoring 7177111 is targeted to 7u12, while 7179482 is for 8. The fix for 7u12 is a sub-set of the fix for 8. The webrevs are available here: http://cr.openjdk.java.net/~ptbrunet/7177111/webrev.03/ http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ The fix for 7177111 looks fine. The fix for 7179482 doesn't. Every time a PCL is added to a Component with addPropertyChangeListener(), we add the same Component/Container listener to Component.this. As the listener is the same, it's actually added only once. Now if one of PCLs is removed with a call to removePropertyChangeListener(), accessibleComponent/ContainerHandler is removed from Component.this, so all the rest PCLs will stop receiving notifications. Thanks, Artem On 11/9/2012 1:27 PM, Pete Brunet wrote: > Please review the following fix planned for JDK8. Part of the fix will > go into 7u12 under 7177111. > > Problem: > In the process of evaluating 7177111 the following problems were noticed: > - Both Component and JComponent have field "accessibleContext". In > Component it is package-private and accessed by other classes from > java.awt, but in JComponent it is protected and therefore this field > hides the same superclass field from any subclass. These two fields > should be refactored to a single protected field in Component. > - Container.AccessibleAWTContainer has an addPropertyChangeListener but > not a removePropertyChangeListener. This method is needed so stale > listeners can be removed when AT are no longer attached to a Java process. > - The JComponent.AccessibleJComponent.accessibleFocusHandler field > functionally duplicates its superclass field, > Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this > field is used properly there are no logical issues. However, the > existence of this field could cause confusion for a developer trying to > understand the code. The superclass field is sufficient. > > Solution: > - Change java.awt.Component.accessibleContext from package-private to > protected. This will allow use by subclasses and the removal of the > duplicate field in javax.swing.JComponent. > - Add > java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener > so stale listeners can be removed when an Assistive Technology is no > longer attached to a Java process. > - Remove the protected field javax.swing.JComponent.accessibleContext. > Instead the protected field java.awt.Component.accessibleContext, will > be used. With the change subclasses would now use the protected field > in the Component superclass. > - Remove public method javax.swing.JComponent.getAccessibleContext. > Instead it superclass public method > java.awt.Component.getAccessibleContext method would be used. > - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler > field will be deprecated. Developers should use the > java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler > field instead. > > Webrev: http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 > CCC: http://ccc.us.oracle.com/7179482 > From dingxmin at linux.vnet.ibm.com Tue Nov 13 07:53:51 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Tue, 13 Nov 2012 15:53:51 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <509BC7EE.7000801@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com> <509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com> Message-ID: <50A1FC8F.7060107@linux.vnet.ibm.com> Hi Alexandr, As for your comment "Could you create an issue that a JComboBox.setModel(null) call throws NPE? You could fix it before the 7189299 issue. ", I created a bug with internal review ID of 2381499 on JComboBox.setModel(null). But test shows that JPasswordField.setDocument(null), JTextField.setDocument(null), JList.setModel(null) and JTextArea.setDocument(null) all throw NPE. Particularly, JList.setModel(null) has null check and throws IllegalArgumentException("model" must be non null"). Shall I include those components as well? Thanks for your guidance in advance. Best regards, Frank On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote: > On 11/7/2012 10:56 AM, Frank Ding wrote: >> Hi Alexandr, >> Unfortunately, all the JComponents involved in >> FormView.createComponent() have bugs! >> I have done tests for all other swing components, i.e. JCheckBox, >> JRadioButton, JPasswordField, JTextField, JList, JComboBox and >> JTextField. Sadder news is that if we fix all components in the same >> way as I did for JButton, we need to subclass them all, resulting in >> JCheckBoxWrapper, JRadioButtonWrapper, JPasswordFieldWrapper, >> JTextFieldWrapper, JListWrapper, JComboBoxWrapper, JTextFieldWrapper >> plus JButtonWrapper! This approach becomes unacceptable when all >> swing components are affected. >> Shall we fix it in other way illustrated below? >> 1. Whenever a swing component is created, it is kept in AttributeSet, >> as what is now for model. >> 2. In FormView.createComponent(), the old swing component can be >> retrieved via attr.getAttribute(StyleConstants.ComponentAttribute). >> Note that ComponentAttribute is newly added. > This way should be carefully investigated that it does not > introduce new memory leaks. > Could you also check that the StyleConstants.ComponentAttribute > property value can't be rewritten by the JDK code or by public methods. > >> 3. Before setting shared model to a newly initialized swing >> component, call oldComp.setModel(null), delegating deregistration to >> setModel method. >> 4. Seems some setModel such as AbstractButton.setModel() can function >> well when the param, new model, is null while JComboBox.setModel() >> will throw NPE in case of null param. > Could you create an issue that a JComboBox.setModel(null) call > throws NPE? You could fix it before the 7189299 issue. > > Thanks, > Alexandr. > >> 5. Add null check code in those problematic setModel or setDocument >> methods. >> >> Any idea is appreciated. Thanks. >> >> Best regards, >> Frank >> >> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote: >>> On 11/5/2012 11:20 AM, Frank Ding wrote: >>>> Hi Alexander, >>>> Based on your comments last time, I refined my patch of v6 and >>>> offered v7 @ >>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ >>> >>> This version of the fix looks good for me. >>> It seems that it is the only good way to check that a button >>> model contains AbstarctButton.Handler listener. >>> >>> Could you also check that others models used in the >>> createComponent() method do not have such memory leaks (even the NPE >>> is not thrown)? >>> >>>> 4. Could you add the check that the action listener is invoked >>>> only once after a component tree updating and the action does the >>>> same that it does before a component tree updating? >>>> Answer: I am afraid I could not make it in the auto test >>>> (bug7189299.java) but I can achieve it to some degree in manual >>>> test FormSubmit, the one you illustrated below. >>>> My idea of checking it in FormSubmit.java is subclassing >>>> JEditorPane and overriding 'public EditorKit getEditorKit()' where >>>> stack traces can be examined in the overridden method to make sure >>>> FormView.submitData occurs only once. This approach works because >>>> FormView.submitData() calls JEditorPane.getEditorKit but is >>>> tricky. However, it's the only way I can think of without any >>>> additional framework support. If you are in favor of adding the >>>> check in FormSubmit.java, I am willing to do that. >>> >>> At least a separated manual test can be added that asks a user >>> to put a response.html file to a server and according to the server >>> url checks that JTeditor pane show the response text after a button >>> pressing. >>> >>> html = new JEditorPane("text/html", >>> "
" >>> + ">> value=\"submit\"/>" >>> + "
"); >>> >>> response.html: >>> Hello World! >>> >>> Thanks, >>> Alexandr. >>> >>>> Thanks again for all your comments and your support. Once again, >>>> if you have any further concern or comment, please don't hesitate >>>> to let me know. >>>> >>>> Best regards, >>>> Frank >>>> >>>> >>>> On 11/1/2012 8:08 PM, Alexander Scherbatiy wrote: >>>>> On 11/1/2012 10:35 AM, Frank Ding wrote: >>>>>> Hi Alexandr, >>>>>> Thanks for your review. The problem that the JButton does not >>>>>> release itself as you mentioned is, after taking closer look at >>>>>> relevant code again, that I removed instance >>>>>> AbstractButton.Handler as change listener where repainting the >>>>>> button press animation is defined. So this time I get around >>>>>> this issue and here comes v6 patch @ >>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ >>>>>> >>>>>> Below are answers to what you have raised in previous email. >>>>>> 1. if ( if (!listener.equals(this)) { that 'this' means the >>>>>> JButtonWrapper instead of an action listener. >>>>>> 'this' refers to JButtonWrapper.this because the closest class >>>>>> definition is JButtonWrapper. I also verified it during my >>>>>> debugging. >>>>> >>>>> Could you give an example there this check is useful? It seems >>>>> that the JButtonWrapper does not implement ActionListener >>>>> interface and so the listener and the this always should not be >>>>> equal. >>>>> >>>>> >>>>> I dumped action listeners from the button and model before the >>>>> fix and after it. >>>>> Before the fix the button has the latest FormView listener and >>>>> the model has AbstractButton$Handler added each time after a >>>>> component input creation. >>>>> After the fix both the button and the model have the FormView >>>>> listener and the button does not have the AbstractButton$Handler. >>>>> Could you preserve the listeners location and just remove old >>>>> listeners from the model? >>>>> >>>>> The fix sets the model to the JButtonWrapper first and than >>>>> removes unneccessary listeners from the model. Is it possible to >>>>> rearrange order of these operations? >>>>> >>>>> I see that you check number of the listeners in the test. Could >>>>> you add the check that the action listener is invoked only once >>>>> after a component tree updating and >>>>> the action does the same that it does before a component tree >>>>> updating. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> 2. Why are two FormViews created in this sample? >>>>>> SwingUtilities.updateComponentTreeUI() triggers html View >>>>>> hierarchy to update by instantiating new UI instances involved in >>>>>> the html form. It could have been avoided to have 2 View >>>>>> instances but we are restricted to current design that LF change >>>>>> causes creation of View instance which further leads to creation >>>>>> of new UI instances. Creation of new UI instances upon LF change >>>>>> can be referenced in BasicTextUI.modelChanged(). >>>>>> >>>>>> 3. Why are there 2 listeners added to the button model in this >>>>>> sample? >>>>>> The issue is caused by combination of the 2 factors. First, a >>>>>> shared ButtonModel is created per html Element. Second, >>>>>> JButton.setModel() automatically registers its private Handler in >>>>>> the new model but no way to deregister it. The first is a design >>>>>> choice but the second is a design flaw. Consequence is that the >>>>>> shared ButtonModel instance bears more and more JButton.Handler. >>>>>> >>>>>> I think v6 patch is promising as a final fix. If you have any >>>>>> further concern or comment, please don't hesitate to let me know. >>>>>> Thanks again for your careful review. >>>>>> >>>>>> Best regards, >>>>>> Frank >>>>>> >>>>>> On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >>>>>>> Hi Frank, >>>>>>> >>>>>>> I tried your V5 patch and run the test described in the issue >>>>>>> (see below). >>>>>>> I pressed the button and it does not release. This is because >>>>>>> the AbstractButton.Handler listener is removed because of the fix. >>>>>>> You could check the line >>>>>>> 941 if (!listener.equals(this)) { >>>>>>> that 'this' means the JButtonWrapper instead of an action listener. >>>>>>> >>>>>>> Could you also look deeper in the code and say why two FormViews >>>>>>> are created (and each adds it's own listener to the button >>>>>>> model) in this sample? >>>>>>> >>>>>>> ----------------------------------------------- >>>>>>> import java.awt.*; >>>>>>> import javax.swing.*; >>>>>>> >>>>>>> public class FormSubmit { >>>>>>> >>>>>>> public static void main(String[] args) throws Exception { >>>>>>> SwingUtilities.invokeAndWait(new Runnable() { >>>>>>> >>>>>>> @Override >>>>>>> public void run() { >>>>>>> >>>>>>> JEditorPane html = new JEditorPane("text/html", >>>>>>> "
>>>>>> type=\"submit\" value=\"Submit\">
"); >>>>>>> JFrame frame = new JFrame() >>>>>>> frame.setLayout(new BorderLayout()); >>>>>>> frame.add(html, BorderLayout.CENTER); >>>>>>> frame.setSize(200, 100); >>>>>>> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >>>>>>> frame.setVisible(true); // Uncomment this line >>>>>>> to see the Exception on JDK 7 >>>>>>> SwingUtilities.updateComponentTreeUI(html); >>>>>>> } >>>>>>> }); >>>>>>> } >>>>>>> } >>>>>>> ----------------------------------------------- >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Nov 13 11:49:06 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 13 Nov 2012 15:49:06 +0400 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50A1FC8F.7060107@linux.vnet.ibm.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com> <509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com> <50A1FC8F.7060107@linux.vnet.ibm.com> Message-ID: <50A233B2.5020602@oracle.com> On 11/13/2012 11:53 AM, Frank Ding wrote: > Hi Alexandr, > As for your comment "Could you create an issue that a > JComboBox.setModel(null) call throws NPE? You could fix it before the > 7189299 issue. ", I created a bug with internal review ID of 2381499 > on JComboBox.setModel(null). But test shows that > JPasswordField.setDocument(null), JTextField.setDocument(null), > JList.setModel(null) and JTextArea.setDocument(null) all throw NPE. > Particularly, JList.setModel(null) has null check and throws > IllegalArgumentException("model" must be non null"). Shall I include > those components as well? There is the javadoc for the JList setModel() method: Throws IllegalArgumentException - if model is null. So it is undesirable to change the public API. However, it is possible to set a new empty model for the JList. The list listeners should be removed from the old model in this case. You could have only 2 issues: one for components that allow to set a null model but throws NPE (like JComboBox) and another for components that does not allow to set null model but they do not remove listeners from the old model in case if a new model is set. Thanks, Alexandr. > Thanks for your guidance in advance. > > Best regards, > Frank > > On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote: >> On 11/7/2012 10:56 AM, Frank Ding wrote: >>> Hi Alexandr, >>> Unfortunately, all the JComponents involved in >>> FormView.createComponent() have bugs! >>> I have done tests for all other swing components, i.e. JCheckBox, >>> JRadioButton, JPasswordField, JTextField, JList, JComboBox and >>> JTextField. Sadder news is that if we fix all components in the same >>> way as I did for JButton, we need to subclass them all, resulting in >>> JCheckBoxWrapper, JRadioButtonWrapper, JPasswordFieldWrapper, >>> JTextFieldWrapper, JListWrapper, JComboBoxWrapper, JTextFieldWrapper >>> plus JButtonWrapper! This approach becomes unacceptable when all >>> swing components are affected. >>> Shall we fix it in other way illustrated below? >>> 1. Whenever a swing component is created, it is kept in >>> AttributeSet, as what is now for model. >>> 2. In FormView.createComponent(), the old swing component can be >>> retrieved via attr.getAttribute(StyleConstants.ComponentAttribute). >>> Note that ComponentAttribute is newly added. >> This way should be carefully investigated that it does not >> introduce new memory leaks. >> Could you also check that the StyleConstants.ComponentAttribute >> property value can't be rewritten by the JDK code or by public methods. >> >>> 3. Before setting shared model to a newly initialized swing >>> component, call oldComp.setModel(null), delegating deregistration to >>> setModel method. >>> 4. Seems some setModel such as AbstractButton.setModel() can >>> function well when the param, new model, is null while >>> JComboBox.setModel() will throw NPE in case of null param. >> Could you create an issue that a JComboBox.setModel(null) call >> throws NPE? You could fix it before the 7189299 issue. >> >> Thanks, >> Alexandr. >> >>> 5. Add null check code in those problematic setModel or setDocument >>> methods. >>> >>> Any idea is appreciated. Thanks. >>> >>> Best regards, >>> Frank >>> >>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote: >>>> On 11/5/2012 11:20 AM, Frank Ding wrote: >>>>> Hi Alexander, >>>>> Based on your comments last time, I refined my patch of v6 and >>>>> offered v7 @ >>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ >>>> >>>> This version of the fix looks good for me. >>>> It seems that it is the only good way to check that a button >>>> model contains AbstarctButton.Handler listener. >>>> >>>> Could you also check that others models used in the >>>> createComponent() method do not have such memory leaks (even the >>>> NPE is not thrown)? >>>> >>>>> 4. Could you add the check that the action listener is invoked >>>>> only once after a component tree updating and the action does the >>>>> same that it does before a component tree updating? >>>>> Answer: I am afraid I could not make it in the auto test >>>>> (bug7189299.java) but I can achieve it to some degree in manual >>>>> test FormSubmit, the one you illustrated below. >>>>> My idea of checking it in FormSubmit.java is subclassing >>>>> JEditorPane and overriding 'public EditorKit getEditorKit()' where >>>>> stack traces can be examined in the overridden method to make sure >>>>> FormView.submitData occurs only once. This approach works because >>>>> FormView.submitData() calls JEditorPane.getEditorKit but is >>>>> tricky. However, it's the only way I can think of without any >>>>> additional framework support. If you are in favor of adding the >>>>> check in FormSubmit.java, I am willing to do that. >>>> >>>> At least a separated manual test can be added that asks a >>>> user to put a response.html file to a server and according to the >>>> server url checks that JTeditor pane show the response text after a >>>> button pressing. >>>> >>>> html = new JEditorPane("text/html", >>>> "
" >>>> + ">>> value=\"submit\"/>" >>>> + "
"); >>>> >>>> response.html: >>>> Hello World! >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> Thanks again for all your comments and your support. Once >>>>> again, if you have any further concern or comment, please don't >>>>> hesitate to let me know. >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> >>>>> On 11/1/2012 8:08 PM, Alexander Scherbatiy wrote: >>>>>> On 11/1/2012 10:35 AM, Frank Ding wrote: >>>>>>> Hi Alexandr, >>>>>>> Thanks for your review. The problem that the JButton does not >>>>>>> release itself as you mentioned is, after taking closer look at >>>>>>> relevant code again, that I removed instance >>>>>>> AbstractButton.Handler as change listener where repainting the >>>>>>> button press animation is defined. So this time I get around >>>>>>> this issue and here comes v6 patch @ >>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.06/ >>>>>>> >>>>>>> Below are answers to what you have raised in previous email. >>>>>>> 1. if ( if (!listener.equals(this)) { that 'this' means the >>>>>>> JButtonWrapper instead of an action listener. >>>>>>> 'this' refers to JButtonWrapper.this because the closest class >>>>>>> definition is JButtonWrapper. I also verified it during my >>>>>>> debugging. >>>>>> >>>>>> Could you give an example there this check is useful? It >>>>>> seems that the JButtonWrapper does not implement ActionListener >>>>>> interface and so the listener and the this always should not be >>>>>> equal. >>>>>> >>>>>> >>>>>> I dumped action listeners from the button and model before the >>>>>> fix and after it. >>>>>> Before the fix the button has the latest FormView listener and >>>>>> the model has AbstractButton$Handler added each time after a >>>>>> component input creation. >>>>>> After the fix both the button and the model have the FormView >>>>>> listener and the button does not have the AbstractButton$Handler. >>>>>> Could you preserve the listeners location and just remove old >>>>>> listeners from the model? >>>>>> >>>>>> The fix sets the model to the JButtonWrapper first and than >>>>>> removes unneccessary listeners from the model. Is it possible to >>>>>> rearrange order of these operations? >>>>>> >>>>>> I see that you check number of the listeners in the test. >>>>>> Could you add the check that the action listener is invoked only >>>>>> once after a component tree updating and >>>>>> the action does the same that it does before a component tree >>>>>> updating. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> 2. Why are two FormViews created in this sample? >>>>>>> SwingUtilities.updateComponentTreeUI() triggers html View >>>>>>> hierarchy to update by instantiating new UI instances involved >>>>>>> in the html form. It could have been avoided to have 2 View >>>>>>> instances but we are restricted to current design that LF change >>>>>>> causes creation of View instance which further leads to creation >>>>>>> of new UI instances. Creation of new UI instances upon LF >>>>>>> change can be referenced in BasicTextUI.modelChanged(). >>>>>>> >>>>>>> 3. Why are there 2 listeners added to the button model in this >>>>>>> sample? >>>>>>> The issue is caused by combination of the 2 factors. First, a >>>>>>> shared ButtonModel is created per html Element. Second, >>>>>>> JButton.setModel() automatically registers its private Handler >>>>>>> in the new model but no way to deregister it. The first is a >>>>>>> design choice but the second is a design flaw. Consequence is >>>>>>> that the shared ButtonModel instance bears more and more >>>>>>> JButton.Handler. >>>>>>> >>>>>>> I think v6 patch is promising as a final fix. If you have any >>>>>>> further concern or comment, please don't hesitate to let me >>>>>>> know. Thanks again for your careful review. >>>>>>> >>>>>>> Best regards, >>>>>>> Frank >>>>>>> >>>>>>> On 10/30/2012 9:38 PM, Alexander Scherbatiy wrote: >>>>>>>> Hi Frank, >>>>>>>> >>>>>>>> I tried your V5 patch and run the test described in the issue >>>>>>>> (see below). >>>>>>>> I pressed the button and it does not release. This is because >>>>>>>> the AbstractButton.Handler listener is removed because of the fix. >>>>>>>> You could check the line >>>>>>>> 941 if (!listener.equals(this)) { >>>>>>>> that 'this' means the JButtonWrapper instead of an action >>>>>>>> listener. >>>>>>>> >>>>>>>> Could you also look deeper in the code and say why two >>>>>>>> FormViews are created (and each adds it's own listener to the >>>>>>>> button model) in this sample? >>>>>>>> >>>>>>>> ----------------------------------------------- >>>>>>>> import java.awt.*; >>>>>>>> import javax.swing.*; >>>>>>>> >>>>>>>> public class FormSubmit { >>>>>>>> >>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>> SwingUtilities.invokeAndWait(new Runnable() { >>>>>>>> >>>>>>>> @Override >>>>>>>> public void run() { >>>>>>>> >>>>>>>> JEditorPane html = new JEditorPane("text/html", >>>>>>>> "
>>>>>>> type=\"submit\" value=\"Submit\">
"); >>>>>>>> JFrame frame = new JFrame() >>>>>>>> frame.setLayout(new BorderLayout()); >>>>>>>> frame.add(html, BorderLayout.CENTER); >>>>>>>> frame.setSize(200, 100); >>>>>>>> frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE); >>>>>>>> frame.setVisible(true); // Uncomment this line >>>>>>>> to see the Exception on JDK 7 >>>>>>>> SwingUtilities.updateComponentTreeUI(html); >>>>>>>> } >>>>>>>> }); >>>>>>>> } >>>>>>>> } >>>>>>>> ----------------------------------------------- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>> >>>> >>> >> > From dingxmin at linux.vnet.ibm.com Wed Nov 14 06:22:45 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 14 Nov 2012 14:22:45 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50A233B2.5020602@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com> <509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com> <50A1FC8F.7060107@linux.vnet.ibm.com> <50A233B2.5020602@oracle.com> Message-ID: <50A338B5.7070302@linux.vnet.ibm.com> Hi Alexandr, After a couple of hours investigating the possibility of fixing JComboBox.setModel(null) and JTextComponent.setComponent(null), I found that 1. In JComboBox.setModel, the new model, null in this case, is eventually passed to BasicComboPopup.propertyChange where JList.setModel is called. JList.setModel rejects the null model because of its api restriction. Below I listed the offending call stacks in my IDE. This makes sense as the associated drop down JList needs new model. However, it makes fixing JComboBox.setModel(null) hard or impossible. Exception in thread "main" java.lang.IllegalArgumentException: model must be non null at javax.swing.JList.setModel(JList.java:1674) at javax.swing.plaf.basic.BasicComboPopup$Handler.propertyChange(BasicComboPopup.java:939) at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263) at java.awt.Component.firePropertyChange(Component.java:8413) at javax.swing.JComboBox.setModel(JComboBox.java:322) 2. JTextComponent.setComponent(null) can be fixed but code change in BasicTextUI is also required. Since setting null model to JComboBox, JList and JTextComponent is impossible or dangerous, just as you mentioned, we could set a non null new model to these UI components just for the purpose of having the side effect of removing listeners from old model. Are you ok with this approach? By the way, I will investigate your another question "Could you also check that the StyleConstants.ComponentAttribute property value can't be rewritten by the JDK code or by public methods." and reply soon. Best regards, Frank On 11/13/2012 7:49 PM, Alexander Scherbatiy wrote: > On 11/13/2012 11:53 AM, Frank Ding wrote: >> Hi Alexandr, >> As for your comment "Could you create an issue that a >> JComboBox.setModel(null) call throws NPE? You could fix it before the >> 7189299 issue. ", I created a bug with internal review ID of 2381499 >> on JComboBox.setModel(null). But test shows that >> JPasswordField.setDocument(null), JTextField.setDocument(null), >> JList.setModel(null) and JTextArea.setDocument(null) all throw NPE. >> Particularly, JList.setModel(null) has null check and throws >> IllegalArgumentException("model" must be non null"). Shall I include >> those components as well? > > There is the javadoc for the JList setModel() method: Throws > IllegalArgumentException - if model is null. So it is undesirable to > change the public API. > However, it is possible to set a new empty model for the JList. > The list listeners should be removed from the old model in this case. > > You could have only 2 issues: one for components that allow to set > a null model but throws NPE (like JComboBox) and another for > components that does not allow to set null model but they do not > remove listeners from the old model in case if a new model is set. > > Thanks, > Alexandr. > >> Thanks for your guidance in advance. >> >> Best regards, >> Frank >> >> On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote: >>> On 11/7/2012 10:56 AM, Frank Ding wrote: >>>> Hi Alexandr, >>>> Unfortunately, all the JComponents involved in >>>> FormView.createComponent() have bugs! >>>> I have done tests for all other swing components, i.e. JCheckBox, >>>> JRadioButton, JPasswordField, JTextField, JList, JComboBox and >>>> JTextField. Sadder news is that if we fix all components in the >>>> same way as I did for JButton, we need to subclass them all, >>>> resulting in JCheckBoxWrapper, JRadioButtonWrapper, >>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, >>>> JComboBoxWrapper, JTextFieldWrapper plus JButtonWrapper! This >>>> approach becomes unacceptable when all swing components are affected. >>>> Shall we fix it in other way illustrated below? >>>> 1. Whenever a swing component is created, it is kept in >>>> AttributeSet, as what is now for model. >>>> 2. In FormView.createComponent(), the old swing component can be >>>> retrieved via >>>> attr.getAttribute(StyleConstants.ComponentAttribute). Note that >>>> ComponentAttribute is newly added. >>> This way should be carefully investigated that it does not >>> introduce new memory leaks. >>> Could you also check that the >>> StyleConstants.ComponentAttribute property value can't be rewritten >>> by the JDK code or by public methods. >>> >>>> 3. Before setting shared model to a newly initialized swing >>>> component, call oldComp.setModel(null), delegating deregistration >>>> to setModel method. >>>> 4. Seems some setModel such as AbstractButton.setModel() can >>>> function well when the param, new model, is null while >>>> JComboBox.setModel() will throw NPE in case of null param. >>> Could you create an issue that a JComboBox.setModel(null) call >>> throws NPE? You could fix it before the 7189299 issue. >>> >>> Thanks, >>> Alexandr. >>> >>>> 5. Add null check code in those problematic setModel or setDocument >>>> methods. >>>> >>>> Any idea is appreciated. Thanks. >>>> >>>> Best regards, >>>> Frank >>>> >>>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote: >>>>> On 11/5/2012 11:20 AM, Frank Ding wrote: >>>>>> Hi Alexander, >>>>>> Based on your comments last time, I refined my patch of v6 and >>>>>> offered v7 @ >>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ >>>>> >>>>> This version of the fix looks good for me. >>>>> It seems that it is the only good way to check that a button >>>>> model contains AbstarctButton.Handler listener. >>>>> >>>>> Could you also check that others models used in the >>>>> createComponent() method do not have such memory leaks (even the >>>>> NPE is not thrown)? >>>>> >>>>>> 4. Could you add the check that the action listener is invoked >>>>>> only once after a component tree updating and the action does the >>>>>> same that it does before a component tree updating? >>>>>> Answer: I am afraid I could not make it in the auto test >>>>>> (bug7189299.java) but I can achieve it to some degree in manual >>>>>> test FormSubmit, the one you illustrated below. >>>>>> My idea of checking it in FormSubmit.java is subclassing >>>>>> JEditorPane and overriding 'public EditorKit getEditorKit()' >>>>>> where stack traces can be examined in the overridden method to >>>>>> make sure FormView.submitData occurs only once. This approach >>>>>> works because FormView.submitData() calls >>>>>> JEditorPane.getEditorKit but is tricky. However, it's the only >>>>>> way I can think of without any additional framework support. If >>>>>> you are in favor of adding the check in FormSubmit.java, I am >>>>>> willing to do that. >>>>> >>>>> At least a separated manual test can be added that asks a >>>>> user to put a response.html file to a server and according to the >>>>> server url checks that JTeditor pane show the response text after >>>>> a button pressing. >>>>> >>>>> html = new JEditorPane("text/html", >>>>> "
" >>>>> + ">>>> value=\"submit\"/>" >>>>> + "
"); >>>>> >>>>> response.html: >>>>> Hello World! >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> Thanks again for all your comments and your support. Once >>>>>> again, if you have any further concern or comment, please don't >>>>>> hesitate to let me know. >>>>>> >>>>>> Best regards, >>>>>> Frank >>>>>> From konstantin.shefov at oracle.com Wed Nov 14 11:53:07 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 14 Nov 2012 15:53:07 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <509CC335.2010908@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> Message-ID: <50A38623.6090709@oracle.com> Sergey, please, review the fix, and if it is good, please, push it to WS. Konstantin On 09-Nov-12 12:47, Alexander Scherbatiy wrote: > On 11/8/2012 4:25 PM, Konstantin Shefov wrote: >> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ >> > > The fix looks good for me. > > Thanks, > Alexandr. > >> >> On 08-Nov-12 16:02, Alexander Scherbatiy wrote: >>> On 11/7/2012 7:00 PM, Konstantin Shefov wrote: >>>> Please, look at modified fix: >>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ >>>> >>> >>> Try/catch block in the main method catches RuntimeException as >>> well. So the jtreg passes the test even it really fails. >>> It is also a good idea to fail the test if the >>> SwingUtilities.invokeAndWait() throws an exception because it is >>> also a wrong situation. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >>>>> >>>>> - Please, remove comments and unnecessary System.out from the fix >>>>> - Create and check swing components on EDT. Avoiding this rule >>>>> can leads to unpredictable test failures. >>>>> - Swing tests usually have bugBugID.java or some meaningful name. >>>>> - It is better to use the swing-dev at openjdk.java.net alias to >>>>> review the swing tests. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for the issue: >>>>>> >>>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the >>>>>> range: [NORTH, SOUTH] >>>>>> >>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>>>>> >>>>>> It is suggested to move the test to open jdk. >>>>>> >>>>>> Thanks, >>>>>> Konstantin >>>>>> >>>>> >>> > From peter.brunet at oracle.com Wed Nov 14 15:30:08 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 14 Nov 2012 09:30:08 -0600 Subject: Fwd: Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners In-Reply-To: <509C2957.9070200@oracle.com> References: <509C2957.9070200@oracle.com> Message-ID: <50A3B900.6070307@oracle.com> Could someone from the Swing team please review this? -------- Original Message -------- Subject: Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners Date: Thu, 08 Nov 2012 15:51:19 -0600 From: Pete Brunet Reply-To: peter.brunet at oracle.com To: awt-dev , swing-dev at openjdk.java.net Hi Everyone, Please review the following fix planned for 7u12. It will also go into 8 under 7179482. Problem: When an AT (Assistive Technology) accesses a Java application with several nested frames, too many property change listeners are added resulting in a severe performance impact for an AT user. The issue is due to the fact that there is an accessibleContainerHandler field in both javax.swing.JComponent.AccessibleJComponent and its superclass, java.awt.Container.AccessibleAWTContainer. When an AT calls JComponent.AccessibleJComponent.addPropertyChangeListener a handler is new'd and assigned to its accessibleContainerHandler field and then the same method in the superclass is called and it also new's and assigns a handler to its accessibleContainerHandler field. Since there are two handlers, when a child component is later added there are two callbacks and for each one the AT will call addPropertyChangeListener, each of which will add two handlers. For deeply nested trees the explosion of events has a negative impact on performance, i.e. there are 2 handlers added for the first level, 4 for the second level, 8 for the third level, etc. Solution: Remove protected field javax.swing.JComponent.AccessibleJComponent.accessibleContainerHandler. Instead, the protected field of the same name in java.awt.Container.AWTAccessibleContainer will be used. Webrev: http://cr.openjdk.java.net/~ptbrunet/7177111/webrev.03/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177111 http://monaco.us.oracle.com/detail.jsf?cr=7177111 CCC: http://ccc.us.oracle.com/7177111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin.shefov at oracle.com Wed Nov 14 15:39:24 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 14 Nov 2012 19:39:24 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <509CC335.2010908@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> Message-ID: <50A3BB2C.3000409@oracle.com> Could you please look at this test fix? Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ It was test for Metal LaF, so I forced LaF to be Metal even on MacOS. Now the test passes on MacOSX. I also made Swing methods run on EDT. Test can be moved to OpenJDK as it is already in OpenJDK 6. Thanks, Konstantin From denis.fokin at oracle.com Wed Nov 14 18:31:42 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Wed, 14 Nov 2012 22:31:42 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50A0FA4B.9010402@oracle.com> References: <50927965.3030402@oracle.com> <50991E10.5090202@oracle.com> <50A0FA4B.9010402@oracle.com> Message-ID: <50A3E38E.8050806@oracle.com> Hi Alexander, my thoughts are below 1. I see the next scenario // 'this' contains 3 attributes // 'attr' does not contain attributes 925 boolean result = true; 926 927 Enumeration names = attr.getAttributeNames(); // 'names' is an empty enumeration // by this reason we do not get into the loop 928 while (result && names.hasMoreElements()) { 929 Object name = names.nextElement(); 930 result = attr.getAttribute(name).equals(getLocalAttribute(name)); 931 } // three attributes is not the same as no attributes // but we have not changed the default value of the // result variable, so return true. 932 933 return result; 2. You have removed the next code form the SimpleAttributeSet.java file 305 if (this == obj) { 306 return true; 307 } I suggest the next checks in the beginning of each equals method a.) return false if the parameter is null b.) return false if a class of the parameter differs from expected one (in general case is not an instance of AttributeSet) c.) return true if the objects are equal by reference 4. By contrast with StyleContext.SmallAttributeSet.equals() we do not change anything in StyleContext.NamedStyle.equals() StyleContext.java 1431 /** 1432 * Checks whether two attribute sets are equal. 1433 * 1434 * @param attr the attribute set to check against 1435 * @return true if the same 1436 * @see AttributeSet#isEqual 1437 */ 1438 public boolean isEqual(AttributeSet attr) { 1439 return attributes.isEqual(attr); 1440 } 5. In you current implementation we have a code duplication. This code is common for StyleContext.SmallAttributeSet, SimpleAttributeSet, MuxingAttributeSet (and may be for future NamedStyle). 921 if (getAttributeCount() != attr.getAttributeCount()) { 922 return false; 923 } 924 925 boolean result = true; 926 927 Enumeration names = attr.getAttributeNames(); 928 while (result && names.hasMoreElements()) { 929 Object name = names.nextElement(); 930 result = attr.getAttribute(name).equals(getLocalAttribute(name)); 931 } 932 933 return result; May be we should somehow reuse our code here? 6. In the next places we have different approaches for the comparison of attributes. - comparation of local attributes (StyleContext) - comparation of local attributes 'Approach #2' (MuxingAttributeSet) - comparation of attributes Is it intentional or it should be implemented the same way? StyleContext.java 920 private boolean isAttributeSetEqual(AttributeSet attr) { 921 if (getAttributeCount() != attr.getAttributeCount()) { 922 return false; 923 } 924 925 boolean result = true; 926 927 Enumeration names = attr.getAttributeNames(); 928 while (result && names.hasMoreElements()) { 929 Object name = names.nextElement(); 930 result = attr.getAttribute(name).equals(getLocalAttribute(name)); 931 } 932 933 return result; 934 } 795 Object getLocalAttribute(Object nm) { 796 if (nm == StyleConstants.ResolveAttribute) { 797 return resolveParent; 798 } 799 Object[] tbl = attributes; 800 for (int i = 0; i < tbl.length; i += 2) { 801 if (nm.equals(tbl[i])) { 802 return tbl[i+1]; 803 } 804 } 805 return null; 806 } MuxingAttributeSet.java 167 public boolean isEqual(AttributeSet attr) { 168 if (this == attr) { 169 return true; 170 } 171 172 if (getAttributeCount() != attr.getAttributeCount()) { 173 return false; 174 } 175 176 boolean result = true; 177 178 Enumeration names = attr.getAttributeNames(); 179 while (result && names.hasMoreElements()) { 180 Object name = names.nextElement(); 181 Object localAttribute = getLocalAttribute(name); 182 result = localAttribute != null && attr.getAttribute(name).equals(localAttribute); 183 } 184 185 return result; 186 } 188 private Object getLocalAttribute(Object name) { 189 for (AttributeSet as : getAttributes()) { 190 Enumeration names = as.getAttributeNames(); 191 while (names.hasMoreElements()) { 192 Object attributeName = names.nextElement(); 193 if (attributeName.equals(name)) { 194 return as.getAttribute(name); 195 } 196 } 197 } 198 return null; 199 } SimpleAttributeSet.java 115 public boolean isEqual(AttributeSet attr) { 116 if (this == attr) { 117 return true; 118 } 119 120 if (getAttributeCount() != attr.getAttributeCount()) { 121 return false; 122 } 123 124 boolean result = true; 125 126 Enumeration names = attr.getAttributeNames(); 127 while (result && names.hasMoreElements()) { 128 Object name = names.nextElement(); 129 result = attr.getAttribute(name).equals(table.get(name)); 130 } 131 132 return result; 133 } Thank you, Denis. On 11/12/2012 5:31 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8001423/webrev.01/ > > See my comments below: > > On 11/6/2012 6:26 PM, Denis S. Fokin wrote: >> Hi Alexander, >> >> I found several places that could be improved, in my opinion. >> >> SimpleAttributeSet.java >> 120 boolean result = true; >> >> I would not assign 'true' as a default value. If the 'names' >> enumeration does not have any elements, we return true even not trying >> to compare anything. > We always check before that both attribute sets have the same count. So > if the second attribute set is empty that means that the first set also > empty. > >> >> // Does not have elements, so returns true. >> 123 while (result && names.hasMoreElements()) { > That is ok. Comparing two empty attribute sets should return true > because they are equal to each other. >> >> >> MuxingAttributeSet.java >> 130 for (int i = 0; i < as.length; i++) { >> Why we do not use foreach loop here? > Fixed. >> >> >> AbstractDocument.java >> 1874 && !(obj instanceof AbstractElement)) { >> I am not an expert in Swing, so this check is not quite clear to me. >> Why we check AbstractDocument.AbstractElement and do not check, for >> instance, SimpleAttributeSet? Is it only because of "the old >> AbstractElement behaviour"? > There is a theory how to implement equals/hashCode methods correctly in > Java. > For example, If there is a class Point{ double x; double y; } the equals > method can be: > -------------------------------------------- > public boolean equals(Object obj) { > if (obj instanceof Point) { > Point point = (Point) obj; > return x == point.x && y == point.y; > } > return false; > } > -------------------------------------------- > > And there is a child class > -------------------------------------------- > class ColorPoint extends Point{ > Color color; > } > -------------------------------------------- > > Point point = new Point(3,4); > ColorPoint c = new ColorPoint(3, 4, Color.GREEN); > ColorPoint bluePoint = new ColorPoint(3, 4, Color.BLUE); > > What we want that the greenPoint was different from the bluePoint. > And we know that the check point.equals(greenPoint) returns true because > Point 'equals' method checks only coordinates. > > So the ColorPoint equals method could look like: > ----------------------------------------------- > public boolean equals(Object obj) { > if (obj instanceof ColorPoint) { > return (((ColorPoint) obj).color == this.color) && super.equals(obj); > } else if (obj instanceof Point) { > return super.equals(obj); > } > return false; > } > ----------------------------------------------- > The idea is that a child class should add an additional check for > objects that have the same instance. > > The check 'if ((obj instanceof AttributeSet) && !(obj instanceof > AbstractElement))' in the AbstractDocument has been added for the same > reason. > If an object is an instance of AbstractDocument we return just (this == > obj) in other case if the object is and instance of AttributeSet we > return isEqual((AttributeSet) obj). > > The theory also says that it is better to add 'isEqual' rather to > override the 'equals' method because in the second case > the hashCode method should be overriden accordingly and for mutable > object it could have troubles. > > > I decided to changed the fix to: > - make the equals and isEqual method symmetrically > - updated the hashCode method only if they were implemented > > And leave all others as is to not break the backward compatibility. > >> By the way, I would say that we should check for equality by reference >> in the first place to get rid of comparing attributes if we call >> equals method for the same object. > > Fixed. > > Thanks, > Alexandr. >> >> Thank you, >> Denis. >> >> >> On 11/1/2012 5:30 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001423 >>> webrev: http://cr.openjdk.java.net/~alexsch/8001423/webrev.00 >>> >>> The 'equals' method from the SmallAttributeSet class compares local >>> attributes from the current set with all attributes (local and parent) >>> from the second set if local counts are equal. >>> So if we check the following text attributes: >>> attr1: [ elem1 = value1] // getAttributeCount = 1 >>> attr2: [ Parent = [ elem1 = value1] ] // getAttributeCount = 1 >>> >>> The results are: >>> attr1.equals(attr2) = false // attr1 does not contain element with name >>> Parent >>> attr2.equals(attr1) = true // attr2 has element elem1 in the parent set >>> >>> All other classes that implement AttributeSet interface has the same >>> problems with the hashcode/equals contract. >>> >>> The fix compares all local attributes from one set with all local >>> attributes from the another set in the equals method. >>> If both sets have parents, they will be compared automatically (in the >>> same way as it was before). >>> >>> >>> SimpleAttributeSet: Hashtable returns hashcode based on both keys and >>> values. The fix redefines it to return a hash code only for values. >>> MuxingAttributeSet: There is no direct way to get all local attributes. >>> The getLocalAttribute method returns a value only if name is local. >>> AbstractElement: If both attribute sets are AbstractElement they are >>> compared by reference. In other case they are compared by checking local >>> attributes. This preserves the old AbstractElement behaviour. >>> >>> The javax/swing/text/AttributeSet/8001423/bug8001423.java test is added. >>> >>> I run the javax/swing/text tests and there is no new failures after the >>> fix. >>> >>> Thanks, >>> Alexandr. >>> >> > > From peter.brunet at oracle.com Wed Nov 14 20:01:12 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 14 Nov 2012 14:01:12 -0600 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <509D7545.6020903@oracle.com> References: <509C2957.9070200@oracle.com> <509D7545.6020903@oracle.com> Message-ID: <50A3F888.2080909@oracle.com> This bug includes a coordination of fixes for both awt (2 files) and swing (1 file). Which repo should I use? jdk8/awt or jdk8/swing? I'm guessing the latter. (AccessibleJComponent inherits from AccessibleAWTContainer). Pete On 11/9/12 3:27 PM, Pete Brunet wrote: > Please review the following fix planned for JDK8. Part of the fix will > go into 7u12 under 7177111. > > Problem: > In the process of evaluating 7177111 the following problems were noticed: > - Both Component and JComponent have field "accessibleContext". In > Component it is package-private and accessed by other classes from > java.awt, but in JComponent it is protected and therefore this field > hides the same superclass field from any subclass. These two fields > should be refactored to a single protected field in Component. > - Container.AccessibleAWTContainer has an addPropertyChangeListener but > not a removePropertyChangeListener. This method is needed so stale > listeners can be removed when AT are no longer attached to a Java process. > - The JComponent.AccessibleJComponent.accessibleFocusHandler field > functionally duplicates its superclass field, > Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this > field is used properly there are no logical issues. However, the > existence of this field could cause confusion for a developer trying to > understand the code. The superclass field is sufficient. > > Solution: > - Change java.awt.Component.accessibleContext from package-private to > protected. This will allow use by subclasses and the removal of the > duplicate field in javax.swing.JComponent. > - Add > java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener > so stale listeners can be removed when an Assistive Technology is no > longer attached to a Java process. > - Remove the protected field javax.swing.JComponent.accessibleContext. > Instead the protected field java.awt.Component.accessibleContext, will > be used. With the change subclasses would now use the protected field > in the Component superclass. > - Remove public method javax.swing.JComponent.getAccessibleContext. > Instead it superclass public method > java.awt.Component.getAccessibleContext method would be used. > - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler > field will be deprecated. Developers should use the > java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler > field instead. > > Webrev: http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 > CCC: http://ccc.us.oracle.com/7179482 From peter.brunet at oracle.com Wed Nov 14 22:26:23 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 14 Nov 2012 16:26:23 -0600 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <509D7545.6020903@oracle.com> References: <509D7545.6020903@oracle.com> Message-ID: <50A41A8F.7070404@oracle.com> Some more code has been added. A counter has been added to each of the three files. It is incremented when addPropertyChangeListener is called and decremented when removePropertyChangeListener is called. Only when the count is zero, i.e. the first add and last remove, do specific handlers (see below) get added/removed. Component.java: This code has Component and Focus handlers. Container.java: This code has a Container handler. JComponent.java: This code has Container and Focus handlers. See http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.01/ Pete -------- Original Message -------- Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring Date: Fri, 09 Nov 2012 15:27:33 -0600 From: Pete Brunet Reply-To: peter.brunet at oracle.com To: awt-dev , swing-dev at openjdk.java.net Please review the following fix planned for JDK8. Part of the fix will go into 7u12 under 7177111. Problem: In the process of evaluating 7177111 the following problems were noticed: - Both Component and JComponent have field "accessibleContext". In Component it is package-private and accessed by other classes from java.awt, but in JComponent it is protected and therefore this field hides the same superclass field from any subclass. These two fields should be refactored to a single protected field in Component. - Container.AccessibleAWTContainer has an addPropertyChangeListener but not a removePropertyChangeListener. This method is needed so stale listeners can be removed when AT are no longer attached to a Java process. - The JComponent.AccessibleJComponent.accessibleFocusHandler field functionally duplicates its superclass field, Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this field is used properly there are no logical issues. However, the existence of this field could cause confusion for a developer trying to understand the code. The superclass field is sufficient. Solution: - Change java.awt.Component.accessibleContext from package-private to protected. This will allow use by subclasses and the removal of the duplicate field in javax.swing.JComponent. - Add java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener so stale listeners can be removed when an Assistive Technology is no longer attached to a Java process. - Remove the protected field javax.swing.JComponent.accessibleContext. Instead the protected field java.awt.Component.accessibleContext, will be used. With the change subclasses would now use the protected field in the Component superclass. - Remove public method javax.swing.JComponent.getAccessibleContext. Instead it superclass public method java.awt.Component.getAccessibleContext method would be used. - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler field will be deprecated. Developers should use the java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler field instead. Webrev: http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 CCC: http://ccc.us.oracle.com/7179482 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Nov 15 09:18:33 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 15 Nov 2012 13:18:33 +0400 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50A338B5.7070302@linux.vnet.ibm.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com> <509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com> <50A1FC8F.7060107@linux.vnet.ibm.com> <50A233B2.5020602@oracle.com> <50A338B5.7070302@linux.vnet.ibm.com> Message-ID: <50A4B369.3030009@oracle.com> On 11/14/2012 10:22 AM, Frank Ding wrote: > Hi Alexandr, > After a couple of hours investigating the possibility of fixing > JComboBox.setModel(null) and JTextComponent.setComponent(null), I > found that > 1. In JComboBox.setModel, the new model, null in this case, is > eventually passed to BasicComboPopup.propertyChange where > JList.setModel is called. JList.setModel rejects the null model > because of its api restriction. Below I listed the offending call > stacks in my IDE. This makes sense as the associated drop down JList > needs new model. However, it makes fixing JComboBox.setModel(null) > hard or impossible. > Exception in thread "main" java.lang.IllegalArgumentException: model > must be non null > at javax.swing.JList.setModel(JList.java:1674) > at > javax.swing.plaf.basic.BasicComboPopup$Handler.propertyChange(BasicComboPopup.java:939) > at > java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) > at > java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327) > at > java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263) > at java.awt.Component.firePropertyChange(Component.java:8413) > at javax.swing.JComboBox.setModel(JComboBox.java:322) > > 2. JTextComponent.setComponent(null) can be fixed but code change in > BasicTextUI is also required. > > Since setting null model to JComboBox, JList and JTextComponent is > impossible or dangerous, just as you mentioned, we could set a non > null new model to these UI components just for the purpose of having > the side effect of removing listeners from old model. Are you ok with > this approach? Yes. Please, try this and run the html swing automated tests from the test/javax/swing/text/html diroctory to check possible regressions. Thanks, Alexandr. > By the way, I will investigate your another question "Could you also > check that the StyleConstants.ComponentAttribute property value can't > be rewritten by the JDK code or by public methods." and reply soon. > > Best regards, > Frank > > On 11/13/2012 7:49 PM, Alexander Scherbatiy wrote: >> On 11/13/2012 11:53 AM, Frank Ding wrote: >>> Hi Alexandr, >>> As for your comment "Could you create an issue that a >>> JComboBox.setModel(null) call throws NPE? You could fix it before >>> the 7189299 issue. ", I created a bug with internal review ID of >>> 2381499 on JComboBox.setModel(null). But test shows that >>> JPasswordField.setDocument(null), JTextField.setDocument(null), >>> JList.setModel(null) and JTextArea.setDocument(null) all throw NPE. >>> Particularly, JList.setModel(null) has null check and throws >>> IllegalArgumentException("model" must be non null"). Shall I >>> include those components as well? >> >> There is the javadoc for the JList setModel() method: Throws >> IllegalArgumentException - if model is null. So it is undesirable to >> change the public API. >> However, it is possible to set a new empty model for the JList. >> The list listeners should be removed from the old model in this case. >> >> You could have only 2 issues: one for components that allow to >> set a null model but throws NPE (like JComboBox) and another for >> components that does not allow to set null model but they do not >> remove listeners from the old model in case if a new model is set. >> >> Thanks, >> Alexandr. >> >>> Thanks for your guidance in advance. >>> >>> Best regards, >>> Frank >>> >>> On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote: >>>> On 11/7/2012 10:56 AM, Frank Ding wrote: >>>>> Hi Alexandr, >>>>> Unfortunately, all the JComponents involved in >>>>> FormView.createComponent() have bugs! >>>>> I have done tests for all other swing components, i.e. >>>>> JCheckBox, JRadioButton, JPasswordField, JTextField, JList, >>>>> JComboBox and JTextField. Sadder news is that if we fix all >>>>> components in the same way as I did for JButton, we need to >>>>> subclass them all, resulting in JCheckBoxWrapper, >>>>> JRadioButtonWrapper, JPasswordFieldWrapper, JTextFieldWrapper, >>>>> JListWrapper, JComboBoxWrapper, JTextFieldWrapper plus >>>>> JButtonWrapper! This approach becomes unacceptable when all swing >>>>> components are affected. >>>>> Shall we fix it in other way illustrated below? >>>>> 1. Whenever a swing component is created, it is kept in >>>>> AttributeSet, as what is now for model. >>>>> 2. In FormView.createComponent(), the old swing component can be >>>>> retrieved via >>>>> attr.getAttribute(StyleConstants.ComponentAttribute). Note that >>>>> ComponentAttribute is newly added. >>>> This way should be carefully investigated that it does not >>>> introduce new memory leaks. >>>> Could you also check that the >>>> StyleConstants.ComponentAttribute property value can't be rewritten >>>> by the JDK code or by public methods. >>>> >>>>> 3. Before setting shared model to a newly initialized swing >>>>> component, call oldComp.setModel(null), delegating deregistration >>>>> to setModel method. >>>>> 4. Seems some setModel such as AbstractButton.setModel() can >>>>> function well when the param, new model, is null while >>>>> JComboBox.setModel() will throw NPE in case of null param. >>>> Could you create an issue that a JComboBox.setModel(null) call >>>> throws NPE? You could fix it before the 7189299 issue. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> 5. Add null check code in those problematic setModel or >>>>> setDocument methods. >>>>> >>>>> Any idea is appreciated. Thanks. >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote: >>>>>> On 11/5/2012 11:20 AM, Frank Ding wrote: >>>>>>> Hi Alexander, >>>>>>> Based on your comments last time, I refined my patch of v6 and >>>>>>> offered v7 @ >>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ >>>>>> >>>>>> This version of the fix looks good for me. >>>>>> It seems that it is the only good way to check that a button >>>>>> model contains AbstarctButton.Handler listener. >>>>>> >>>>>> Could you also check that others models used in the >>>>>> createComponent() method do not have such memory leaks (even the >>>>>> NPE is not thrown)? >>>>>> >>>>>>> 4. Could you add the check that the action listener is >>>>>>> invoked only once after a component tree updating and the action >>>>>>> does the same that it does before a component tree updating? >>>>>>> Answer: I am afraid I could not make it in the auto test >>>>>>> (bug7189299.java) but I can achieve it to some degree in manual >>>>>>> test FormSubmit, the one you illustrated below. >>>>>>> My idea of checking it in FormSubmit.java is subclassing >>>>>>> JEditorPane and overriding 'public EditorKit getEditorKit()' >>>>>>> where stack traces can be examined in the overridden method to >>>>>>> make sure FormView.submitData occurs only once. This approach >>>>>>> works because FormView.submitData() calls >>>>>>> JEditorPane.getEditorKit but is tricky. However, it's the only >>>>>>> way I can think of without any additional framework support. If >>>>>>> you are in favor of adding the check in FormSubmit.java, I am >>>>>>> willing to do that. >>>>>> >>>>>> At least a separated manual test can be added that asks a >>>>>> user to put a response.html file to a server and according to the >>>>>> server url checks that JTeditor pane show the response text after >>>>>> a button pressing. >>>>>> >>>>>> html = new JEditorPane("text/html", >>>>>> "
" >>>>>> + ">>>>> value=\"submit\"/>" >>>>>> + "
"); >>>>>> >>>>>> response.html: >>>>>> Hello World! >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> Thanks again for all your comments and your support. Once >>>>>>> again, if you have any further concern or comment, please don't >>>>>>> hesitate to let me know. >>>>>>> >>>>>>> Best regards, >>>>>>> Frank >>>>>>> > From alexandr.scherbatiy at oracle.com Thu Nov 15 09:20:17 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 15 Nov 2012 13:20:17 +0400 Subject: Fwd: Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners In-Reply-To: <50A3B900.6070307@oracle.com> References: <509C2957.9070200@oracle.com> <50A3B900.6070307@oracle.com> Message-ID: <50A4B3D1.20000@oracle.com> On 11/14/2012 7:30 PM, Pete Brunet wrote: > Could someone from the Swing team please review this? The fix looks good for me. Thanks, Alexandr. > > -------- Original Message -------- > Subject: Please review fix for 7177111 : > Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential > listeners > Date: Thu, 08 Nov 2012 15:51:19 -0600 > From: Pete Brunet > Reply-To: peter.brunet at oracle.com > To: awt-dev , swing-dev at openjdk.java.net > > > > Hi Everyone, Please review the following fix planned for 7u12. It > will also go into 8 under 7179482. > > Problem: > When an AT (Assistive Technology) accesses a Java application with > several nested frames, too many property change listeners are added > resulting in a severe performance impact for an AT user. > > The issue is due to the fact that there is an > accessibleContainerHandler field in both > javax.swing.JComponent.AccessibleJComponent and its superclass, > java.awt.Container.AccessibleAWTContainer. When an AT calls > JComponent.AccessibleJComponent.addPropertyChangeListener a handler is > new'd and assigned to its accessibleContainerHandler field and then > the same method in the superclass is called and it also new's and > assigns a handler to its accessibleContainerHandler field. Since > there are two handlers, when a child component is later added there > are two callbacks and for each one the AT will call > addPropertyChangeListener, each of which will add two handlers. For > deeply nested trees the explosion of events has a negative impact on > performance, i.e. there are 2 handlers added for the first level, 4 > for the second level, 8 for the third level, etc. > > Solution: > Remove protected field > javax.swing.JComponent.AccessibleJComponent.accessibleContainerHandler. > Instead, the protected field of the same name in > java.awt.Container.AWTAccessibleContainer will be used. > > Webrev: http://cr.openjdk.java.net/~ptbrunet/7177111/webrev.03/ > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177111 > http://monaco.us.oracle.com/detail.jsf?cr=7177111 > CCC: http://ccc.us.oracle.com/7177111 > > > From alexandr.scherbatiy at oracle.com Thu Nov 15 10:01:41 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 15 Nov 2012 14:01:41 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50A3E38E.8050806@oracle.com> References: <50927965.3030402@oracle.com> <50991E10.5090202@oracle.com> <50A0FA4B.9010402@oracle.com> <50A3E38E.8050806@oracle.com> Message-ID: <50A4BD85.5020103@oracle.com> On 11/14/2012 10:31 PM, Denis S. Fokin wrote: > Hi Alexander, > > my thoughts are below > > 1. I see the next scenario > > // 'this' contains 3 attributes > // 'attr' does not contain attributes In this scenario the code below is unreachable because of the previous check: if (getAttributeCount() != attr.getAttributeCount()) { return false; } > 925 boolean result = true; > 926 > 927 Enumeration names = attr.getAttributeNames(); > > // 'names' is an empty enumeration > // by this reason we do not get into the loop > > 928 while (result && names.hasMoreElements()) { > 929 Object name = names.nextElement(); > 930 result = > attr.getAttribute(name).equals(getLocalAttribute(name)); > 931 } > > // three attributes is not the same as no attributes > // but we have not changed the default value of the > // result variable, so return true. > > 932 > 933 return result; > > 2. You have removed the next code form the SimpleAttributeSet.java file > > 305 if (this == obj) { > 306 return true; > 307 } > > I suggest the next checks in the beginning of each equals method I have removed this check because the equals method calls isEqual() method that has this check. Using this check in both methods equals and isEqual is code duplication. > > a.) return false if the parameter is null According to the implementation before the fix it should throw NPE. This is a correct behavior. I do not think that it should be changed. > b.) return false if a class of the parameter differs from expected > one (in general case is not an instance of AttributeSet) Yes. This check is always implemented in the equals method. > c.) return true if the objects are equal by reference This is implemented in all overridden equals and isEqual method (directly or from the isEqual call from equals). > > 4. > > By contrast with StyleContext.SmallAttributeSet.equals() we do not > change anything in StyleContext.NamedStyle.equals() > > StyleContext.java > 1431 /** > 1432 * Checks whether two attribute sets are equal. > 1433 * > 1434 * @param attr the attribute set to check against > 1435 * @return true if the same > 1436 * @see AttributeSet#isEqual > 1437 */ > 1438 public boolean isEqual(AttributeSet attr) { > 1439 return attributes.isEqual(attr); > 1440 } It was decided by design that these classes should be compared only by reference (so the equals method is not overridden). We do not change this behavior in the current fix. The current fix only makes 'equals' and 'isEqual' method symmetrically for those cases there they were not symmetrically. > > 5. > In you current implementation we have a code duplication. This code is > common for StyleContext.SmallAttributeSet, SimpleAttributeSet, > MuxingAttributeSet (and may be for future NamedStyle). > > 921 if (getAttributeCount() != attr.getAttributeCount()) { > 922 return false; > 923 } > 924 > 925 boolean result = true; > 926 > 927 Enumeration names = attr.getAttributeNames(); > 928 while (result && names.hasMoreElements()) { > 929 Object name = names.nextElement(); > 930 result = > attr.getAttribute(name).equals(getLocalAttribute(name)); > 931 } > 932 > 933 return result; > > May be we should somehow reuse our code here? There is no a code duplication because every time we check local attributes from the given set with the local attributes from the current set. Getting local attributes from the current set depends on the set class implementation. For example, the SimpleAttributeSet contains it's attributes in table and the SmallAttributeSet in an array. So the only code duplication can be checking attribute counts. It will be new public API that should be processed from the CCC request. Is it really necessary? > > 6. > > In the next places we have different approaches for the comparison of > attributes. > > - comparation of local attributes (StyleContext) > - comparation of local attributes 'Approach #2' (MuxingAttributeSet) > - comparation of attributes > > Is it intentional or it should be implemented the same way? All these cases compares only local attributes. The last case gets attributes from the table. The table contains only local attributes. Thanks, Alexandr. > > StyleContext.java > > 920 private boolean isAttributeSetEqual(AttributeSet attr) { > 921 if (getAttributeCount() != attr.getAttributeCount()) { > 922 return false; > 923 } > 924 > 925 boolean result = true; > 926 > 927 Enumeration names = attr.getAttributeNames(); > 928 while (result && names.hasMoreElements()) { > 929 Object name = names.nextElement(); > 930 result = > attr.getAttribute(name).equals(getLocalAttribute(name)); > 931 } > 932 > 933 return result; > 934 } > > 795 Object getLocalAttribute(Object nm) { > 796 if (nm == StyleConstants.ResolveAttribute) { > 797 return resolveParent; > 798 } > 799 Object[] tbl = attributes; > 800 for (int i = 0; i < tbl.length; i += 2) { > 801 if (nm.equals(tbl[i])) { > 802 return tbl[i+1]; > 803 } > 804 } > 805 return null; > 806 } > > > MuxingAttributeSet.java > > 167 public boolean isEqual(AttributeSet attr) { > 168 if (this == attr) { > 169 return true; > 170 } > 171 > 172 if (getAttributeCount() != attr.getAttributeCount()) { > 173 return false; > 174 } > 175 > 176 boolean result = true; > 177 > 178 Enumeration names = attr.getAttributeNames(); > 179 while (result && names.hasMoreElements()) { > 180 Object name = names.nextElement(); > 181 Object localAttribute = getLocalAttribute(name); > 182 result = localAttribute != null && > attr.getAttribute(name).equals(localAttribute); > 183 } > 184 > 185 return result; > 186 } > > > > 188 private Object getLocalAttribute(Object name) { > 189 for (AttributeSet as : getAttributes()) { > 190 Enumeration names = as.getAttributeNames(); > 191 while (names.hasMoreElements()) { > 192 Object attributeName = names.nextElement(); > 193 if (attributeName.equals(name)) { > 194 return as.getAttribute(name); > 195 } > 196 } > 197 } > 198 return null; > 199 } > > SimpleAttributeSet.java > > 115 public boolean isEqual(AttributeSet attr) { > 116 if (this == attr) { > 117 return true; > 118 } > 119 > 120 if (getAttributeCount() != attr.getAttributeCount()) { > 121 return false; > 122 } > 123 > 124 boolean result = true; > 125 > 126 Enumeration names = attr.getAttributeNames(); > 127 while (result && names.hasMoreElements()) { > 128 Object name = names.nextElement(); > 129 result = > attr.getAttribute(name).equals(table.get(name)); > 130 } > 131 > 132 return result; > 133 } > > Thank you, > Denis. > > On 11/12/2012 5:31 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8001423/webrev.01/ >> >> See my comments below: >> >> On 11/6/2012 6:26 PM, Denis S. Fokin wrote: >>> Hi Alexander, >>> >>> I found several places that could be improved, in my opinion. >>> >>> SimpleAttributeSet.java >>> 120 boolean result = true; >>> >>> I would not assign 'true' as a default value. If the 'names' >>> enumeration does not have any elements, we return true even not trying >>> to compare anything. >> We always check before that both attribute sets have the same count. So >> if the second attribute set is empty that means that the first set also >> empty. >> >>> >>> // Does not have elements, so returns true. >>> 123 while (result && names.hasMoreElements()) { >> That is ok. Comparing two empty attribute sets should return true >> because they are equal to each other. >>> >>> >>> MuxingAttributeSet.java >>> 130 for (int i = 0; i < as.length; i++) { >>> Why we do not use foreach loop here? >> Fixed. >>> >>> >>> AbstractDocument.java >>> 1874 && !(obj instanceof AbstractElement)) { >>> I am not an expert in Swing, so this check is not quite clear to me. >>> Why we check AbstractDocument.AbstractElement and do not check, for >>> instance, SimpleAttributeSet? Is it only because of "the old >>> AbstractElement behaviour"? >> There is a theory how to implement equals/hashCode methods correctly in >> Java. >> For example, If there is a class Point{ double x; double y; } the equals >> method can be: >> -------------------------------------------- >> public boolean equals(Object obj) { >> if (obj instanceof Point) { >> Point point = (Point) obj; >> return x == point.x && y == point.y; >> } >> return false; >> } >> -------------------------------------------- >> >> And there is a child class >> -------------------------------------------- >> class ColorPoint extends Point{ >> Color color; >> } >> -------------------------------------------- >> >> Point point = new Point(3,4); >> ColorPoint c = new ColorPoint(3, 4, Color.GREEN); >> ColorPoint bluePoint = new ColorPoint(3, 4, Color.BLUE); >> >> What we want that the greenPoint was different from the bluePoint. >> And we know that the check point.equals(greenPoint) returns true because >> Point 'equals' method checks only coordinates. >> >> So the ColorPoint equals method could look like: >> ----------------------------------------------- >> public boolean equals(Object obj) { >> if (obj instanceof ColorPoint) { >> return (((ColorPoint) obj).color == this.color) && super.equals(obj); >> } else if (obj instanceof Point) { >> return super.equals(obj); >> } >> return false; >> } >> ----------------------------------------------- >> The idea is that a child class should add an additional check for >> objects that have the same instance. >> >> The check 'if ((obj instanceof AttributeSet) && !(obj instanceof >> AbstractElement))' in the AbstractDocument has been added for the same >> reason. >> If an object is an instance of AbstractDocument we return just (this == >> obj) in other case if the object is and instance of AttributeSet we >> return isEqual((AttributeSet) obj). >> >> The theory also says that it is better to add 'isEqual' rather to >> override the 'equals' method because in the second case >> the hashCode method should be overriden accordingly and for mutable >> object it could have troubles. >> >> >> I decided to changed the fix to: >> - make the equals and isEqual method symmetrically >> - updated the hashCode method only if they were implemented >> >> And leave all others as is to not break the backward compatibility. >> >>> By the way, I would say that we should check for equality by reference >>> in the first place to get rid of comparing attributes if we call >>> equals method for the same object. >> >> Fixed. >> >> Thanks, >> Alexandr. >>> >>> Thank you, >>> Denis. >>> >>> >>> On 11/1/2012 5:30 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001423 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8001423/webrev.00 >>>> >>>> The 'equals' method from the SmallAttributeSet class compares local >>>> attributes from the current set with all attributes (local and parent) >>>> from the second set if local counts are equal. >>>> So if we check the following text attributes: >>>> attr1: [ elem1 = value1] // getAttributeCount = 1 >>>> attr2: [ Parent = [ elem1 = value1] ] // getAttributeCount = 1 >>>> >>>> The results are: >>>> attr1.equals(attr2) = false // attr1 does not contain element with >>>> name >>>> Parent >>>> attr2.equals(attr1) = true // attr2 has element elem1 in the parent >>>> set >>>> >>>> All other classes that implement AttributeSet interface has the same >>>> problems with the hashcode/equals contract. >>>> >>>> The fix compares all local attributes from one set with all local >>>> attributes from the another set in the equals method. >>>> If both sets have parents, they will be compared automatically (in the >>>> same way as it was before). >>>> >>>> >>>> SimpleAttributeSet: Hashtable returns hashcode based on both keys and >>>> values. The fix redefines it to return a hash code only for values. >>>> MuxingAttributeSet: There is no direct way to get all local >>>> attributes. >>>> The getLocalAttribute method returns a value only if name is local. >>>> AbstractElement: If both attribute sets are AbstractElement they are >>>> compared by reference. In other case they are compared by checking >>>> local >>>> attributes. This preserves the old AbstractElement behaviour. >>>> >>>> The javax/swing/text/AttributeSet/8001423/bug8001423.java test is >>>> added. >>>> >>>> I run the javax/swing/text tests and there is no new failures after >>>> the >>>> fix. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> >> > From artem.ananiev at oracle.com Thu Nov 15 10:19:55 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 15 Nov 2012 14:19:55 +0400 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <50A3F888.2080909@oracle.com> References: <509C2957.9070200@oracle.com> <509D7545.6020903@oracle.com> <50A3F888.2080909@oracle.com> Message-ID: <50A4C1CB.7040401@oracle.com> On 11/15/2012 12:01 AM, Pete Brunet wrote: > This bug includes a coordination of fixes for both awt (2 files) and > swing (1 file). Which repo should I use? jdk8/awt or jdk8/swing? I'm > guessing the latter. (AccessibleJComponent inherits from > AccessibleAWTContainer). When you get approvals from AWT and Swing teams for the last version of the fix, please use jdk8/awt-gate to push the changes. Thanks, Artem > Pete > > On 11/9/12 3:27 PM, Pete Brunet wrote: >> Please review the following fix planned for JDK8. Part of the fix will >> go into 7u12 under 7177111. >> >> Problem: >> In the process of evaluating 7177111 the following problems were noticed: >> - Both Component and JComponent have field "accessibleContext". In >> Component it is package-private and accessed by other classes from >> java.awt, but in JComponent it is protected and therefore this field >> hides the same superclass field from any subclass. These two fields >> should be refactored to a single protected field in Component. >> - Container.AccessibleAWTContainer has an addPropertyChangeListener but >> not a removePropertyChangeListener. This method is needed so stale >> listeners can be removed when AT are no longer attached to a Java process. >> - The JComponent.AccessibleJComponent.accessibleFocusHandler field >> functionally duplicates its superclass field, >> Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this >> field is used properly there are no logical issues. However, the >> existence of this field could cause confusion for a developer trying to >> understand the code. The superclass field is sufficient. >> >> Solution: >> - Change java.awt.Component.accessibleContext from package-private to >> protected. This will allow use by subclasses and the removal of the >> duplicate field in javax.swing.JComponent. >> - Add >> java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener >> so stale listeners can be removed when an Assistive Technology is no >> longer attached to a Java process. >> - Remove the protected field javax.swing.JComponent.accessibleContext. >> Instead the protected field java.awt.Component.accessibleContext, will >> be used. With the change subclasses would now use the protected field >> in the Component superclass. >> - Remove public method javax.swing.JComponent.getAccessibleContext. >> Instead it superclass public method >> java.awt.Component.getAccessibleContext method would be used. >> - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler >> field will be deprecated. Developers should use the >> java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler >> field instead. >> >> Webrev: http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 >> CCC: http://ccc.us.oracle.com/7179482 > From jaroslav.tulach at oracle.com Thu Nov 15 15:58:35 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 15 Nov 2012 16:58:35 +0100 Subject: Patch for NPE at javax.swing.plaf.basic.BasicTreeUI$Actions.page:4470 Message-ID: <6868828.OWPBIWenVZ@logoutik> Dear Swing maintainers, my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a component that is using JTree heavily. >From time to time I receive a user report with a NPE from Swing where little or even no NetBeans code involved. Just today I got http://netbeans.org/bugzilla/show_bug.cgi?id=222081 We have about 35 other ones (which is not that much given the fact we have million of users), but still... According to http://statistics.netbeans.org/exceptions/exception.do?id=628832 the report comes from jdk7u9-b05. The source code is here http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java and thus it looks like the call on line 4468 to ui.getPathBounds(tree, newPath); can return null (under some rare and unknown circumstances). I can close the bug #222081 as "worksforme", but it is clear that such error happens from time to time and we don't want our users to face errors. A simple: 4469 if (newRect == null) return; would do the trick. One question remains: if I try to donate such patch, will you accept it? -jt From alexander.zuev at oracle.com Thu Nov 15 16:37:41 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 15 Nov 2012 20:37:41 +0400 Subject: [8] Please review fix for 8003273: Missing testcase for 7171812 Message-ID: <50A51A55.1010309@oracle.com> Please review my test for CR 8003273: Missing testcase for 7171812 The new regression test can be found at http://cr.openjdk.java.net/~kizune/8003273/webrev.00/ Bug description is available at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003273 With best regards, Alex From konstantin.shefov at oracle.com Fri Nov 16 08:50:42 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 16 Nov 2012 12:50:42 +0400 Subject: [8] Review request for 7124242 [macosx] Test doesn't work because of the frame round corners in the LaF In-Reply-To: <509CC335.2010908@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> Message-ID: <50A5FE62.3030507@oracle.com> Could you please look at this test fix? Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ JFrame was undecorated to make test pass on MacOSX and Windows 7 with Aero. Thanks, Konstantin From konstantin.shefov at oracle.com Fri Nov 16 09:29:15 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 16 Nov 2012 13:29:15 +0400 Subject: [7u12] Request for approval for CR 8003522 - [macosx] Add autodelay to fix a regression test Message-ID: <50A6076B.9060306@oracle.com> Hello, Please review a fix for the issue: 8003522 - [macosx] Add autodelay to fix a regression test The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev.03 Suggested backport from jdk 8. Thanks, Konstantin From alexandr.scherbatiy at oracle.com Fri Nov 16 11:30:00 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Nov 2012 15:30:00 +0400 Subject: Patch for NPE at javax.swing.plaf.basic.BasicTreeUI$Actions.page:4470 In-Reply-To: <6868828.OWPBIWenVZ@logoutik> References: <6868828.OWPBIWenVZ@logoutik> Message-ID: <50A623B8.9070504@oracle.com> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: > Dear Swing maintainers, > my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a > component that is using JTree heavily. > > > From time to time I receive a user report with a NPE from Swing where little > or even no NetBeans code involved. Just today I got > http://netbeans.org/bugzilla/show_bug.cgi?id=222081 > We have about 35 other ones (which is not that much given the fact we have > million of users), but still... > > According to > http://statistics.netbeans.org/exceptions/exception.do?id=628832 > the report comes from jdk7u9-b05. The source code is here > http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- > b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java > and thus it looks like the call on line 4468 to > > ui.getPathBounds(tree, newPath); > > can return null (under some rare and unknown circumstances). > > I can close the bug #222081 as "worksforme", but it is clear that such error > happens from time to time and we don't want our users to face errors. A > simple: > > 4469 if (newRect == null) return; > > would do the trick. One question remains: if I try to donate such patch, will > you accept it? The ui.getPathBounds(tree, newPath) method definitely can return null so it needs to have this check. However, such fix can mask the real issue, for example, in the treeState.getBounds() method where the treeState can be instance of FixedHeightLayoutCache or VariableHeightLayoutCache class. If it is possible, could you send a code snippet that shows how NetBeans uses JTree? May be it can give a hint what can be wrong in this case. Thanks, Alexandr. > -jt > > From anthony.petrov at oracle.com Fri Nov 16 12:01:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 16 Nov 2012 16:01:34 +0400 Subject: [7u12] Request for approval for CR 8003522 - [macosx] Add autodelay to fix a regression test In-Reply-To: <50A6076B.9060306@oracle.com> References: <50A6076B.9060306@oracle.com> Message-ID: <50A62B1E.4010607@oracle.com> Looks good to me. -- best regards, Anthony On 11/16/2012 1:29 PM, Konstantin Shefov wrote: > Hello, > > Please review a fix for the issue: > > 8003522 - [macosx] Add autodelay to fix a regression test > > The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev.03 > > Suggested backport from jdk 8. > > Thanks, > Konstantin > From jaroslav.tulach at oracle.com Fri Nov 16 12:10:55 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 16 Nov 2012 13:10:55 +0100 Subject: Patch for NPE at javax.swing.plaf.basic.BasicTreeUI$Actions.page:4470 In-Reply-To: <50A623B8.9070504@oracle.com> References: <6868828.OWPBIWenVZ@logoutik> <50A623B8.9070504@oracle.com> Message-ID: <8154791.4EKInKHKfR@logoutik> Hello Alexander, thanks for your reply. The source code for NetBeans TreeView component is available here: http://hg.netbeans.org/main- golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/view/TreeView.java I'll be glad for any review, however I am also positively pleased by your answer: > The ui.getPathBounds(tree, newPath) method definitely can return > null so it needs to have this check. Should I start working on a webrev, so (in case you don't find any violation of good Swing practices in TreeView) we can eliminate this NPE once and forever? What should be part of such webrev? Just the NPE check? Or do you want some test, change in documentation, etc.? Thanks again for your comments. -jt Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): > On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: > > Dear Swing maintainers, > > my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a > > component that is using JTree heavily. > > > > > From time to time I receive a user report with a NPE from Swing where > > > little> > > or even no NetBeans code involved. Just today I got > > http://netbeans.org/bugzilla/show_bug.cgi?id=222081 > > We have about 35 other ones (which is not that much given the fact we have > > million of users), but still... > > > > According to > > http://statistics.netbeans.org/exceptions/exception.do?id=628832 > > the report comes from jdk7u9-b05. The source code is here > > http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- > > b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java > > and thus it looks like the call on line 4468 to > > > > ui.getPathBounds(tree, newPath); > > > > can return null (under some rare and unknown circumstances). > > > > I can close the bug #222081 as "worksforme", but it is clear that such > > error happens from time to time and we don't want our users to face > > errors. A simple: > > > > 4469 if (newRect == null) return; > > > > would do the trick. One question remains: if I try to donate such patch, > > will you accept it? > > The ui.getPathBounds(tree, newPath) method definitely can return > null so it needs to have this check. > However, such fix can mask the real issue, for example, in the > treeState.getBounds() method where the treeState can be instance of > FixedHeightLayoutCache or VariableHeightLayoutCache class. > > If it is possible, could you send a code snippet that shows how > NetBeans uses JTree? May be it can give a hint what can be wrong in this > case. > > Thanks, > Alexandr. > > > -jt From anthony.petrov at oracle.com Fri Nov 16 12:34:31 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 16 Nov 2012 16:34:31 +0400 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <50A41A8F.7070404@oracle.com> References: <509D7545.6020903@oracle.com> <50A41A8F.7070404@oracle.com> Message-ID: <50A632D7.8090602@oracle.com> The fix looks fine to me. -- best regards, Anthony On 11/15/2012 2:26 AM, Pete Brunet wrote: > Some more code has been added. A counter has been added to each of > the three files. It is incremented when addPropertyChangeListener is > called and decremented when removePropertyChangeListener is called. > Only when the count is zero, i.e. the first add and last remove, do > specific handlers (see below) get added/removed. > > Component.java: This code has Component and Focus handlers. > > Container.java: This code has a Container handler. > > JComponent.java: This code has Container and Focus handlers. > > See http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.01/ > > Pete > > -------- Original Message -------- > Subject: Please review fix for 7179482 : > Component.accessibleContext and JComponent.accessibleContext refactoring > Date: Fri, 09 Nov 2012 15:27:33 -0600 > From: Pete Brunet > Reply-To: peter.brunet at oracle.com > To: awt-dev , swing-dev at openjdk.java.net > > > > Please review the following fix planned for JDK8. Part of the fix will > go into 7u12 under 7177111. > > Problem: > In the process of evaluating 7177111 the following problems were noticed: > - Both Component and JComponent have field "accessibleContext". In > Component it is package-private and accessed by other classes from > java.awt, but in JComponent it is protected and therefore this field > hides the same superclass field from any subclass. These two fields > should be refactored to a single protected field in Component. > - Container.AccessibleAWTContainer has an addPropertyChangeListener but > not a removePropertyChangeListener. This method is needed so stale > listeners can be removed when AT are no longer attached to a Java process. > - The JComponent.AccessibleJComponent.accessibleFocusHandler field > functionally duplicates its superclass field, > Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this > field is used properly there are no logical issues. However, the > existence of this field could cause confusion for a developer trying to > understand the code. The superclass field is sufficient. > > Solution: > - Change java.awt.Component.accessibleContext from package-private to > protected. This will allow use by subclasses and the removal of the > duplicate field in javax.swing.JComponent. > - Add > java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener > so stale listeners can be removed when an Assistive Technology is no > longer attached to a Java process. > - Remove the protected field javax.swing.JComponent.accessibleContext. > Instead the protected field java.awt.Component.accessibleContext, will > be used. With the change subclasses would now use the protected field > in the Component superclass. > - Remove public method javax.swing.JComponent.getAccessibleContext. > Instead it superclass public method > java.awt.Component.getAccessibleContext method would be used. > - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler > field will be deprecated. Developers should use the > java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler > field instead. > > Webrev: http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 > CCC: http://ccc.us.oracle.com/7179482 > > > > From alexandr.scherbatiy at oracle.com Fri Nov 16 13:00:19 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Nov 2012 17:00:19 +0400 Subject: [8] Review request for 8002077 Possible mnemonic issue on JFileChooser Save button on nimbus L&F Message-ID: <50A638E3.7050307@oracle.com> Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002077 webrev: http://cr.openjdk.java.net/~alexsch/8002077/webrev.00 The Save button does not have a mnemonic because the mnemonic is not updated after changing the JFileChooser type from default (open) to save in the SynthFileChooserUI. The fix updates the Save button mnemonic when JFileChooser control buttons are updated. Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Fri Nov 16 13:27:43 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Nov 2012 17:27:43 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50A3BB2C.3000409@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A3BB2C.3000409@oracle.com> Message-ID: <50A63F4F.7080002@oracle.com> The fix looks good for me. Thanks, Alexandr. On 11/14/2012 7:39 PM, Konstantin Shefov wrote: > Could you please look at this test fix? > > Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ > > It was test for Metal LaF, so I forced LaF to be Metal even on MacOS. > Now the test passes on MacOSX. > I also made Swing methods run on EDT. > Test can be moved to OpenJDK as it is already in OpenJDK 6. > > Thanks, > Konstantin From alexandr.scherbatiy at oracle.com Fri Nov 16 13:38:17 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Nov 2012 17:38:17 +0400 Subject: [8] Review request for 7124242 [macosx] Test doesn't work because of the frame round corners in the LaF In-Reply-To: <50A5FE62.3030507@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A5FE62.3030507@oracle.com> Message-ID: <50A641C9.7030201@oracle.com> The fix looks good for me. Could you also create an issue in the awt subcategory that the SunToolkit.realSync() method does not properly work on Mac OS X. Thanks, Alexandr. On 11/16/2012 12:50 PM, Konstantin Shefov wrote: > Could you please look at this test fix? > > Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ > > JFrame was undecorated to make test pass on MacOSX and Windows 7 with > Aero. > > Thanks, > Konstantin From alexandr.scherbatiy at oracle.com Fri Nov 16 13:39:37 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Nov 2012 17:39:37 +0400 Subject: [7u12] Request for approval for CR 8003522 - [macosx] Add autodelay to fix a regression test In-Reply-To: <50A6076B.9060306@oracle.com> References: <50A6076B.9060306@oracle.com> Message-ID: <50A64219.4080409@oracle.com> The fix looks good for me. On 11/16/2012 1:29 PM, Konstantin Shefov wrote: > Hello, > > Please review a fix for the issue: > > 8003522 - [macosx] Add autodelay to fix a regression test > > The webrev is http://cr.openjdk.java.net/~kshefov/7147408/webrev.03 > > Suggested backport from jdk 8. > > Thanks, > Konstantin > From alexandr.scherbatiy at oracle.com Fri Nov 16 14:00:45 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Nov 2012 18:00:45 +0400 Subject: Patch for NPE at javax.swing.plaf.basic.BasicTreeUI$Actions.page:4470 In-Reply-To: <8154791.4EKInKHKfR@logoutik> References: <6868828.OWPBIWenVZ@logoutik> <50A623B8.9070504@oracle.com> <8154791.4EKInKHKfR@logoutik> Message-ID: <50A6470D.7000805@oracle.com> On 11/16/2012 4:10 PM, Jaroslav Tulach wrote: > Hello Alexander, > thanks for your reply. The source code for NetBeans TreeView component is > available here: > http://hg.netbeans.org/main- > golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/view/TreeView.java > I'll be glad for any review, however I am also positively pleased by your > answer: Is it possible to know from the filled NB issues which NB module/component has been used when the NPE occures? Or could you point any NB panel where the TreeView is used. >> The ui.getPathBounds(tree, newPath) method definitely can return >> null so it needs to have this check. > Should I start working on a webrev, so (in case you don't find any violation of > good Swing practices in TreeView) we can eliminate this NPE once and forever? Yes, please. > What should be part of such webrev? Just the NPE check? Or do you want some > test, change in documentation, etc.? The fix should check the NPE and may be do some possible default actions in this case. It is a good idea to add an automated test but it can be possible if there are known steps which reproduce the issue. At least you can run the test/javax/swing/JTree automated test to check possible regressions. Thanks, Alexandr. > Thanks again for your comments. > -jt > > > Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): >> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: >>> Dear Swing maintainers, >>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a >>> component that is using JTree heavily. >>> >>>> From time to time I receive a user report with a NPE from Swing where >>>> little> >>> or even no NetBeans code involved. Just today I got >>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 >>> We have about 35 other ones (which is not that much given the fact we have >>> million of users), but still... >>> >>> According to >>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 >>> the report comes from jdk7u9-b05. The source code is here >>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- >>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java >>> and thus it looks like the call on line 4468 to >>> >>> ui.getPathBounds(tree, newPath); >>> >>> can return null (under some rare and unknown circumstances). >>> >>> I can close the bug #222081 as "worksforme", but it is clear that such >>> error happens from time to time and we don't want our users to face >>> errors. A simple: >>> >>> 4469 if (newRect == null) return; >>> >>> would do the trick. One question remains: if I try to donate such patch, >>> will you accept it? >> The ui.getPathBounds(tree, newPath) method definitely can return >> null so it needs to have this check. >> However, such fix can mask the real issue, for example, in the >> treeState.getBounds() method where the treeState can be instance of >> FixedHeightLayoutCache or VariableHeightLayoutCache class. >> >> If it is possible, could you send a code snippet that shows how >> NetBeans uses JTree? May be it can give a hint what can be wrong in this >> case. >> >> Thanks, >> Alexandr. >> >>> -jt From jaroslav.tulach at oracle.com Fri Nov 16 14:28:36 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 16 Nov 2012 15:28:36 +0100 Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <50A6470D.7000805@oracle.com> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> Message-ID: <4054906.gg3VXlsrro@logoutik> Hello Alexander, if you scroll down the page with the report http://statistics.netbeans.org/exceptions/exception.do?id=628832 you'll see list of user actions. Click on individual ones to get more info. One of the last actions is 5:34 PM Select in Projects it was invoked via keyboard shortcut (Ctrl-Shift-1). Looking at the XML file I found out that the actual time was 17:34:23. Then the user switched back to editor (again via shortcut this time Ctrl-Shift-0) about 1.5s later at 17:34:24: 5:34 PM Editor A two seconds later (at 17:34:26) the NPE from JTree appeared: java.lang.NullPointerException at javax.swing.plaf.basic.BasicTreeUI$Actions.page(rt.jar:4470) at javax.swing.plaf.basic.BasicTreeUI$Actions.actionPerformed(rt.jar:4046) at javax.swing.SwingUtilities.notifyAction(rt.jar:1664) We don't have logs about what the user did inside of the "Projects" component with JTree, but there seems to be no radical tree structure changes (no creation or deletion of files). The fact that the NPE happens more than a second after the user leaves the JTree hosting component is surprising. But maybe the JTree was not visible anymore - many users (including me) have the IDE configured to hide the "Projects tab" as soon as we switch to editor... I am not sure what to conclude from these observation, however. -jt Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): > On 11/16/2012 4:10 PM, Jaroslav Tulach wrote: > > Hello Alexander, > > thanks for your reply. The source code for NetBeans TreeView component is > > available here: > > http://hg.netbeans.org/main- > > golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/view/Tr > > eeView.java I'll be glad for any review, however I am also positively > > pleased by your > > answer: > Is it possible to know from the filled NB issues which NB > module/component has been used when the NPE occures? > Or could you point any NB panel where the TreeView is used. > > >> The ui.getPathBounds(tree, newPath) method definitely can return > >> > >> null so it needs to have this check. > > > > Should I start working on a webrev, so (in case you don't find any > > violation of good Swing practices in TreeView) we can eliminate this NPE > > once and forever? > Yes, please. > > > What should be part of such webrev? Just the NPE check? Or do you want > > some > > test, change in documentation, etc.? > > The fix should check the NPE and may be do some possible default > actions in this case. > It is a good idea to add an automated test but it can be possible > if there are known steps which reproduce the issue. > At least you can run the test/javax/swing/JTree automated test to > check possible regressions. > > Thanks, > Alexandr. > > > Thanks again for your comments. > > -jt > > > > Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): > >> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: > >>> Dear Swing maintainers, > >>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a > >>> component that is using JTree heavily. > >>> > >>>> From time to time I receive a user report with a NPE from Swing where > >>>> > >>>> little> > >>> > >>> or even no NetBeans code involved. Just today I got > >>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 > >>> We have about 35 other ones (which is not that much given the fact we > >>> have > >>> million of users), but still... > >>> > >>> According to > >>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 > >>> the report comes from jdk7u9-b05. The source code is here > >>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- > >>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java > >>> and thus it looks like the call on line 4468 to > >>> > >>> ui.getPathBounds(tree, newPath); > >>> > >>> can return null (under some rare and unknown circumstances). > >>> > >>> I can close the bug #222081 as "worksforme", but it is clear that such > >>> error happens from time to time and we don't want our users to face > >>> errors. A simple: > >>> > >>> 4469 if (newRect == null) return; > >>> > >>> would do the trick. One question remains: if I try to donate such patch, > >>> will you accept it? > >>> > >> The ui.getPathBounds(tree, newPath) method definitely can return > >> > >> null so it needs to have this check. > >> > >> However, such fix can mask the real issue, for example, in the > >> > >> treeState.getBounds() method where the treeState can be instance of > >> FixedHeightLayoutCache or VariableHeightLayoutCache class. > >> > >> If it is possible, could you send a code snippet that shows how > >> > >> NetBeans uses JTree? May be it can give a hint what can be wrong in this > >> case. > >> > >> Thanks, > >> Alexandr. > >>> > >>> -jt From WLaan at costengineering.eu Fri Nov 16 15:17:22 2012 From: WLaan at costengineering.eu (Walter Laan) Date: Fri, 16 Nov 2012 15:17:22 +0000 Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <4054906.gg3VXlsrro@logoutik> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> <4054906.gg3VXlsrro@logoutik> Message-ID: <59CA7531B79CD24C9220F8C952EF389E13DFB9F1@EXCH2010.ce.local> For what it's worth, I've reports of a similar exceptions (in 7u7), but it happens during an automated GUI test (with QFTest) which generates the mouse events and I've not been able to reproduce it in a manual test case. However, since the javadoc for BasicTreeUI#getPathBounds says it can return null, the result should be checked for null where ever it is called. There are several places where this does not happen yet after the fix for 6505523. java.lang.NullPointerException at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(Unknown Source) // I assume this is at line 3573 in 7u7 at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleasedDND(Unknown Source) at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleased(Unknown Source) at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source) Regards, Walter Laan -----Original Message----- From: swing-dev-bounces at openjdk.java.net [mailto:swing-dev-bounces at openjdk.java.net] On Behalf Of Jaroslav Tulach Sent: vrijdag 16 november 2012 15:29 To: Alexander Scherbatiy Cc: swing-dev at openjdk.java.net Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 Hello Alexander, if you scroll down the page with the report http://statistics.netbeans.org/exceptions/exception.do?id=628832 you'll see list of user actions. Click on individual ones to get more info. One of the last actions is 5:34 PM Select in Projects it was invoked via keyboard shortcut (Ctrl-Shift-1). Looking at the XML file I found out that the actual time was 17:34:23. Then the user switched back to editor (again via shortcut this time Ctrl-Shift-0) about 1.5s later at 17:34:24: 5:34 PM Editor A two seconds later (at 17:34:26) the NPE from JTree appeared: java.lang.NullPointerException at javax.swing.plaf.basic.BasicTreeUI$Actions.page(rt.jar:4470) at javax.swing.plaf.basic.BasicTreeUI$Actions.actionPerformed(rt.jar:4046) at javax.swing.SwingUtilities.notifyAction(rt.jar:1664) We don't have logs about what the user did inside of the "Projects" component with JTree, but there seems to be no radical tree structure changes (no creation or deletion of files). The fact that the NPE happens more than a second after the user leaves the JTree hosting component is surprising. But maybe the JTree was not visible anymore - many users (including me) have the IDE configured to hide the "Projects tab" as soon as we switch to editor... I am not sure what to conclude from these observation, however. -jt Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): > On 11/16/2012 4:10 PM, Jaroslav Tulach wrote: > > Hello Alexander, > > thanks for your reply. The source code for NetBeans TreeView > > component is available here: > > http://hg.netbeans.org/main- > > golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/v > > iew/Tr eeView.java I'll be glad for any review, however I am also > > positively pleased by your > > answer: > Is it possible to know from the filled NB issues which NB > module/component has been used when the NPE occures? > Or could you point any NB panel where the TreeView is used. > > >> The ui.getPathBounds(tree, newPath) method definitely can > >> return > >> > >> null so it needs to have this check. > > > > Should I start working on a webrev, so (in case you don't find any > > violation of good Swing practices in TreeView) we can eliminate this > > NPE once and forever? > Yes, please. > > > What should be part of such webrev? Just the NPE check? Or do you > > want some test, change in documentation, etc.? > > The fix should check the NPE and may be do some possible default > actions in this case. > It is a good idea to add an automated test but it can be possible > if there are known steps which reproduce the issue. > At least you can run the test/javax/swing/JTree automated test > to check possible regressions. > > Thanks, > Alexandr. > > > Thanks again for your comments. > > -jt > > > > Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): > >> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: > >>> Dear Swing maintainers, > >>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer > >>> - a component that is using JTree heavily. > >>> > >>>> From time to time I receive a user report with a NPE from Swing > >>>> where > >>>> > >>>> little> > >>> > >>> or even no NetBeans code involved. Just today I got > >>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 > >>> We have about 35 other ones (which is not that much given the fact > >>> we have million of users), but still... > >>> > >>> According to > >>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 > >>> the report comes from jdk7u9-b05. The source code is here > >>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- > >>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java > >>> and thus it looks like the call on line 4468 to > >>> > >>> ui.getPathBounds(tree, newPath); > >>> > >>> can return null (under some rare and unknown circumstances). > >>> > >>> I can close the bug #222081 as "worksforme", but it is clear that > >>> such error happens from time to time and we don't want our users > >>> to face errors. A simple: > >>> > >>> 4469 if (newRect == null) return; > >>> > >>> would do the trick. One question remains: if I try to donate such > >>> patch, will you accept it? > >>> > >> The ui.getPathBounds(tree, newPath) method definitely can > >> return > >> > >> null so it needs to have this check. > >> > >> However, such fix can mask the real issue, for example, in > >> the > >> > >> treeState.getBounds() method where the treeState can be instance > >> of FixedHeightLayoutCache or VariableHeightLayoutCache class. > >> > >> If it is possible, could you send a code snippet that shows > >> how > >> > >> NetBeans uses JTree? May be it can give a hint what can be wrong in > >> this case. > >> > >> Thanks, > >> Alexandr. > >>> > >>> -jt From jviswana at linux.vnet.ibm.com Mon Nov 19 11:12:26 2012 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Mon, 19 Nov 2012 16:42:26 +0530 Subject: Review Request - Jcolorchooser Missing accessible name In-Reply-To: <505C4E93.5070809@oracle.com> References: <5051A78B.7050904@linux.vnet.ibm.com> <505AD26F.40307@linux.vnet.ibm.com> <505B0AC4.5080805@oracle.com> <505BEC32.2050604@linux.vnet.ibm.com> <505C4E93.5070809@oracle.com> Message-ID: <50AA141A.6030009@linux.vnet.ibm.com> On 21-09-2012 4:55 PM, Alexander Scherbatiy wrote: > On 9/21/2012 8:25 AM, jayashree viswanathan wrote: >> Hi Alexandar , >> >> Thanks for replying , Jcolorchooser code seems to have been change >> quite a bit, while I am able to see pretty old Sun bug relevant [ >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4631925]. >> Though This particular bug is related to spinner and sliders not >> having the accessible name , JFerret is able to show this, also AT >> tools like JAWS is not able to read the names of neither the colors >> nor the sliders name, while testing with swingset demo . >> >> The fix is intended to just add the accessible names so that there is >> some help for the AT tools . Post this fix , I was able to see >> JFerret picking things up and AT able to read the accessible name. > > I run the NetBeans accessibility plugin from a11y.netbeans.org for > JColorChooser and for example for HSL tab it shows: > ----------------------------------------------------------- > No Accessible name : > Class: javax.swing.JFormattedTextField { | } > Class: javax.swing.JSlider { | } > > No Accessible description : > Class: javax.swing.JFormattedTextField { | } > Class: javax.swing.JRadioButton { Hue | } > Class: javax.swing.JRadioButton { Lightness | } > Class: javax.swing.JRadioButton { Saturation | } > Class: javax.swing.JSlider { | } > Class: javax.swing.JTabbedPane { HSL | } > ----------------------------------------------------------- > Full report can be found at > http://cr.openjdk.java.net/~alexsch/others/colorchooser/a11n/01/ > > > May be it has sense to fix all accessible names in one issue so > other tools will not have problem with it? > > Thanks, > Alexandr. > >> >> Thanks and Regards, >> Jayashree Viswanathan >> >> >> On 20-09-2012 5:53 PM, Alexander Scherbatiy wrote: >>> Hi, >>> >>> Could you send the bug ID of the problem? >>> It is not clear for me is the issue related only to the spinners >>> accessible names or to all components on the JColorChooser. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 9/20/2012 12:23 PM, jayashree viswanathan wrote: >>>> Hi, >>>> >>>> Can some one please review this request ? >>>> >>>> Thanks and Regards, >>>> Jayashree Viswanathan >>>> >>>> On 13-09-2012 2:59 PM, jayashree viswanathan wrote: >>>>> Hi , >>>>> >>>>> Jcolorchooser doesn't seems to have accessible name in sliders etc., >>>>> >>>>> \bin\java.exe -jar >>>>> \demo\jfc\SwingSet2\SwingSet2.jar >>>>> 1) Run Java ferret enabling accessibility trace option >>>>> 2) Go to ColorChooser tab >>>>> 3) Select gradient1/any of the choices >>>>> 4) for instance in swatches/HSL tabs, spinners are without any >>>>> accessibility name >>>>> 5) for instance Sliders in HSL and rest of the tabs that follows >>>>> also are not having accessibility name >>>>> >>>>> webrev changes are available at >>>>> http://cr.openjdk.java.net/~shirishk/20120913_01/webrev.01/ >>>>> >>>>> Thanks and Regards, >>>>> Jayashree Viswanathan >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > Hi Alexandr, Please find the updated CR and the results in the below link . http://cr.openjdk.java.net/~jviswana/4631925/ I have fixed all the accessible name issues reported by the a11y tool in this for the ColorChooser and the result post that is also available in the same location . Thanks and Regards, Jayashree V From alexandr.scherbatiy at oracle.com Mon Nov 19 13:30:52 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 19 Nov 2012 17:30:52 +0400 Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <59CA7531B79CD24C9220F8C952EF389E13DFB9F1@EXCH2010.ce.local> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> <4054906.gg3VXlsrro@logoutik> <59CA7531B79CD24C9220F8C952EF389E13DFB9F1@EXCH2010.ce.local> Message-ID: <50AA348C.4060401@oracle.com> On 11/16/2012 7:17 PM, Walter Laan wrote: > For what it's worth, I've reports of a similar exceptions (in 7u7), but it happens during an automated GUI test (with QFTest) which generates the mouse events and I've not been able to reproduce it in a manual test case. Could you send the source code of the automated test? This really helps to understand why the getPathBounds(tree, pressedPath) method returns null. Thanks, Alexandr. > However, since the javadoc for BasicTreeUI#getPathBounds says it can return null, the result should be checked for null where ever it is called. There are several places where this does not happen yet after the fix for 6505523. > > java.lang.NullPointerException > at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(Unknown Source) // I assume this is at line 3573 in 7u7 > at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleasedDND(Unknown Source) > at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleased(Unknown Source) > at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source) > > Regards, > Walter Laan > > -----Original Message----- > From: swing-dev-bounces at openjdk.java.net [mailto:swing-dev-bounces at openjdk.java.net] On Behalf Of Jaroslav Tulach > Sent: vrijdag 16 november 2012 15:29 > To: Alexander Scherbatiy > Cc: swing-dev at openjdk.java.net > Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 > > Hello Alexander, > if you scroll down the page with the report > http://statistics.netbeans.org/exceptions/exception.do?id=628832 > you'll see list of user actions. Click on individual ones to get more info. > > One of the last actions is > > 5:34 PM Select in Projects > > it was invoked via keyboard shortcut (Ctrl-Shift-1). Looking at the XML file I found out that the actual time was 17:34:23. Then the user switched back to editor (again via shortcut this time Ctrl-Shift-0) about 1.5s later at > 17:34:24: > > 5:34 PM Editor > > A two seconds later (at 17:34:26) the NPE from JTree appeared: > > java.lang.NullPointerException > at javax.swing.plaf.basic.BasicTreeUI$Actions.page(rt.jar:4470) > at javax.swing.plaf.basic.BasicTreeUI$Actions.actionPerformed(rt.jar:4046) > at javax.swing.SwingUtilities.notifyAction(rt.jar:1664) > > We don't have logs about what the user did inside of the "Projects" component with JTree, but there seems to be no radical tree structure changes (no creation or deletion of files). > > The fact that the NPE happens more than a second after the user leaves the JTree hosting component is surprising. But maybe the JTree was not visible anymore - many users (including me) have the IDE configured to hide the "Projects tab" as soon as we switch to editor... > > I am not sure what to conclude from these observation, however. > -jt > > Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): >> On 11/16/2012 4:10 PM, Jaroslav Tulach wrote: >>> Hello Alexander, >>> thanks for your reply. The source code for NetBeans TreeView >>> component is available here: >>> http://hg.netbeans.org/main- >>> golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/v >>> iew/Tr eeView.java I'll be glad for any review, however I am also >>> positively pleased by your >>> answer: >> Is it possible to know from the filled NB issues which NB >> module/component has been used when the NPE occures? >> Or could you point any NB panel where the TreeView is used. >> >>>> The ui.getPathBounds(tree, newPath) method definitely can >>>> return >>>> >>>> null so it needs to have this check. >>> Should I start working on a webrev, so (in case you don't find any >>> violation of good Swing practices in TreeView) we can eliminate this >>> NPE once and forever? >> Yes, please. >> >>> What should be part of such webrev? Just the NPE check? Or do you >>> want some test, change in documentation, etc.? >> The fix should check the NPE and may be do some possible default >> actions in this case. >> It is a good idea to add an automated test but it can be possible >> if there are known steps which reproduce the issue. >> At least you can run the test/javax/swing/JTree automated test >> to check possible regressions. >> >> Thanks, >> Alexandr. >> >>> Thanks again for your comments. >>> -jt >>> >>> Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): >>>> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: >>>>> Dear Swing maintainers, >>>>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer >>>>> - a component that is using JTree heavily. >>>>> >>>>>> From time to time I receive a user report with a NPE from Swing >>>>>> where >>>>>> >>>>>> little> >>>>> or even no NetBeans code involved. Just today I got >>>>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 >>>>> We have about 35 other ones (which is not that much given the fact >>>>> we have million of users), but still... >>>>> >>>>> According to >>>>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 >>>>> the report comes from jdk7u9-b05. The source code is here >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- >>>>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java >>>>> and thus it looks like the call on line 4468 to >>>>> >>>>> ui.getPathBounds(tree, newPath); >>>>> >>>>> can return null (under some rare and unknown circumstances). >>>>> >>>>> I can close the bug #222081 as "worksforme", but it is clear that >>>>> such error happens from time to time and we don't want our users >>>>> to face errors. A simple: >>>>> >>>>> 4469 if (newRect == null) return; >>>>> >>>>> would do the trick. One question remains: if I try to donate such >>>>> patch, will you accept it? >>>>> >>>> The ui.getPathBounds(tree, newPath) method definitely can >>>> return >>>> >>>> null so it needs to have this check. >>>> >>>> However, such fix can mask the real issue, for example, in >>>> the >>>> >>>> treeState.getBounds() method where the treeState can be instance >>>> of FixedHeightLayoutCache or VariableHeightLayoutCache class. >>>> >>>> If it is possible, could you send a code snippet that shows >>>> how >>>> >>>> NetBeans uses JTree? May be it can give a hint what can be wrong in >>>> this case. >>>> >>>> Thanks, >>>> Alexandr. >>>>> -jt From alexandr.scherbatiy at oracle.com Mon Nov 19 15:06:54 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 19 Nov 2012 19:06:54 +0400 Subject: Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring In-Reply-To: <50A41A8F.7070404@oracle.com> References: <509D7545.6020903@oracle.com> <50A41A8F.7070404@oracle.com> Message-ID: <50AA4B0E.3070600@oracle.com> The fix looks good for me. Thanks, Alexandr. On 11/15/2012 2:26 AM, Pete Brunet wrote: > Some more code has been added. A counter has been added to each of > the three files. It is incremented when addPropertyChangeListener is > called and decremented when removePropertyChangeListener is called. > Only when the count is zero, i.e. the first add and last remove, do > specific handlers (see below) get added/removed. > > Component.java: This code has Component and Focus handlers. > > Container.java: This code has a Container handler. > > JComponent.java: This code has Container and Focus handlers. > > See http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.01/ > > Pete > > -------- Original Message -------- > Subject: Please review fix for 7179482 : > Component.accessibleContext and JComponent.accessibleContext refactoring > Date: Fri, 09 Nov 2012 15:27:33 -0600 > From: Pete Brunet > Reply-To: peter.brunet at oracle.com > To: awt-dev , swing-dev at openjdk.java.net > > > > Please review the following fix planned for JDK8. Part of the fix will > go into 7u12 under 7177111. > > Problem: > In the process of evaluating 7177111 the following problems were noticed: > - Both Component and JComponent have field "accessibleContext". In > Component it is package-private and accessed by other classes from > java.awt, but in JComponent it is protected and therefore this field > hides the same superclass field from any subclass. These two fields > should be refactored to a single protected field in Component. > - Container.AccessibleAWTContainer has an addPropertyChangeListener but > not a removePropertyChangeListener. This method is needed so stale > listeners can be removed when AT are no longer attached to a Java process. > - The JComponent.AccessibleJComponent.accessibleFocusHandler field > functionally duplicates its superclass field, > Component.AccessibleAWTComponent.accessibleAWTFocusHandler. When this > field is used properly there are no logical issues. However, the > existence of this field could cause confusion for a developer trying to > understand the code. The superclass field is sufficient. > > Solution: > - Change java.awt.Component.accessibleContext from package-private to > protected. This will allow use by subclasses and the removal of the > duplicate field in javax.swing.JComponent. > - Add > java.awt.Container.AccessibleAWTContainer.removePropertyChangeListener > so stale listeners can be removed when an Assistive Technology is no > longer attached to a Java process. > - Remove the protected field javax.swing.JComponent.accessibleContext. > Instead the protected field java.awt.Component.accessibleContext, will > be used. With the change subclasses would now use the protected field > in the Component superclass. > - Remove public method javax.swing.JComponent.getAccessibleContext. > Instead it superclass public method > java.awt.Component.getAccessibleContext method would be used. > - javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler > field will be deprecated. Developers should use the > java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler > field instead. > > Webrev:http://cr.openjdk.java.net/~ptbrunet/7179482/webrev.00/ > Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179482 > CCC:http://ccc.us.oracle.com/7179482 > > > From alexandr.scherbatiy at oracle.com Tue Nov 20 10:01:49 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 20 Nov 2012 14:01:49 +0400 Subject: Review Request - Jcolorchooser Missing accessible name In-Reply-To: <50AA141A.6030009@linux.vnet.ibm.com> References: <5051A78B.7050904@linux.vnet.ibm.com> <505AD26F.40307@linux.vnet.ibm.com> <505B0AC4.5080805@oracle.com> <505BEC32.2050604@linux.vnet.ibm.com> <505C4E93.5070809@oracle.com> <50AA141A.6030009@linux.vnet.ibm.com> Message-ID: <50AB550D.70301@oracle.com> On 11/19/2012 3:12 PM, jayashree viswanathan wrote: > > Hi Alexandr, > > Please find the updated CR and the results in the below link . > > http://cr.openjdk.java.net/~jviswana/4631925/ > > I have fixed all the accessible name issues reported by the a11y tool > in this for the ColorChooser and the result post that is also > available in the same location . before fix: http://cr.openjdk.java.net/~alexsch/others/colorchooser/a11n/01/a11n_CMYK.txt after fix: http://cr.openjdk.java.net/~jviswana/4631925/temp/CMYK.txt The 'No Accessible name' list is empty now for the CMYK tab. But the 'No Accessible description' contains lines like: Class: javax.swing.JFormattedTextField { Alpha | } after the fix. It seems that accessible descriptions should be also set with accessible names. Thanks, Alexandr. > > Thanks and Regards, > Jayashree V > From jaroslav.tulach at oracle.com Tue Nov 20 15:17:36 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 20 Nov 2012 16:17:36 +0100 Subject: jtreg test was:: Patch for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <50A6470D.7000805@oracle.com> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> Message-ID: <17812261.8996tqQ4xK@logoutik> Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): > It is a good idea to add an automated test but it can be possible > if there are known steps which reproduce the issue. Hello Alexander, I am trying to create the test. I've got jdk8-b65 sources, built them and then I tried to run the JTree tests. But they are failing! /src/jdk8/jdk/test$ jtreg -jdk:src/jdk8/build/linux-i586/j2sdk-image/ javax/swing/JTree Test results: passed: 3; failed: 2 What should I do? Just ignore the two failing tests and add my own anyway? -jt PS: My version of jtreg maybe a bit outdated, if that matters: /src/jdk8/jdk/test$ jtreg -jdk:/src/jdk8/build/linux-i586/j2sdk-image/ - version jtreg, version 4.1 fcs b03 Installed in /bin/jtreg.dir/lib/jtreg.jar Running on platform version 1.8.0-internal from /src/jdk8/build/linux- i586/j2sdk-image/jre. Built with Java(TM) 2 SDK, Version 1.5.0-b64 on July 11, 2011. Copyright 2008 Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. From alexandr.scherbatiy at oracle.com Wed Nov 21 08:57:36 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 21 Nov 2012 12:57:36 +0400 Subject: jtreg test was:: Patch for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <17812261.8996tqQ4xK@logoutik> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> <17812261.8996tqQ4xK@logoutik> Message-ID: <50AC9780.8010206@oracle.com> On 11/20/2012 7:17 PM, Jaroslav Tulach wrote: > Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): >> It is a good idea to add an automated test but it can be possible >> if there are known steps which reproduce the issue. > Hello Alexander, > I am trying to create the test. I've got jdk8-b65 sources, built them and then > I tried to run the JTree tests. But they are failing! > > /src/jdk8/jdk/test$ jtreg -jdk:src/jdk8/build/linux-i586/j2sdk-image/ > javax/swing/JTree > Test results: passed: 3; failed: 2 That is strange. All 5 JTree tests (1 manual and 4 automated) passes on my Ubuntu with the built jdk 8. Could you send the the log of the failed tests (JTwork/javax/swing/JTree/bugid/*.jtr files)? Note that a user should not move the mouse during tests execution. It can fail the tests. > What should I do? Just ignore the two failing tests and add my own anyway? The requirement is that all passed tests before a fix should also pass after the fix. Thanks, Alexandr. > -jt > > > PS: My version of jtreg maybe a bit outdated, if that matters: > > /src/jdk8/jdk/test$ jtreg -jdk:/src/jdk8/build/linux-i586/j2sdk-image/ - > version > jtreg, version 4.1 fcs b03 > Installed in /bin/jtreg.dir/lib/jtreg.jar > Running on platform version 1.8.0-internal from /src/jdk8/build/linux- > i586/j2sdk-image/jre. > Built with Java(TM) 2 SDK, Version 1.5.0-b64 on July 11, 2011. > Copyright 2008 Oracle and/or its affiliates. All rights reserved. > Use is subject to license terms. > From jaroslav.tulach at oracle.com Wed Nov 21 09:02:38 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 21 Nov 2012 10:02:38 +0100 Subject: Webrev for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <50A6470D.7000805@oracle.com> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> Message-ID: <1739283.93MTExHSUT@logoutik> Hello again. Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): > >> The ui.getPathBounds(tree, newPath) method definitely can return > >> null so it needs to have this check. > > > > Should I start working on a webrev, so (in case you don't find any > > violation of good Swing practices in TreeView) we can eliminate this NPE > > once and forever? > Yes, please. Here is my proposed fix: http://xelfi.cz/webrev/NB222081/ > The fix should check the NPE and may be do some possible default > actions in this case. Done. As this is just about navigation and selection, I think doing nothing is a reasonable default. > It is a good idea to add an automated test but it can be possible > if there are known steps which reproduce the issue. I created an automated test, but it is just artificial one - it returns null for no reason and only checks the caller is ready for such situation. That is the best I was able to come up. > At least you can run the test/javax/swing/JTree automated test to > check possible regressions. As I wrote yesterday. The results before my fix were: > Test results: passed: 3; failed: 2 and after my fix > Test results: passed: 4; failed: 2 - e.g. I am almost sure that my patch causes no regressions. Btw. I included artificial bug number 9999999 in the test right now (as there is no bugtraq/bugdb report for the NPE afaik). I also tried to reference the NetBeans bug (by name of the directory and test). I can of course change that according to your suggestions. Thanks in advance for your review. -jt > > Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): > >> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: > >>> Dear Swing maintainers, > >>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a > >>> component that is using JTree heavily. > >>> > >>>> From time to time I receive a user report with a NPE from Swing where > >>>> > >>>> little> > >>> > >>> or even no NetBeans code involved. Just today I got > >>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 > >>> We have about 35 other ones (which is not that much given the fact we > >>> have > >>> million of users), but still... > >>> > >>> According to > >>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 > >>> the report comes from jdk7u9-b05. The source code is here > >>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- > >>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java > >>> and thus it looks like the call on line 4468 to > >>> > >>> ui.getPathBounds(tree, newPath); > >>> > >>> can return null (under some rare and unknown circumstances). > >>> > >>> I can close the bug #222081 as "worksforme", but it is clear that such > >>> error happens from time to time and we don't want our users to face > >>> errors. A simple: > >>> > >>> 4469 if (newRect == null) return; > >>> > >>> would do the trick. One question remains: if I try to donate such patch, > >>> will you accept it? > >>> > >> The ui.getPathBounds(tree, newPath) method definitely can return > >> > >> null so it needs to have this check. > >> > >> However, such fix can mask the real issue, for example, in the > >> > >> treeState.getBounds() method where the treeState can be instance of > >> FixedHeightLayoutCache or VariableHeightLayoutCache class. > >> > >> If it is possible, could you send a code snippet that shows how > >> > >> NetBeans uses JTree? May be it can give a hint what can be wrong in this > >> case. > >> > >> Thanks, > >> Alexandr. > >>> > >>> -jt From jaroslav.tulach at oracle.com Wed Nov 21 09:07:29 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 21 Nov 2012 10:07:29 +0100 Subject: jtreg test In-Reply-To: <50AC9780.8010206@oracle.com> References: <6868828.OWPBIWenVZ@logoutik> <17812261.8996tqQ4xK@logoutik> <50AC9780.8010206@oracle.com> Message-ID: <1565159.ocf4icBF8S@logoutik> Dne St 21. listopadu 2012 12:57:36, Alexander Scherbatiy napsal(a): > On 11/20/2012 7:17 PM, Jaroslav Tulach wrote: > That is strange. All 5 JTree tests (1 manual and 4 automated) > passes on my Ubuntu with the built jdk 8. I am running Kubuntu 12.04. > Could you send the the log of the failed tests > (JTwork/javax/swing/JTree/bugid/*.jtr files)? Attached. > Note that a user should not move the mouse during tests execution. > It can fail the tests. Both tests seem to fail consistently. -jt -------------- next part -------------- #Test Results (version 2) #Wed Nov 21 09:57:35 CET 2012 #checksum:1ff9dec5dd9f6ae5 #-----testdescription----- $file=/home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/bug4330357.java $root=/home/jarda/src/jdk8/jdk/test author=Peter Zhelezniakov keywords=bug4330357 library=../../regtesthelpers run=USER_SPECIFIED build Util\nUSER_SPECIFIED main bug4330357\n source=bug4330357.java title=Tests that real editor in JTree cleans up after editing was stopped #-----environment----- #-----testresult----- description=file:/home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/bug4330357.java elapsed=3138 0:00:03.138 end=Wed Nov 21 09:57:35 CET 2012 environment=regtest execStatus=Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Cell editor is missed for path: color hostname=logoutik javatestOS=Linux 3.2.0-33-generic-pae (i386) javatestVersion=4.1.4 script=com.sun.javatest.regtest.RegressionScript sections=script_messages build compile build compile main start=Wed Nov 21 09:57:32 CET 2012 test=javax/swing/JTree/4330357/bug4330357.java work=/home/jarda/src/jdk8/jdk/test/javax/swing/JTwork/javax/swing/JTree/4330357 #section:script_messages ----------messages:(4/226)---------- JDK under test: (/home/jarda/src/jdk8/build/linux-i586/j2sdk-image) openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-jarda_2012_11_19_18_48-b00) OpenJDK Server VM (build 25.0-b09, mixed mode) #section:build ----------messages:(3/97)---------- command: build Util reason: User specified action: run build Util elapsed time (seconds): 0.817 result: Passed. Build successful #section:compile ----------messages:(3/184)---------- command: compile /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/../../regtesthelpers/Util.java reason: .class file out of date or does not exist elapsed time (seconds): 0.816 ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:build ----------messages:(3/95)---------- command: build bug4330357 reason: Named class compiled on demand elapsed time (seconds): 0.703 result: Passed. Build successful #section:compile ----------messages:(3/169)---------- command: compile /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/bug4330357.java reason: .class file out of date or does not exist elapsed time (seconds): 0.702 ----------System.out:(0/0)---------- ----------System.err:(12/893)---------- /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/bug4330357.java:37: warning: SunToolkit is internal proprietary API and may be removed in a future release import sun.awt.SunToolkit; ^ /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/bug4330357.java:46: warning: SunToolkit is internal proprietary API and may be removed in a future release SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); ^ /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/bug4330357.java:46: warning: SunToolkit is internal proprietary API and may be removed in a future release SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); ^ Note: /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/4330357/bug4330357.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 3 warnings result: Passed. Compilation successful #section:main ----------messages:(3/107)---------- command: main bug4330357 reason: User specified action: run main bug4330357 elapsed time (seconds): 1.613 ----------System.out:(0/0)---------- ----------System.err:(13/763)---------- java.lang.RuntimeException: Cell editor is missed for path: color at bug4330357.main(bug4330357.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:722) JavaTest Message: Test threw exception: java.lang.RuntimeException: Cell editor is missed for path: color JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Cell editor is missed for path: color result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Cell editor is missed for path: color test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Cell editor is missed for path: color -------------- next part -------------- #Test Results (version 2) #Wed Nov 21 09:57:42 CET 2012 #checksum:463feaf0b692beb4 #-----testdescription----- $file=/home/jarda/src/jdk8/jdk/test/javax/swing/JTree/6263446/bug6263446.java $root=/home/jarda/src/jdk8/jdk/test author=Shannon Hickey keywords=bug6263446 run=USER_SPECIFIED main bug6263446\n source=bug6263446.java title=Tests that double-clicking to edit a cell doesn't select the content. #-----environment----- #-----testresult----- description=file:/home/jarda/src/jdk8/jdk/test/javax/swing/JTree/6263446/bug6263446.java elapsed=3789 0:00:03.789 end=Wed Nov 21 09:57:42 CET 2012 environment=regtest execStatus=Failed. Execution failed: `main' threw exception: java.lang.reflect.InvocationTargetException hostname=logoutik javatestOS=Linux 3.2.0-33-generic-pae (i386) javatestVersion=4.1.4 script=com.sun.javatest.regtest.RegressionScript sections=script_messages build compile main start=Wed Nov 21 09:57:38 CET 2012 test=javax/swing/JTree/6263446/bug6263446.java work=/home/jarda/src/jdk8/jdk/test/javax/swing/JTwork/javax/swing/JTree/6263446 #section:script_messages ----------messages:(4/226)---------- JDK under test: (/home/jarda/src/jdk8/build/linux-i586/j2sdk-image) openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-jarda_2012_11_19_18_48-b00) OpenJDK Server VM (build 25.0-b09, mixed mode) #section:build ----------messages:(3/95)---------- command: build bug6263446 reason: Named class compiled on demand elapsed time (seconds): 0.831 result: Passed. Build successful #section:compile ----------messages:(3/169)---------- command: compile /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/6263446/bug6263446.java reason: .class file out of date or does not exist elapsed time (seconds): 0.831 ----------System.out:(0/0)---------- ----------System.err:(10/684)---------- /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/6263446/bug6263446.java:36: warning: SunToolkit is internal proprietary API and may be removed in a future release import sun.awt.SunToolkit; ^ /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/6263446/bug6263446.java:45: warning: SunToolkit is internal proprietary API and may be removed in a future release private static SunToolkit toolkit; ^ /home/jarda/src/jdk8/jdk/test/javax/swing/JTree/6263446/bug6263446.java:48: warning: SunToolkit is internal proprietary API and may be removed in a future release toolkit = (SunToolkit) Toolkit.getDefaultToolkit(); ^ 3 warnings result: Passed. Compilation successful #section:main ----------messages:(3/107)---------- command: main bug6263446 reason: User specified action: run main bug6263446 elapsed time (seconds): 2.957 ----------System.out:(0/0)---------- ----------System.err:(33/2011)---------- java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:1270) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) at bug6263446.assertEditingNoTreeLock(bug6263446.java:257) at bug6263446.assertEditing(bug6263446.java:247) at bug6263446.main(bug6263446.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.RuntimeException: Tree should be editing at bug6263446$7.run(bug6263446.java:262) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:720) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:681) at java.awt.EventQueue$3.run(EventQueue.java:679) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:690) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:244) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:147) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:139) at java.awt.EventDispatchThread.run(EventDispatchThread.java:97) JavaTest Message: Test threw exception: java.lang.reflect.InvocationTargetException JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.reflect.InvocationTargetException result: Failed. Execution failed: `main' threw exception: java.lang.reflect.InvocationTargetException test result: Failed. Execution failed: `main' threw exception: java.lang.reflect.InvocationTargetException From Sergey.Bylokhov at oracle.com Wed Nov 21 12:54:52 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 21 Nov 2012 16:54:52 +0400 Subject: [8] Please review fix for 8003273: Missing testcase for 7171812 In-Reply-To: <50A51A55.1010309@oracle.com> References: <50A51A55.1010309@oracle.com> Message-ID: <50ACCF1C.4040108@oracle.com> Hi, Alexander. Fix looks fine. 15.11.2012 20:37, Alexander Zuev wrote: > Please review my test for CR 8003273: Missing testcase for 7171812 > > The new regression test can be found at > http://cr.openjdk.java.net/~kizune/8003273/webrev.00/ > Bug description is available at > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003273 > > With best regards, > Alex -- Best regards, Sergey. From artem.ananiev at oracle.com Wed Nov 21 13:04:18 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 21 Nov 2012 17:04:18 +0400 Subject: [8] Please review fix for 8003273: Missing testcase for 7171812 In-Reply-To: <50A51A55.1010309@oracle.com> References: <50A51A55.1010309@oracle.com> Message-ID: <50ACD152.5050602@oracle.com> Looks fine. Thanks, Artem On 11/15/2012 8:37 PM, Alexander Zuev wrote: > Please review my test for CR 8003273: Missing testcase for 7171812 > > The new regression test can be found at > http://cr.openjdk.java.net/~kizune/8003273/webrev.00/ > Bug description is available at > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003273 > > With best regards, > Alex From alexandr.scherbatiy at oracle.com Wed Nov 21 14:42:39 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 21 Nov 2012 18:42:39 +0400 Subject: Webrev for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <1739283.93MTExHSUT@logoutik> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> <1739283.93MTExHSUT@logoutik> Message-ID: <50ACE85F.4090802@oracle.com> On 11/21/2012 1:02 PM, Jaroslav Tulach wrote: > Here is my proposed fix: > http://xelfi.cz/webrev/NB222081/ The fix looks good for me. > I created an automated test, but it is just artificial one - it returns null > for no reason and only checks the caller is ready for such situation. That is > the best I was able to come up. That is fine. >> At least you can run the test/javax/swing/JTree automated test to >> check possible regressions. > - e.g. I am almost sure that my patch causes no regressions. > > Btw. I included artificial bug number 9999999 in the test right now (as there > is no bugtraq/bugdb report for the NPE afaik). I also tried to reference the > NetBeans bug (by name of the directory and test). I can of course change that > according to your suggestions. I have created an issue on it: 8003830 NullPointerException at javax.swing.plaf.basic.BasicTreeUI$Actions.page Please, use this number for the test name. The updated webrev should be put to cr.openjdk.java.net (you could ask anyone from this alias to do that). Please, use the following email as a template for the updated review request. http://mail.openjdk.java.net/pipermail/swing-dev/2012-June/002150.html Thanks, Alexandr. > Thanks in advance for your review. > -jt > >>> Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): >>>> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: >>>>> Dear Swing maintainers, >>>>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a >>>>> component that is using JTree heavily. >>>>> >>>>>> From time to time I receive a user report with a NPE from Swing where >>>>>> >>>>>> little> >>>>> or even no NetBeans code involved. Just today I got >>>>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 >>>>> We have about 35 other ones (which is not that much given the fact we >>>>> have >>>>> million of users), but still... >>>>> >>>>> According to >>>>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 >>>>> the report comes from jdk7u9-b05. The source code is here >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- >>>>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java >>>>> and thus it looks like the call on line 4468 to >>>>> >>>>> ui.getPathBounds(tree, newPath); >>>>> >>>>> can return null (under some rare and unknown circumstances). >>>>> >>>>> I can close the bug #222081 as "worksforme", but it is clear that such >>>>> error happens from time to time and we don't want our users to face >>>>> errors. A simple: >>>>> >>>>> 4469 if (newRect == null) return; >>>>> >>>>> would do the trick. One question remains: if I try to donate such patch, >>>>> will you accept it? >>>>> >>>> The ui.getPathBounds(tree, newPath) method definitely can return >>>> >>>> null so it needs to have this check. >>>> >>>> However, such fix can mask the real issue, for example, in the >>>> >>>> treeState.getBounds() method where the treeState can be instance of >>>> FixedHeightLayoutCache or VariableHeightLayoutCache class. >>>> >>>> If it is possible, could you send a code snippet that shows how >>>> >>>> NetBeans uses JTree? May be it can give a hint what can be wrong in this >>>> case. >>>> >>>> Thanks, >>>> Alexandr. >>>>> -jt From alexandr.scherbatiy at oracle.com Wed Nov 21 15:09:35 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 21 Nov 2012 19:09:35 +0400 Subject: jtreg test In-Reply-To: <1565159.ocf4icBF8S@logoutik> References: <6868828.OWPBIWenVZ@logoutik> <17812261.8996tqQ4xK@logoutik> <50AC9780.8010206@oracle.com> <1565159.ocf4icBF8S@logoutik> Message-ID: <50ACEEAF.7060600@oracle.com> I have created an issue on it: 8003839 JTree tests bug4330357 and bug6263446 fails on Kubuntu Thanks, Alexandr. On 11/21/2012 1:07 PM, Jaroslav Tulach wrote: > Dne St 21. listopadu 2012 12:57:36, Alexander Scherbatiy napsal(a): >> On 11/20/2012 7:17 PM, Jaroslav Tulach wrote: >> That is strange. All 5 JTree tests (1 manual and 4 automated) >> passes on my Ubuntu with the built jdk 8. > I am running Kubuntu 12.04. > >> Could you send the the log of the failed tests >> (JTwork/javax/swing/JTree/bugid/*.jtr files)? > Attached. > >> Note that a user should not move the mouse during tests execution. >> It can fail the tests. > Both tests seem to fail consistently. > -jt From konstantin.shefov at oracle.com Thu Nov 22 11:29:30 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 22 Nov 2012 15:29:30 +0400 Subject: [8] Review request for 7124242 [macosx] Test doesn't work because of the frame round corners in the LaF In-Reply-To: <50A641C9.7030201@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A5FE62.3030507@oracle.com> <50A641C9.7030201@oracle.com> Message-ID: <50AE0C9A.2040702@oracle.com> Could you please look at this test fix? Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ On 16-Nov-12 17:38, Alexander Scherbatiy wrote: > > The fix looks good for me. > > Could you also create an issue in the awt subcategory that the > SunToolkit.realSync() method does not properly work on Mac OS X. > > Thanks, > Alexandr. > > On 11/16/2012 12:50 PM, Konstantin Shefov wrote: >> Could you please look at this test fix? >> >> Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ >> >> JFrame was undecorated to make test pass on MacOSX and Windows 7 with >> Aero. >> >> Thanks, >> Konstantin > From konstantin.shefov at oracle.com Thu Nov 22 11:31:35 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 22 Nov 2012 15:31:35 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <509CC335.2010908@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> Message-ID: <50AE0D17.3070102@oracle.com> Please review a fix for this issue: http://cr.openjdk.java.net/~kshefov/7124209/webrev.02 On 09-Nov-12 12:47, Alexander Scherbatiy wrote: > On 11/8/2012 4:25 PM, Konstantin Shefov wrote: >> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ >> > > The fix looks good for me. > > Thanks, > Alexandr. > >> >> On 08-Nov-12 16:02, Alexander Scherbatiy wrote: >>> On 11/7/2012 7:00 PM, Konstantin Shefov wrote: >>>> Please, look at modified fix: >>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ >>>> >>> >>> Try/catch block in the main method catches RuntimeException as >>> well. So the jtreg passes the test even it really fails. >>> It is also a good idea to fail the test if the >>> SwingUtilities.invokeAndWait() throws an exception because it is >>> also a wrong situation. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >>>>> >>>>> - Please, remove comments and unnecessary System.out from the fix >>>>> - Create and check swing components on EDT. Avoiding this rule >>>>> can leads to unpredictable test failures. >>>>> - Swing tests usually have bugBugID.java or some meaningful name. >>>>> - It is better to use the swing-dev at openjdk.java.net alias to >>>>> review the swing tests. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for the issue: >>>>>> >>>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the >>>>>> range: [NORTH, SOUTH] >>>>>> >>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>>>>> >>>>>> It is suggested to move the test to open jdk. >>>>>> >>>>>> Thanks, >>>>>> Konstantin >>>>>> >>>>> >>> > From konstantin.shefov at oracle.com Thu Nov 22 11:32:39 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 22 Nov 2012 15:32:39 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50A63F4F.7080002@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A3BB2C.3000409@oracle.com> <50A63F4F.7080002@oracle.com> Message-ID: <50AE0D57.5000906@oracle.com> Could you please look at this test fix? Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ On 16-Nov-12 17:27, Alexander Scherbatiy wrote: > > The fix looks good for me. > > Thanks, > Alexandr. > > On 11/14/2012 7:39 PM, Konstantin Shefov wrote: >> Could you please look at this test fix? >> >> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >> >> It was test for Metal LaF, so I forced LaF to be Metal even on MacOS. >> Now the test passes on MacOSX. >> I also made Swing methods run on EDT. >> Test can be moved to OpenJDK as it is already in OpenJDK 6. >> >> Thanks, >> Konstantin > From yuri.nesterenko at oracle.com Thu Nov 22 11:50:57 2012 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 22 Nov 2012 15:50:57 +0400 Subject: [8] Review request for 7124242 [macosx] Test doesn't work because of the frame round corners in the LaF -- approved In-Reply-To: <50AE0C9A.2040702@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A5FE62.3030507@oracle.com> <50A641C9.7030201@oracle.com> <50AE0C9A.2040702@oracle.com> Message-ID: <50AE11A1.1010304@oracle.com> OK. -yan On 11/22/2012 03:29 PM, Konstantin Shefov wrote: > Could you please look at this test fix? > Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ > > > On 16-Nov-12 17:38, Alexander Scherbatiy wrote: >> >> The fix looks good for me. >> >> Could you also create an issue in the awt subcategory that the >> SunToolkit.realSync() method does not properly work on Mac OS X. >> >> Thanks, >> Alexandr. >> >> On 11/16/2012 12:50 PM, Konstantin Shefov wrote: >>> Could you please look at this test fix? >>> >>> Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ >>> >>> JFrame was undecorated to make test pass on MacOSX and Windows 7 with >>> Aero. >>> >>> Thanks, >>> Konstantin >> From anthony.petrov at oracle.com Thu Nov 22 13:47:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 22 Nov 2012 17:47:29 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <50AE0D17.3070102@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50AE0D17.3070102@oracle.com> Message-ID: <50AE2CF1.5010905@oracle.com> I'm not a Swing expert, but since the test is simply moved from closed repos, I guess it looks fine. -- best regards, Anthony On 11/22/12 15:31, Konstantin Shefov wrote: > Please review a fix for this issue: > http://cr.openjdk.java.net/~kshefov/7124209/webrev.02 > > On 09-Nov-12 12:47, Alexander Scherbatiy wrote: >> On 11/8/2012 4:25 PM, Konstantin Shefov wrote: >>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ >>> >> >> The fix looks good for me. >> >> Thanks, >> Alexandr. >> >>> >>> On 08-Nov-12 16:02, Alexander Scherbatiy wrote: >>>> On 11/7/2012 7:00 PM, Konstantin Shefov wrote: >>>>> Please, look at modified fix: >>>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ >>>>> >>>> >>>> Try/catch block in the main method catches RuntimeException as well. >>>> So the jtreg passes the test even it really fails. >>>> It is also a good idea to fail the test if the >>>> SwingUtilities.invokeAndWait() throws an exception because it is >>>> also a wrong situation. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >>>>>> >>>>>> - Please, remove comments and unnecessary System.out from the fix >>>>>> - Create and check swing components on EDT. Avoiding this rule can >>>>>> leads to unpredictable test failures. >>>>>> - Swing tests usually have bugBugID.java or some meaningful name. >>>>>> - It is better to use the swing-dev at openjdk.java.net alias to >>>>>> review the swing tests. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for the issue: >>>>>>> >>>>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the >>>>>>> range: [NORTH, SOUTH] >>>>>>> >>>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>>>>>> >>>>>>> It is suggested to move the test to open jdk. >>>>>>> >>>>>>> Thanks, >>>>>>> Konstantin >>>>>>> >>>>>> >>>> >> From anthony.petrov at oracle.com Thu Nov 22 13:48:32 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 22 Nov 2012 17:48:32 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50AE0D57.5000906@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A3BB2C.3000409@oracle.com> <50A63F4F.7080002@oracle.com> <50AE0D57.5000906@oracle.com> Message-ID: <50AE2D30.90907@oracle.com> Looks good given it's the same test from closed repos. -- best regards, Anthony On 11/22/12 15:32, Konstantin Shefov wrote: > Could you please look at this test fix? > Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ > > On 16-Nov-12 17:27, Alexander Scherbatiy wrote: >> >> The fix looks good for me. >> >> Thanks, >> Alexandr. >> >> On 11/14/2012 7:39 PM, Konstantin Shefov wrote: >>> Could you please look at this test fix? >>> >>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>> >>> It was test for Metal LaF, so I forced LaF to be Metal even on MacOS. >>> Now the test passes on MacOSX. >>> I also made Swing methods run on EDT. >>> Test can be moved to OpenJDK as it is already in OpenJDK 6. >>> >>> Thanks, >>> Konstantin >> From anthony.petrov at oracle.com Thu Nov 22 13:49:35 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 22 Nov 2012 17:49:35 +0400 Subject: [8] Review request for 7124242 [macosx] Test doesn't work because of the frame round corners in the LaF In-Reply-To: <50AE0C9A.2040702@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A5FE62.3030507@oracle.com> <50A641C9.7030201@oracle.com> <50AE0C9A.2040702@oracle.com> Message-ID: <50AE2D6F.3070604@oracle.com> Looks fine. -- best regards, Anthony On 11/22/12 15:29, Konstantin Shefov wrote: > Could you please look at this test fix? > Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ > > > On 16-Nov-12 17:38, Alexander Scherbatiy wrote: >> >> The fix looks good for me. >> >> Could you also create an issue in the awt subcategory that the >> SunToolkit.realSync() method does not properly work on Mac OS X. >> >> Thanks, >> Alexandr. >> >> On 11/16/2012 12:50 PM, Konstantin Shefov wrote: >>> Could you please look at this test fix? >>> >>> Webrev: http://cr.openjdk.java.net/~kshefov/7124242/webrev.00/ >>> >>> JFrame was undecorated to make test pass on MacOSX and Windows 7 with >>> Aero. >>> >>> Thanks, >>> Konstantin >> From konstantin.shefov at oracle.com Thu Nov 22 13:51:54 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 22 Nov 2012 17:51:54 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50AE2D30.90907@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A3BB2C.3000409@oracle.com> <50A63F4F.7080002@oracle.com> <50AE0D57.5000906@oracle.com> <50AE2D30.90907@oracle.com> Message-ID: <50AE2DFA.5070501@oracle.com> It is not the same test indeed. I forced Look and Feel to be Metal even on MacOS and made Swing methods run on Event Dispatching Thread. On 22-Nov-12 17:48, Anthony Petrov wrote: > Looks good given it's the same test from closed repos. > > -- > best regards, > Anthony > > On 11/22/12 15:32, Konstantin Shefov wrote: >> Could you please look at this test fix? >> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >> >> On 16-Nov-12 17:27, Alexander Scherbatiy wrote: >>> >>> The fix looks good for me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 11/14/2012 7:39 PM, Konstantin Shefov wrote: >>>> Could you please look at this test fix? >>>> >>>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>>> >>>> It was test for Metal LaF, so I forced LaF to be Metal even on MacOS. >>>> Now the test passes on MacOSX. >>>> I also made Swing methods run on EDT. >>>> Test can be moved to OpenJDK as it is already in OpenJDK 6. >>>> >>>> Thanks, >>>> Konstantin >>> From anthony.petrov at oracle.com Thu Nov 22 14:04:07 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 22 Nov 2012 18:04:07 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50AE2DFA.5070501@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A3BB2C.3000409@oracle.com> <50A63F4F.7080002@oracle.com> <50AE0D57.5000906@oracle.com> <50AE2D30.90907@oracle.com> <50AE2DFA.5070501@oracle.com> Message-ID: <50AE30D7.4000803@oracle.com> I see. I suggest to request reviews from Swing engineers for Swing tests in this case. E.g. Alexander Scherbatiy could review it better than I. -- best regards, Anthony On 11/22/12 17:51, Konstantin Shefov wrote: > It is not the same test indeed. > I forced Look and Feel to be Metal even on MacOS and made Swing methods > run on Event Dispatching Thread. > > On 22-Nov-12 17:48, Anthony Petrov wrote: >> Looks good given it's the same test from closed repos. >> >> -- >> best regards, >> Anthony >> >> On 11/22/12 15:32, Konstantin Shefov wrote: >>> Could you please look at this test fix? >>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>> >>> On 16-Nov-12 17:27, Alexander Scherbatiy wrote: >>>> >>>> The fix looks good for me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 11/14/2012 7:39 PM, Konstantin Shefov wrote: >>>>> Could you please look at this test fix? >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>>>> >>>>> It was test for Metal LaF, so I forced LaF to be Metal even on MacOS. >>>>> Now the test passes on MacOSX. >>>>> I also made Swing methods run on EDT. >>>>> Test can be moved to OpenJDK as it is already in OpenJDK 6. >>>>> >>>>> Thanks, >>>>> Konstantin >>>> From konstantin.shefov at oracle.com Thu Nov 22 14:05:01 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 22 Nov 2012 18:05:01 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50AE30D7.4000803@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A3BB2C.3000409@oracle.com> <50A63F4F.7080002@oracle.com> <50AE0D57.5000906@oracle.com> <50AE2D30.90907@oracle.com> <50AE2DFA.5070501@oracle.com> <50AE30D7.4000803@oracle.com> Message-ID: <50AE310D.10004@oracle.com> He has already, but as I know, i should have 2 approvals On 22-Nov-12 18:04, Anthony Petrov wrote: > I see. I suggest to request reviews from Swing engineers for Swing > tests in this case. E.g. Alexander Scherbatiy could review it better > than I. > > -- > best regards, > Anthony > > On 11/22/12 17:51, Konstantin Shefov wrote: >> It is not the same test indeed. >> I forced Look and Feel to be Metal even on MacOS and made Swing methods >> run on Event Dispatching Thread. >> >> On 22-Nov-12 17:48, Anthony Petrov wrote: >>> Looks good given it's the same test from closed repos. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 11/22/12 15:32, Konstantin Shefov wrote: >>>> Could you please look at this test fix? >>>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>>> >>>> On 16-Nov-12 17:27, Alexander Scherbatiy wrote: >>>>> >>>>> The fix looks good for me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 11/14/2012 7:39 PM, Konstantin Shefov wrote: >>>>>> Could you please look at this test fix? >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>>>>> >>>>>> It was test for Metal LaF, so I forced LaF to be Metal even on >>>>>> MacOS. >>>>>> Now the test passes on MacOSX. >>>>>> I also made Swing methods run on EDT. >>>>>> Test can be moved to OpenJDK as it is already in OpenJDK 6. >>>>>> >>>>>> Thanks, >>>>>> Konstantin >>>>> From jaroslav.tulach at oracle.com Thu Nov 22 14:45:20 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 22 Nov 2012 15:45:20 +0100 Subject: Review request for 8003830: NPE at BasicTreeUI$Actions.page:4470 Message-ID: <4204137.uMKAJHeSPn@logoutik> Hello. Please review my fix for the following issue 8003830: NPE at BasicTreeUI$Actions.page:4470 To be available at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003830 The webrev has been exposed by Alexander at: http://cr.openjdk.java.net/~alexsch/jaroslav-tulach/8003830/webrev.00/ Fix for bug #222081 reported to NetBeans - the page action should be ready for null return value from getPathBounds Thanks for considering to accept my change. -jt From alexandr.scherbatiy at oracle.com Thu Nov 22 15:15:04 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 22 Nov 2012 19:15:04 +0400 Subject: Review request for 8003830: NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <4204137.uMKAJHeSPn@logoutik> References: <4204137.uMKAJHeSPn@logoutik> Message-ID: <50AE4178.7090107@oracle.com> The fix looks good for me. Thanks, Alexandr. On 11/22/2012 6:45 PM, Jaroslav Tulach wrote: > Hello. > > Please review my fix for the following issue > 8003830: NPE at BasicTreeUI$Actions.page:4470 > To be available at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003830 > > The webrev has been exposed by Alexander at: > http://cr.openjdk.java.net/~alexsch/jaroslav-tulach/8003830/webrev.00/ > > Fix for bug #222081 reported to NetBeans - the page action should be ready for > null return value from getPathBounds > > Thanks for considering to accept my change. > -jt > From alexandr.scherbatiy at oracle.com Thu Nov 22 15:28:41 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 22 Nov 2012 19:28:41 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50A4BD85.5020103@oracle.com> References: <50927965.3030402@oracle.com> <50991E10.5090202@oracle.com> <50A0FA4B.9010402@oracle.com> <50A3E38E.8050806@oracle.com> <50A4BD85.5020103@oracle.com> Message-ID: <50AE44A9.4000802@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8001423/webrev.02/ - The isAttributeSetEqual method that compares two attribute sets is added to the SwingUtilities2 class - The isDefined() method is used to know that an attribute is local - The attributes from the sets are compated with the equals method. That leads that parents are also compared by the equals method. The same was before the fix. - All asymmetrically redefined equals and isEqual methods now call SwingUtilities2.isAttributeSetEqual() method. Thanks, Alexandr. On 11/15/2012 2:01 PM, Alexander Scherbatiy wrote: > On 11/14/2012 10:31 PM, Denis S. Fokin wrote: >> Hi Alexander, >> >> my thoughts are below >> >> 1. I see the next scenario >> >> // 'this' contains 3 attributes >> // 'attr' does not contain attributes > > In this scenario the code below is unreachable because of the > previous check: > > if (getAttributeCount() != attr.getAttributeCount()) { > return false; > } > >> 925 boolean result = true; >> 926 >> 927 Enumeration names = attr.getAttributeNames(); >> >> // 'names' is an empty enumeration >> // by this reason we do not get into the loop >> >> 928 while (result && names.hasMoreElements()) { >> 929 Object name = names.nextElement(); >> 930 result = >> attr.getAttribute(name).equals(getLocalAttribute(name)); >> 931 } >> >> // three attributes is not the same as no attributes >> // but we have not changed the default value of the >> // result variable, so return true. >> >> 932 >> 933 return result; >> >> 2. You have removed the next code form the SimpleAttributeSet.java file >> >> 305 if (this == obj) { >> 306 return true; >> 307 } >> >> I suggest the next checks in the beginning of each equals method > I have removed this check because the equals method calls > isEqual() method that has this check. > Using this check in both methods equals and isEqual is code > duplication. > >> >> a.) return false if the parameter is null > According to the implementation before the fix it should throw > NPE. This is a correct behavior. I do not think that it should be > changed. >> b.) return false if a class of the parameter differs from expected >> one (in general case is not an instance of AttributeSet) > Yes. This check is always implemented in the equals method. >> c.) return true if the objects are equal by reference > This is implemented in all overridden equals and isEqual method > (directly or from the isEqual call from equals). >> >> 4. >> >> By contrast with StyleContext.SmallAttributeSet.equals() we do not >> change anything in StyleContext.NamedStyle.equals() >> >> StyleContext.java >> 1431 /** >> 1432 * Checks whether two attribute sets are equal. >> 1433 * >> 1434 * @param attr the attribute set to check against >> 1435 * @return true if the same >> 1436 * @see AttributeSet#isEqual >> 1437 */ >> 1438 public boolean isEqual(AttributeSet attr) { >> 1439 return attributes.isEqual(attr); >> 1440 } > > It was decided by design that these classes should be compared > only by reference (so the equals method is not overridden). We do not > change this behavior in the current fix. > The current fix only makes 'equals' and 'isEqual' method > symmetrically for those cases there they were not symmetrically. > >> >> 5. >> In you current implementation we have a code duplication. This code >> is common for StyleContext.SmallAttributeSet, SimpleAttributeSet, >> MuxingAttributeSet (and may be for future NamedStyle). >> >> 921 if (getAttributeCount() != attr.getAttributeCount()) { >> 922 return false; >> 923 } >> 924 >> 925 boolean result = true; >> 926 >> 927 Enumeration names = attr.getAttributeNames(); >> 928 while (result && names.hasMoreElements()) { >> 929 Object name = names.nextElement(); >> 930 result = >> attr.getAttribute(name).equals(getLocalAttribute(name)); >> 931 } >> 932 >> 933 return result; >> >> May be we should somehow reuse our code here? > There is no a code duplication because every time we check local > attributes from the given set with the local attributes from the > current set. > Getting local attributes from the current set depends on the set > class implementation. For example, the SimpleAttributeSet contains > it's attributes in table and the SmallAttributeSet in an array. > > So the only code duplication can be checking attribute counts. It > will be new public API that should be processed from the CCC request. > Is it really necessary? > >> >> 6. >> >> In the next places we have different approaches for the comparison of >> attributes. >> >> - comparation of local attributes (StyleContext) >> - comparation of local attributes 'Approach #2' (MuxingAttributeSet) >> - comparation of attributes >> >> Is it intentional or it should be implemented the same way? > > All these cases compares only local attributes. > The last case gets attributes from the table. The table contains > only local attributes. > > Thanks, > Alexandr. > >> >> StyleContext.java >> >> 920 private boolean isAttributeSetEqual(AttributeSet attr) { >> 921 if (getAttributeCount() != attr.getAttributeCount()) { >> 922 return false; >> 923 } >> 924 >> 925 boolean result = true; >> 926 >> 927 Enumeration names = attr.getAttributeNames(); >> 928 while (result && names.hasMoreElements()) { >> 929 Object name = names.nextElement(); >> 930 result = >> attr.getAttribute(name).equals(getLocalAttribute(name)); >> 931 } >> 932 >> 933 return result; >> 934 } >> >> 795 Object getLocalAttribute(Object nm) { >> 796 if (nm == StyleConstants.ResolveAttribute) { >> 797 return resolveParent; >> 798 } >> 799 Object[] tbl = attributes; >> 800 for (int i = 0; i < tbl.length; i += 2) { >> 801 if (nm.equals(tbl[i])) { >> 802 return tbl[i+1]; >> 803 } >> 804 } >> 805 return null; >> 806 } >> >> >> MuxingAttributeSet.java >> >> 167 public boolean isEqual(AttributeSet attr) { >> 168 if (this == attr) { >> 169 return true; >> 170 } >> 171 >> 172 if (getAttributeCount() != attr.getAttributeCount()) { >> 173 return false; >> 174 } >> 175 >> 176 boolean result = true; >> 177 >> 178 Enumeration names = attr.getAttributeNames(); >> 179 while (result && names.hasMoreElements()) { >> 180 Object name = names.nextElement(); >> 181 Object localAttribute = getLocalAttribute(name); >> 182 result = localAttribute != null && >> attr.getAttribute(name).equals(localAttribute); >> 183 } >> 184 >> 185 return result; >> 186 } >> >> >> >> 188 private Object getLocalAttribute(Object name) { >> 189 for (AttributeSet as : getAttributes()) { >> 190 Enumeration names = as.getAttributeNames(); >> 191 while (names.hasMoreElements()) { >> 192 Object attributeName = names.nextElement(); >> 193 if (attributeName.equals(name)) { >> 194 return as.getAttribute(name); >> 195 } >> 196 } >> 197 } >> 198 return null; >> 199 } >> >> SimpleAttributeSet.java >> >> 115 public boolean isEqual(AttributeSet attr) { >> 116 if (this == attr) { >> 117 return true; >> 118 } >> 119 >> 120 if (getAttributeCount() != attr.getAttributeCount()) { >> 121 return false; >> 122 } >> 123 >> 124 boolean result = true; >> 125 >> 126 Enumeration names = attr.getAttributeNames(); >> 127 while (result && names.hasMoreElements()) { >> 128 Object name = names.nextElement(); >> 129 result = >> attr.getAttribute(name).equals(table.get(name)); >> 130 } >> 131 >> 132 return result; >> 133 } >> >> Thank you, >> Denis. >> >> On 11/12/2012 5:31 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8001423/webrev.01/ >>> >>> See my comments below: >>> >>> On 11/6/2012 6:26 PM, Denis S. Fokin wrote: >>>> Hi Alexander, >>>> >>>> I found several places that could be improved, in my opinion. >>>> >>>> SimpleAttributeSet.java >>>> 120 boolean result = true; >>>> >>>> I would not assign 'true' as a default value. If the 'names' >>>> enumeration does not have any elements, we return true even not trying >>>> to compare anything. >>> We always check before that both attribute sets have the same count. So >>> if the second attribute set is empty that means that the first set also >>> empty. >>> >>>> >>>> // Does not have elements, so returns true. >>>> 123 while (result && names.hasMoreElements()) { >>> That is ok. Comparing two empty attribute sets should return true >>> because they are equal to each other. >>>> >>>> >>>> MuxingAttributeSet.java >>>> 130 for (int i = 0; i < as.length; i++) { >>>> Why we do not use foreach loop here? >>> Fixed. >>>> >>>> >>>> AbstractDocument.java >>>> 1874 && !(obj instanceof AbstractElement)) { >>>> I am not an expert in Swing, so this check is not quite clear to me. >>>> Why we check AbstractDocument.AbstractElement and do not check, for >>>> instance, SimpleAttributeSet? Is it only because of "the old >>>> AbstractElement behaviour"? >>> There is a theory how to implement equals/hashCode methods correctly in >>> Java. >>> For example, If there is a class Point{ double x; double y; } the >>> equals >>> method can be: >>> -------------------------------------------- >>> public boolean equals(Object obj) { >>> if (obj instanceof Point) { >>> Point point = (Point) obj; >>> return x == point.x && y == point.y; >>> } >>> return false; >>> } >>> -------------------------------------------- >>> >>> And there is a child class >>> -------------------------------------------- >>> class ColorPoint extends Point{ >>> Color color; >>> } >>> -------------------------------------------- >>> >>> Point point = new Point(3,4); >>> ColorPoint c = new ColorPoint(3, 4, Color.GREEN); >>> ColorPoint bluePoint = new ColorPoint(3, 4, Color.BLUE); >>> >>> What we want that the greenPoint was different from the bluePoint. >>> And we know that the check point.equals(greenPoint) returns true >>> because >>> Point 'equals' method checks only coordinates. >>> >>> So the ColorPoint equals method could look like: >>> ----------------------------------------------- >>> public boolean equals(Object obj) { >>> if (obj instanceof ColorPoint) { >>> return (((ColorPoint) obj).color == this.color) && super.equals(obj); >>> } else if (obj instanceof Point) { >>> return super.equals(obj); >>> } >>> return false; >>> } >>> ----------------------------------------------- >>> The idea is that a child class should add an additional check for >>> objects that have the same instance. >>> >>> The check 'if ((obj instanceof AttributeSet) && !(obj instanceof >>> AbstractElement))' in the AbstractDocument has been added for the same >>> reason. >>> If an object is an instance of AbstractDocument we return just (this == >>> obj) in other case if the object is and instance of AttributeSet we >>> return isEqual((AttributeSet) obj). >>> >>> The theory also says that it is better to add 'isEqual' rather to >>> override the 'equals' method because in the second case >>> the hashCode method should be overriden accordingly and for mutable >>> object it could have troubles. >>> >>> >>> I decided to changed the fix to: >>> - make the equals and isEqual method symmetrically >>> - updated the hashCode method only if they were implemented >>> >>> And leave all others as is to not break the backward compatibility. >>> >>>> By the way, I would say that we should check for equality by reference >>>> in the first place to get rid of comparing attributes if we call >>>> equals method for the same object. >>> >>> Fixed. >>> >>> Thanks, >>> Alexandr. >>>> >>>> Thank you, >>>> Denis. >>>> >>>> >>>> On 11/1/2012 5:30 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001423 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8001423/webrev.00 >>>>> >>>>> The 'equals' method from the SmallAttributeSet class compares local >>>>> attributes from the current set with all attributes (local and >>>>> parent) >>>>> from the second set if local counts are equal. >>>>> So if we check the following text attributes: >>>>> attr1: [ elem1 = value1] // getAttributeCount = 1 >>>>> attr2: [ Parent = [ elem1 = value1] ] // getAttributeCount = 1 >>>>> >>>>> The results are: >>>>> attr1.equals(attr2) = false // attr1 does not contain element with >>>>> name >>>>> Parent >>>>> attr2.equals(attr1) = true // attr2 has element elem1 in the >>>>> parent set >>>>> >>>>> All other classes that implement AttributeSet interface has the same >>>>> problems with the hashcode/equals contract. >>>>> >>>>> The fix compares all local attributes from one set with all local >>>>> attributes from the another set in the equals method. >>>>> If both sets have parents, they will be compared automatically (in >>>>> the >>>>> same way as it was before). >>>>> >>>>> >>>>> SimpleAttributeSet: Hashtable returns hashcode based on both keys and >>>>> values. The fix redefines it to return a hash code only for values. >>>>> MuxingAttributeSet: There is no direct way to get all local >>>>> attributes. >>>>> The getLocalAttribute method returns a value only if name is local. >>>>> AbstractElement: If both attribute sets are AbstractElement they are >>>>> compared by reference. In other case they are compared by checking >>>>> local >>>>> attributes. This preserves the old AbstractElement behaviour. >>>>> >>>>> The javax/swing/text/AttributeSet/8001423/bug8001423.java test is >>>>> added. >>>>> >>>>> I run the javax/swing/text tests and there is no new failures >>>>> after the >>>>> fix. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Nov 26 09:08:49 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 26 Nov 2012 13:08:49 +0400 Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <59CA7531B79CD24C9220F8C952EF389E13DFB9F1@EXCH2010.ce.local> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> <4054906.gg3VXlsrro@logoutik> <59CA7531B79CD24C9220F8C952EF389E13DFB9F1@EXCH2010.ce.local> Message-ID: <50B331A1.2040708@oracle.com> On 11/16/2012 7:17 PM, Walter Laan wrote: > For what it's worth, I've reports of a similar exceptions (in 7u7), but it happens during an automated GUI test (with QFTest) which generates the mouse events and I've not been able to reproduce it in a manual test case. > > However, since the javadoc for BasicTreeUI#getPathBounds says it can return null, the result should be checked for null where ever it is called. There are several places where this does not happen yet after the fix for 6505523. > > java.lang.NullPointerException > at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(Unknown Source) // I assume this is at line 3573 in 7u7 > at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleasedDND(Unknown Source) > at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleased(Unknown Source) > at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source) There is the open issue 6671481 : NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6671481 I do not know steps to reproduce the issue, but the fixed issue 6505523 can shed light on this mysterious NPE. It is reproduced when drag is enabled and a node is removed by an expansion listener. The pressed path is stored in the BasicTreeUI during mouse pressed event. Then the expansion listener removes the path and the mouse released event checks the stored path by the getPathBounds() method and gets null (the path has been already removed). I think that other NPEs where getPathBounds() method returns null can have similar scenarios. I will fix the issue 6671481 and the similar cases. Thanks, Alexandr. > Regards, > Walter Laan > > -----Original Message----- > From: swing-dev-bounces at openjdk.java.net [mailto:swing-dev-bounces at openjdk.java.net] On Behalf Of Jaroslav Tulach > Sent: vrijdag 16 november 2012 15:29 > To: Alexander Scherbatiy > Cc: swing-dev at openjdk.java.net > Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 > > Hello Alexander, > if you scroll down the page with the report > http://statistics.netbeans.org/exceptions/exception.do?id=628832 > you'll see list of user actions. Click on individual ones to get more info. > > One of the last actions is > > 5:34 PM Select in Projects > > it was invoked via keyboard shortcut (Ctrl-Shift-1). Looking at the XML file I found out that the actual time was 17:34:23. Then the user switched back to editor (again via shortcut this time Ctrl-Shift-0) about 1.5s later at > 17:34:24: > > 5:34 PM Editor > > A two seconds later (at 17:34:26) the NPE from JTree appeared: > > java.lang.NullPointerException > at javax.swing.plaf.basic.BasicTreeUI$Actions.page(rt.jar:4470) > at javax.swing.plaf.basic.BasicTreeUI$Actions.actionPerformed(rt.jar:4046) > at javax.swing.SwingUtilities.notifyAction(rt.jar:1664) > > We don't have logs about what the user did inside of the "Projects" component with JTree, but there seems to be no radical tree structure changes (no creation or deletion of files). > > The fact that the NPE happens more than a second after the user leaves the JTree hosting component is surprising. But maybe the JTree was not visible anymore - many users (including me) have the IDE configured to hide the "Projects tab" as soon as we switch to editor... > > I am not sure what to conclude from these observation, however. > -jt > > Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): >> On 11/16/2012 4:10 PM, Jaroslav Tulach wrote: >>> Hello Alexander, >>> thanks for your reply. The source code for NetBeans TreeView >>> component is available here: >>> http://hg.netbeans.org/main- >>> golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/v >>> iew/Tr eeView.java I'll be glad for any review, however I am also >>> positively pleased by your >>> answer: >> Is it possible to know from the filled NB issues which NB >> module/component has been used when the NPE occures? >> Or could you point any NB panel where the TreeView is used. >> >>>> The ui.getPathBounds(tree, newPath) method definitely can >>>> return >>>> >>>> null so it needs to have this check. >>> Should I start working on a webrev, so (in case you don't find any >>> violation of good Swing practices in TreeView) we can eliminate this >>> NPE once and forever? >> Yes, please. >> >>> What should be part of such webrev? Just the NPE check? Or do you >>> want some test, change in documentation, etc.? >> The fix should check the NPE and may be do some possible default >> actions in this case. >> It is a good idea to add an automated test but it can be possible >> if there are known steps which reproduce the issue. >> At least you can run the test/javax/swing/JTree automated test >> to check possible regressions. >> >> Thanks, >> Alexandr. >> >>> Thanks again for your comments. >>> -jt >>> >>> Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): >>>> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: >>>>> Dear Swing maintainers, >>>>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer >>>>> - a component that is using JTree heavily. >>>>> >>>>>> From time to time I receive a user report with a NPE from Swing >>>>>> where >>>>>> >>>>>> little> >>>>> or even no NetBeans code involved. Just today I got >>>>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 >>>>> We have about 35 other ones (which is not that much given the fact >>>>> we have million of users), but still... >>>>> >>>>> According to >>>>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 >>>>> the report comes from jdk7u9-b05. The source code is here >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- >>>>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java >>>>> and thus it looks like the call on line 4468 to >>>>> >>>>> ui.getPathBounds(tree, newPath); >>>>> >>>>> can return null (under some rare and unknown circumstances). >>>>> >>>>> I can close the bug #222081 as "worksforme", but it is clear that >>>>> such error happens from time to time and we don't want our users >>>>> to face errors. A simple: >>>>> >>>>> 4469 if (newRect == null) return; >>>>> >>>>> would do the trick. One question remains: if I try to donate such >>>>> patch, will you accept it? >>>>> >>>> The ui.getPathBounds(tree, newPath) method definitely can >>>> return >>>> >>>> null so it needs to have this check. >>>> >>>> However, such fix can mask the real issue, for example, in >>>> the >>>> >>>> treeState.getBounds() method where the treeState can be instance >>>> of FixedHeightLayoutCache or VariableHeightLayoutCache class. >>>> >>>> If it is possible, could you send a code snippet that shows >>>> how >>>> >>>> NetBeans uses JTree? May be it can give a hint what can be wrong in >>>> this case. >>>> >>>> Thanks, >>>> Alexandr. >>>>> -jt From WLaan at costengineering.eu Mon Nov 26 09:42:57 2012 From: WLaan at costengineering.eu (Walter Laan) Date: Mon, 26 Nov 2012 09:42:57 +0000 Subject: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <50B331A1.2040708@oracle.com> References: <6868828.OWPBIWenVZ@logoutik> <8154791.4EKInKHKfR@logoutik> <50A6470D.7000805@oracle.com> <4054906.gg3VXlsrro@logoutik> <59CA7531B79CD24C9220F8C952EF389E13DFB9F1@EXCH2010.ce.local> <50B331A1.2040708@oracle.com> Message-ID: <59CA7531B79CD24C9220F8C952EF389E13DFC770@EXCH2010.ce.local> FYI, in my QFTest case I tracked it down to the Jide docking framework (the DefaultDockingManager in the log) incorrectly re-ordering the MouseEvents so the released event comes before the pressed event in the JTree. [16.094] DefaultDockingManager$51.eventDispatched() - GlobalDockingManagerEventHandler: detected event:MouseEvent[MOUSE_PRESSED] [16.094] DefaultDockingManager.handleEvent() - about to process MouseEvent[MOUSE_PRESSED] [16.094] DefaultDockingManager.handleEvent() - component to process com.ces.core.gui.windows.DockableWindowPanel$1[key=DatabaseExplorer] [16.094] DefaultDockingManager.handleEvent() - queuing 1 until focusgained :MouseEvent[MOUSE_PRESSED] [16.094] DefaultDockingManager$51.eventDispatched() - consuming event:MouseEvent[MOUSE_PRESSED] [16.094] DefaultDockingManager$51.eventDispatched() - detected event:MouseEvent[MOUSE_RELEASED] [16.094] DefaultDockingManager.handleEvent() - about to process MouseEvent[MOUSE_RELEASED] [16.094] DatabaseExplorerTree.processMouseEvent() - tree:15419438:1353420136084:MouseEvent[MOUSE_RELEASED] Exception in thread "AWT-EventQueue-1" java.lang.NullPointerException at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(Unknown Source) at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleasedDND(Unknown Source) at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleased(Unknown Source) [16.094] DefaultDockingManager$51.eventDispatched() - detected event:MouseEvent[MOUSE_CLICKED] [16.094] DefaultDockingManager.handleEvent() - about to process MouseEvent[MOUSE_CLICKED] [16.094] DefaultDockingManager.handleEvent() - component to process com.ces.core.gui.windows.DockableWindowPanel$1[key=DatabaseExplorer] [16.094] DefaultDockingManager.handleEvent() - queuing 1 until focusgained :MouseEvent[MOUSE_CLICKED] [16.094] DefaultDockingManager$51.eventDispatched() - consuming event:MouseEvent[MOUSE_CLICKED] [16.114] DefaultDockingManager$51.eventDispatched() - detected event:java.awt.FocusEvent[FOCUS_GAINED] on com.ces.core.datamanager.DatabaseExplorerTree [16.134] WindowController.setActiveView() - Active changed from null to DataExplorerWindowPanel [16.144] DefaultDockingManager.handleEvent() - dequeuing 1 mouseevents for com.ces.core.gui.windows.DockableWindowPanel$1[key=DatabaseExplorer] [16.144] DefaultDockingManager$51.eventDispatched() - detected event:MouseEvent[MOUSE_PRESSED] [16.144] DefaultDockingManager.handleEvent() - about to process MouseEvent[MOUSE_PRESSED] [16.144] DefaultDockingManager.handleEvent() - component to process com.ces.core.gui.windows.DockableWindowPanel$1[key=DatabaseExplorer] [16.144] DatabaseExplorerTree.processMouseEvent() - tree:14861865:1353420136084:MouseEvent[MOUSE_PRESSED] [16.144] DatabaseExplorerTree.processMouseEvent() - tree:14861865:1353420136084:processed. [16.144] DefaultDockingManager$51.eventDispatched() - detected event:MouseEvent[MOUSE_CLICKED] [16.144] DefaultDockingManager.handleEvent() - about to process MouseEvent[MOUSE_CLICKED] [16.144] DefaultDockingManager.handleEvent() - component to process com.ces.core.gui.windows.DockableWindowPanel$1[key=DatabaseExplorer] [16.144] DatabaseExplorerTree.processMouseEvent() - tree:29414366:1353420136084:MouseEvent[MOUSE_CLICKED] [16.144] DatabaseExplorerTree.processMouseEvent() - tree:29414366:1353420136084:processed. Perhaps Netbeans does something similar? HTH, Walter. -----Original Message----- From: Alexander Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] Sent: maandag 26 november 2012 10:09 To: Walter Laan; Jaroslav Tulach Cc: swing-dev at openjdk.java.net Subject: Re: What was the user doing was: Patch for NPE at BasicTreeUI$Actions.page:4470 On 11/16/2012 7:17 PM, Walter Laan wrote: > For what it's worth, I've reports of a similar exceptions (in 7u7), but it happens during an automated GUI test (with QFTest) which generates the mouse events and I've not been able to reproduce it in a manual test case. > > However, since the javadoc for BasicTreeUI#getPathBounds says it can return null, the result should be checked for null where ever it is called. There are several places where this does not happen yet after the fix for 6505523. > > java.lang.NullPointerException > at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(Unknown > Source) // I assume this is at line 3573 in 7u7 at > javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleasedDND(Unknown > Source) at > javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleased(Unknown > Source) at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source) There is the open issue 6671481 : NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6671481 I do not know steps to reproduce the issue, but the fixed issue 6505523 can shed light on this mysterious NPE. It is reproduced when drag is enabled and a node is removed by an expansion listener. The pressed path is stored in the BasicTreeUI during mouse pressed event. Then the expansion listener removes the path and the mouse released event checks the stored path by the getPathBounds() method and gets null (the path has been already removed). I think that other NPEs where getPathBounds() method returns null can have similar scenarios. I will fix the issue 6671481 and the similar cases. Thanks, Alexandr. > Regards, > Walter Laan > > -----Original Message----- > From: swing-dev-bounces at openjdk.java.net > [mailto:swing-dev-bounces at openjdk.java.net] On Behalf Of Jaroslav > Tulach > Sent: vrijdag 16 november 2012 15:29 > To: Alexander Scherbatiy > Cc: swing-dev at openjdk.java.net > Subject: What was the user doing was: Patch for NPE at > BasicTreeUI$Actions.page:4470 > > Hello Alexander, > if you scroll down the page with the report > http://statistics.netbeans.org/exceptions/exception.do?id=628832 > you'll see list of user actions. Click on individual ones to get more info. > > One of the last actions is > > 5:34 PM Select in Projects > > it was invoked via keyboard shortcut (Ctrl-Shift-1). Looking at the > XML file I found out that the actual time was 17:34:23. Then the user > switched back to editor (again via shortcut this time Ctrl-Shift-0) > about 1.5s later at > 17:34:24: > > 5:34 PM Editor > > A two seconds later (at 17:34:26) the NPE from JTree appeared: > > java.lang.NullPointerException > at javax.swing.plaf.basic.BasicTreeUI$Actions.page(rt.jar:4470) > at > javax.swing.plaf.basic.BasicTreeUI$Actions.actionPerformed(rt.jar:4046 > ) at javax.swing.SwingUtilities.notifyAction(rt.jar:1664) > > We don't have logs about what the user did inside of the "Projects" component with JTree, but there seems to be no radical tree structure changes (no creation or deletion of files). > > The fact that the NPE happens more than a second after the user leaves the JTree hosting component is surprising. But maybe the JTree was not visible anymore - many users (including me) have the IDE configured to hide the "Projects tab" as soon as we switch to editor... > > I am not sure what to conclude from these observation, however. > -jt > > Dne P? 16. listopadu 2012 18:00:45, Alexander Scherbatiy napsal(a): >> On 11/16/2012 4:10 PM, Jaroslav Tulach wrote: >>> Hello Alexander, >>> thanks for your reply. The source code for NetBeans TreeView >>> component is available here: >>> http://hg.netbeans.org/main- >>> golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/v >>> iew/Tr eeView.java I'll be glad for any review, however I am also >>> positively pleased by your >>> answer: >> Is it possible to know from the filled NB issues which NB >> module/component has been used when the NPE occures? >> Or could you point any NB panel where the TreeView is used. >> >>>> The ui.getPathBounds(tree, newPath) method definitely can >>>> return >>>> >>>> null so it needs to have this check. >>> Should I start working on a webrev, so (in case you don't find any >>> violation of good Swing practices in TreeView) we can eliminate this >>> NPE once and forever? >> Yes, please. >> >>> What should be part of such webrev? Just the NPE check? Or do you >>> want some test, change in documentation, etc.? >> The fix should check the NPE and may be do some possible >> default actions in this case. >> It is a good idea to add an automated test but it can be >> possible if there are known steps which reproduce the issue. >> At least you can run the test/javax/swing/JTree automated test >> to check possible regressions. >> >> Thanks, >> Alexandr. >> >>> Thanks again for your comments. >>> -jt >>> >>> Dne P? 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a): >>>> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote: >>>>> Dear Swing maintainers, >>>>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer >>>>> - a component that is using JTree heavily. >>>>> >>>>>> From time to time I receive a user report with a NPE from >>>>>> Swing where >>>>>> >>>>>> little> >>>>> or even no NetBeans code involved. Just today I got >>>>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081 >>>>> We have about 35 other ones (which is not that much given the fact >>>>> we have million of users), but still... >>>>> >>>>> According to >>>>> http://statistics.netbeans.org/exceptions/exception.do?id=628832 >>>>> the report comes from jdk7u9-b05. The source code is here >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9- >>>>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java >>>>> and thus it looks like the call on line 4468 to >>>>> >>>>> ui.getPathBounds(tree, newPath); >>>>> >>>>> can return null (under some rare and unknown circumstances). >>>>> >>>>> I can close the bug #222081 as "worksforme", but it is clear that >>>>> such error happens from time to time and we don't want our users >>>>> to face errors. A simple: >>>>> >>>>> 4469 if (newRect == null) return; >>>>> >>>>> would do the trick. One question remains: if I try to donate such >>>>> patch, will you accept it? >>>>> >>>> The ui.getPathBounds(tree, newPath) method definitely can >>>> return >>>> >>>> null so it needs to have this check. >>>> >>>> However, such fix can mask the real issue, for example, in >>>> the >>>> >>>> treeState.getBounds() method where the treeState can be instance >>>> of FixedHeightLayoutCache or VariableHeightLayoutCache class. >>>> >>>> If it is possible, could you send a code snippet that shows >>>> how >>>> >>>> NetBeans uses JTree? May be it can give a hint what can be wrong in >>>> this case. >>>> >>>> Thanks, >>>> Alexandr. >>>>> -jt From alexandr.scherbatiy at oracle.com Mon Nov 26 13:27:17 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 26 Nov 2012 17:27:17 +0400 Subject: [8] Review request for 6671481 NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection Message-ID: <50B36E35.9040904@oracle.com> Hello, could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6671481 webrev: http://cr.openjdk.java.net/~alexsch/6671481/webrev.00 There are no known exact steps to reproduce the issue. However, there is a possible scenario that one can check a tree path that has been already removed. The fix correctly handles the null value returned by the getPathBounds(tree, path) method in the BasicTreeUI class. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Mon Nov 26 17:28:42 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 26 Nov 2012 21:28:42 +0400 Subject: [8] Review request for 6671481 NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection In-Reply-To: <50B36E35.9040904@oracle.com> References: <50B36E35.9040904@oracle.com> Message-ID: <50B3A6CA.60808@oracle.com> Hi, Alexander. Fix looks good. 26.11.2012 17:27, Alexander Scherbatiy wrote: > Hello, > > could you review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6671481 > webrev: http://cr.openjdk.java.net/~alexsch/6671481/webrev.00 > > > There are no known exact steps to reproduce the issue. However, there > is a possible scenario that one can check a tree path that has been > already removed. > The fix correctly handles the null value returned by the > getPathBounds(tree, path) method in the BasicTreeUI class. > > > Thanks, > Alexandr. > -- Best regards, Sergey. From dingxmin at linux.vnet.ibm.com Wed Nov 28 06:29:11 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 28 Nov 2012 14:29:11 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50A4B369.3030009@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com> <5029C0A0.2030903@linux.vnet.ibm.com> <502BCC13.4000808@oracle.com> <5051488F.3000004@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com> <5056C45B.9030905@linux.vnet.ibm.com> <506ED516.5020706@oracle.com> <50727AFF.3060004@linux.vnet.ibm.com> <507440C4.9060504@oracle.com> <50751427.4040706@linux.vnet.ibm.com> <50778B0F.6040407@linux.vnet.ibm.com> <507BD467.2000405@oracle.com> <507E4752.3040302@linux.vnet.ibm.com> <508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com> <5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com> <509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com> <509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com> <50A1FC8F.7060107@linux.vnet.ibm.com> <50A233B2.5020602@oracle.com> <50A338B5.7070302@linux.vnet.ibm.com> <50A4B369.3030009@oracle.com> Message-ID: <50B5AF37.3070307@linux.vnet.ibm.com> Hi Alexandr, I created a new patch v8 @ http://cr.openjdk.java.net/~dingxmin/7189299/webrev.08/. It uses the newly proposed approach mentioned in my last email. Could you please help to review it again? The patch, of course, passed jtreg test bug7189299.java in the patch. What's more, I did additional tests for JComboBox, JTextField and JList in my IDE by comparing listener numbers observed during debugging with/without my patch. The listener numbers were doubled without the fix. This proves that v8 patch works for all components. I think I can write those additional tests as jtreg tests after the patch passes review. One notable change is that I had to restrict the scope of holding a write lock in DefaultStyledDocument because otherwise, we cannot store the new component created in FormView.createComponent(). The stack trace is pasted below for reference. Exception in thread "main" java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:1270) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) at bug7189299.main(bug7189299.java:116) Caused by: java.lang.IllegalStateException: Attempt to mutate in notification at javax.swing.text.AbstractDocument.writeLock(AbstractDocument.java:1357) at javax.swing.text.html.HTMLDocument.obtainLock(HTMLDocument.java:1708) at javax.swing.text.html.FormView.createComponent(FormView.java:211) ......(omitted)...... at javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1602) at javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1861) at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201) at javax.swing.text.DefaultStyledDocument.create(DefaultStyledDocument.java:155) <------ FormView.createComponent is triggered by this call which has already held the lock at javax.swing.text.html.HTMLDocument.create(HTMLDocument.java:469) ......(omitted)...... This change did violate what is documented in AbstractDocument.writeLock that "This situation violates the bean event model where order of delivery is not guaranteed and all listeners should be notified before further mutations are allowed. " However, without the change of shrinking lock scope, the component cannot be saved once it is created in FormView.createComponent(). I found it is even harder to save it later in code but perhaps there does exist a more appropriate place to do this. If you have any better suggestion, I am glad to know. Also I searched references to 'StyleConstants.ComponentAttribute' as you asked. The result is listed below. Note that the command 'grep' is invoked under openjdk 8 top directory. $ grep -R 'ComponentAttribute' . ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: public static final Object ComponentAttribute = new CharacterConstants("component"); ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: return (Component) a.getAttribute(ComponentAttribute); ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: a.addAttribute(ComponentAttribute, c); ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: Background, ComponentAttribute, IconAttribute, ./jdk/src/share/classes/javax/swing/text/StyledEditorKit.java: set.removeAttribute(StyleConstants.ComponentAttribute); Binary file ./jdk/test/sun/tools/jhat/jmap.bin matches So ComponentAttribute is not referenced by other classes except StyledEditorKit. StyleConstants exposes ComponentAttribute in getComponent() and setComponent() methods. References to StyleConstants.getComponent and StyleConstants.setComponent are further searched in repo. $ grep -R 'StyleConstants.getComponent' . ./jdk/src/share/classes/javax/swing/text/ComponentView.java: * the element (by calling StyleConstants.getComponent). A ./jdk/src/share/classes/javax/swing/text/ComponentView.java: Component comp = StyleConstants.getComponent(attr); $ grep -R 'StyleConstants.setComponent' . ./jdk/src/share/classes/javax/swing/JTextPane.java: StyleConstants.setComponent(inputAttributes, c); From the facts above, I think we are sufficiently confident to use ComponentAttribute. Please let me know if you have any comments and I can do more regression tests and provide more jtreg test cases as next step. Thanks and regards, Frank On 11/15/2012 5:18 PM, Alexander Scherbatiy wrote: > On 11/14/2012 10:22 AM, Frank Ding wrote: >> Hi Alexandr, >> After a couple of hours investigating the possibility of fixing >> JComboBox.setModel(null) and JTextComponent.setComponent(null), I >> found that >> 1. In JComboBox.setModel, the new model, null in this case, is >> eventually passed to BasicComboPopup.propertyChange where >> JList.setModel is called. JList.setModel rejects the null model >> because of its api restriction. Below I listed the offending call >> stacks in my IDE. This makes sense as the associated drop down JList >> needs new model. However, it makes fixing JComboBox.setModel(null) >> hard or impossible. >> Exception in thread "main" java.lang.IllegalArgumentException: model >> must be non null >> at javax.swing.JList.setModel(JList.java:1674) >> at >> javax.swing.plaf.basic.BasicComboPopup$Handler.propertyChange(BasicComboPopup.java:939) >> at >> java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) >> at >> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327) >> at >> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263) >> at java.awt.Component.firePropertyChange(Component.java:8413) >> at javax.swing.JComboBox.setModel(JComboBox.java:322) >> >> 2. JTextComponent.setComponent(null) can be fixed but code change in >> BasicTextUI is also required. >> >> Since setting null model to JComboBox, JList and JTextComponent is >> impossible or dangerous, just as you mentioned, we could set a non >> null new model to these UI components just for the purpose of having >> the side effect of removing listeners from old model. Are you ok with >> this approach? > Yes. Please, try this and run the html swing automated tests > from the test/javax/swing/text/html diroctory to check possible > regressions. > > Thanks, > Alexandr. > >> By the way, I will investigate your another question "Could you also >> check that the StyleConstants.ComponentAttribute property value can't >> be rewritten by the JDK code or by public methods." and reply soon. >> >> Best regards, >> Frank >> >> On 11/13/2012 7:49 PM, Alexander Scherbatiy wrote: >>> On 11/13/2012 11:53 AM, Frank Ding wrote: >>>> Hi Alexandr, >>>> As for your comment "Could you create an issue that a >>>> JComboBox.setModel(null) call throws NPE? You could fix it before >>>> the 7189299 issue. ", I created a bug with internal review ID of >>>> 2381499 on JComboBox.setModel(null). But test shows that >>>> JPasswordField.setDocument(null), JTextField.setDocument(null), >>>> JList.setModel(null) and JTextArea.setDocument(null) all throw >>>> NPE. Particularly, JList.setModel(null) has null check and throws >>>> IllegalArgumentException("model" must be non null"). Shall I >>>> include those components as well? >>> >>> There is the javadoc for the JList setModel() method: Throws >>> IllegalArgumentException - if model is null. So it is undesirable >>> to change the public API. >>> However, it is possible to set a new empty model for the JList. >>> The list listeners should be removed from the old model in this case. >>> >>> You could have only 2 issues: one for components that allow to >>> set a null model but throws NPE (like JComboBox) and another for >>> components that does not allow to set null model but they do not >>> remove listeners from the old model in case if a new model is set. >>> >>> Thanks, >>> Alexandr. >>> >>>> Thanks for your guidance in advance. >>>> >>>> Best regards, >>>> Frank >>>> >>>> On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote: >>>>> On 11/7/2012 10:56 AM, Frank Ding wrote: >>>>>> Hi Alexandr, >>>>>> Unfortunately, all the JComponents involved in >>>>>> FormView.createComponent() have bugs! >>>>>> I have done tests for all other swing components, i.e. >>>>>> JCheckBox, JRadioButton, JPasswordField, JTextField, JList, >>>>>> JComboBox and JTextField. Sadder news is that if we fix all >>>>>> components in the same way as I did for JButton, we need to >>>>>> subclass them all, resulting in JCheckBoxWrapper, >>>>>> JRadioButtonWrapper, JPasswordFieldWrapper, JTextFieldWrapper, >>>>>> JListWrapper, JComboBoxWrapper, JTextFieldWrapper plus >>>>>> JButtonWrapper! This approach becomes unacceptable when all >>>>>> swing components are affected. >>>>>> Shall we fix it in other way illustrated below? >>>>>> 1. Whenever a swing component is created, it is kept in >>>>>> AttributeSet, as what is now for model. >>>>>> 2. In FormView.createComponent(), the old swing component can be >>>>>> retrieved via >>>>>> attr.getAttribute(StyleConstants.ComponentAttribute). Note that >>>>>> ComponentAttribute is newly added. >>>>> This way should be carefully investigated that it does not >>>>> introduce new memory leaks. >>>>> Could you also check that the >>>>> StyleConstants.ComponentAttribute property value can't be >>>>> rewritten by the JDK code or by public methods. >>>>> >>>>>> 3. Before setting shared model to a newly initialized swing >>>>>> component, call oldComp.setModel(null), delegating deregistration >>>>>> to setModel method. >>>>>> 4. Seems some setModel such as AbstractButton.setModel() can >>>>>> function well when the param, new model, is null while >>>>>> JComboBox.setModel() will throw NPE in case of null param. >>>>> Could you create an issue that a JComboBox.setModel(null) >>>>> call throws NPE? You could fix it before the 7189299 issue. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> 5. Add null check code in those problematic setModel or >>>>>> setDocument methods. >>>>>> >>>>>> Any idea is appreciated. Thanks. >>>>>> >>>>>> Best regards, >>>>>> Frank >>>>>> >>>>>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote: >>>>>>> On 11/5/2012 11:20 AM, Frank Ding wrote: >>>>>>>> Hi Alexander, >>>>>>>> Based on your comments last time, I refined my patch of v6 >>>>>>>> and offered v7 @ >>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ >>>>>>> >>>>>>> This version of the fix looks good for me. >>>>>>> It seems that it is the only good way to check that a >>>>>>> button model contains AbstarctButton.Handler listener. >>>>>>> >>>>>>> Could you also check that others models used in the >>>>>>> createComponent() method do not have such memory leaks (even the >>>>>>> NPE is not thrown)? >>>>>>> >>>>>>>> 4. Could you add the check that the action listener is >>>>>>>> invoked only once after a component tree updating and the >>>>>>>> action does the same that it does before a component tree >>>>>>>> updating? >>>>>>>> Answer: I am afraid I could not make it in the auto test >>>>>>>> (bug7189299.java) but I can achieve it to some degree in manual >>>>>>>> test FormSubmit, the one you illustrated below. >>>>>>>> My idea of checking it in FormSubmit.java is subclassing >>>>>>>> JEditorPane and overriding 'public EditorKit getEditorKit()' >>>>>>>> where stack traces can be examined in the overridden method to >>>>>>>> make sure FormView.submitData occurs only once. This approach >>>>>>>> works because FormView.submitData() calls >>>>>>>> JEditorPane.getEditorKit but is tricky. However, it's the only >>>>>>>> way I can think of without any additional framework support. >>>>>>>> If you are in favor of adding the check in FormSubmit.java, I >>>>>>>> am willing to do that. >>>>>>> >>>>>>> At least a separated manual test can be added that asks a >>>>>>> user to put a response.html file to a server and according to >>>>>>> the server url checks that JTeditor pane show the response text >>>>>>> after a button pressing. >>>>>>> >>>>>>> html = new JEditorPane("text/html", >>>>>>> "
" >>>>>>> + ">>>>>> value=\"submit\"/>" >>>>>>> + "
"); >>>>>>> >>>>>>> response.html: >>>>>>> Hello World! >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> Thanks again for all your comments and your support. Once >>>>>>>> again, if you have any further concern or comment, please don't >>>>>>>> hesitate to let me know. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Frank >>>>>>>> >> > From jviswana at linux.vnet.ibm.com Wed Nov 28 13:43:47 2012 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Wed, 28 Nov 2012 19:13:47 +0530 Subject: Review Request - Jcolorchooser Missing accessible name In-Reply-To: <50AB550D.70301@oracle.com> References: <5051A78B.7050904@linux.vnet.ibm.com> <505AD26F.40307@linux.vnet.ibm.com> <505B0AC4.5080805@oracle.com> <505BEC32.2050604@linux.vnet.ibm.com> <505C4E93.5070809@oracle.com> <50AA141A.6030009@linux.vnet.ibm.com> <50AB550D.70301@oracle.com> Message-ID: <50B61513.6080608@linux.vnet.ibm.com> On 20-11-2012 3:31 PM, Alexander Scherbatiy wrote: > On 11/19/2012 3:12 PM, jayashree viswanathan wrote: >> >> Hi Alexandr, >> >> Please find the updated CR and the results in the below link . >> >> http://cr.openjdk.java.net/~jviswana/4631925/ >> >> I have fixed all the accessible name issues reported by the a11y tool >> in this for the ColorChooser and the result post that is also >> available in the same location . > > before fix: > http://cr.openjdk.java.net/~alexsch/others/colorchooser/a11n/01/a11n_CMYK.txt > after fix: > http://cr.openjdk.java.net/~jviswana/4631925/temp/CMYK.txt > > The 'No Accessible name' list is empty now for the CMYK tab. > But the 'No Accessible description' contains lines like: Class: > javax.swing.JFormattedTextField { Alpha | } after the fix. > It seems that accessible descriptions should be also set with > accessible names. > > Thanks, > Alexandr. > > >> >> Thanks and Regards, >> Jayashree V >> > > > Hi Alexandr , Please find the updated CR and the results in the below link http://cr.openjdk.java.net/~jviswana/4631925/result.01/ http://cr.openjdk.java.net/~jviswana/4631925/webrev.02/ The No Accessible Name and No accessible Description is fixed now. I think that we can have a utility like the sample shown in http://cr.openjdk.java.net/~jviswana/4631925/result.01/AccessibilityUtils.java to have such parameters set for all the accessibility requirement as it reduces repetition across various piece of code. Please let me know your opinion . Thanks and Regards, Jayashree Viswanathan From konstantin.shefov at oracle.com Wed Nov 28 16:39:11 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 28 Nov 2012 20:39:11 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50AE30D7.4000803@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50A3BB2C.3000409@oracle.com> <50A63F4F.7080002@oracle.com> <50AE0D57.5000906@oracle.com> <50AE2D30.90907@oracle.com> <50AE2DFA.5070501@oracle.com> <50AE30D7.4000803@oracle.com> Message-ID: <50B63E2F.40307@oracle.com> Could you please look at this test fix? Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ (already approved by Alexander Scherbatiy) On 22-Nov-12 18:04, Anthony Petrov wrote: > I see. I suggest to request reviews from Swing engineers for Swing > tests in this case. E.g. Alexander Scherbatiy could review it better > than I. > > -- > best regards, > Anthony > > On 11/22/12 17:51, Konstantin Shefov wrote: >> It is not the same test indeed. >> I forced Look and Feel to be Metal even on MacOS and made Swing methods >> run on Event Dispatching Thread. >> >> On 22-Nov-12 17:48, Anthony Petrov wrote: >>> Looks good given it's the same test from closed repos. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 11/22/12 15:32, Konstantin Shefov wrote: >>>> Could you please look at this test fix? >>>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>>> >>>> On 16-Nov-12 17:27, Alexander Scherbatiy wrote: >>>>> >>>>> The fix looks good for me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 11/14/2012 7:39 PM, Konstantin Shefov wrote: >>>>>> Could you please look at this test fix? >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/7104594/webrev.01/ >>>>>> >>>>>> It was test for Metal LaF, so I forced LaF to be Metal even on >>>>>> MacOS. >>>>>> Now the test passes on MacOSX. >>>>>> I also made Swing methods run on EDT. >>>>>> Test can be moved to OpenJDK as it is already in OpenJDK 6. >>>>>> >>>>>> Thanks, >>>>>> Konstantin >>>>> From konstantin.shefov at oracle.com Wed Nov 28 16:41:23 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 28 Nov 2012 20:41:23 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <50AE2CF1.5010905@oracle.com> References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com> <509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com> <509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com> <50AE0D17.3070102@oracle.com> <50AE2CF1.5010905@oracle.com> Message-ID: <50B63EB3.6000703@oracle.com> Could you please look at this test fix? Webrev: http://cr.openjdk.java.net/~kshefov/7124209/webrev.02 (already approved by Alexander Scherbatiy) On 22-Nov-12 17:47, Anthony Petrov wrote: > I'm not a Swing expert, but since the test is simply moved from closed > repos, I guess it looks fine. > > -- > best regards, > Anthony > > On 11/22/12 15:31, Konstantin Shefov wrote: >> Please review a fix for this issue: >> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02 >> >> On 09-Nov-12 12:47, Alexander Scherbatiy wrote: >>> On 11/8/2012 4:25 PM, Konstantin Shefov wrote: >>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ >>>> >>> >>> The fix looks good for me. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 08-Nov-12 16:02, Alexander Scherbatiy wrote: >>>>> On 11/7/2012 7:00 PM, Konstantin Shefov wrote: >>>>>> Please, look at modified fix: >>>>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ >>>>>> >>>>> >>>>> Try/catch block in the main method catches RuntimeException as well. >>>>> So the jtreg passes the test even it really fails. >>>>> It is also a good idea to fail the test if the >>>>> SwingUtilities.invokeAndWait() throws an exception because it is >>>>> also a wrong situation. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> - Please, remove comments and unnecessary System.out from the fix >>>>>>> - Create and check swing components on EDT. Avoiding this rule can >>>>>>> leads to unpredictable test failures. >>>>>>> - Swing tests usually have bugBugID.java or some meaningful name. >>>>>>> - It is better to use the swing-dev at openjdk.java.net alias to >>>>>>> review the swing tests. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a fix for the issue: >>>>>>>> >>>>>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the >>>>>>>> range: [NORTH, SOUTH] >>>>>>>> >>>>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/ >>>>>>>> >>>>>>>> It is suggested to move the test to open jdk. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Konstantin >>>>>>>> >>>>>>> >>>>> >>>