From alexandr.scherbatiy at oracle.com Mon Dec 3 10:53:11 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 03 Dec 2012 14:53:11 +0400 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50B5AF37.3070307@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> <50A4B369.3030009@oracle.com> <50B5AF37.3070307@linux.vnet.ibm.com> Message-ID: <50BC8497.5030409@oracle.com> Could you check the following sample with your latest fix? It just hangs on my side. - put the sample.html and the response.html files on a server - update path to the html files in the LoadingWebPageToJEditorPane class ------------- sample.html ------------
Username:
------------- response.html ------------ Hello World! ------------- LoadingWebPageToJEditorPane.html ------------ import java.net.URL; import javax.swing.JEditorPane; import javax.swing.JFrame; import javax.swing.JScrollPane; import javax.swing.SwingUtilities; public class LoadingWebPageToJEditorPane { private static final String HTML_PATH = "http://serever/path/sample.html"; public static void main(String[] a) throws Exception { SwingUtilities.invokeAndWait(new Runnable() { @Override public void run() { try { JFrame frame = new JFrame(); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); JEditorPane editorPane = new JEditorPane(); editorPane.setPage(new URL(HTML_PATH)); frame.add(new JScrollPane(editorPane)); frame.setSize(300, 200); frame.setVisible(true); SwingUtilities.updateComponentTreeUI(editorPane); } catch (Exception ex) { throw new RuntimeException(ex); } } }); } } --------------------------------------- Thanks, Alexandr. On 11/28/2012 10:29 AM, Frank Ding wrote: > 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 alexandr.scherbatiy at oracle.com Mon Dec 3 12:51:00 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 03 Dec 2012 16:51:00 +0400 Subject: Review Request - Jcolorchooser Missing accessible name In-Reply-To: <50B61513.6080608@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> <50AB550D.70301@oracle.com> <50B61513.6080608@linux.vnet.ibm.com> Message-ID: <50BCA034.3050100@oracle.com> On 11/28/2012 5:43 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/result.01/ > http://cr.openjdk.java.net/~jviswana/4631925/webrev.02/ > > The No Accessible Name and No accessible Description is fixed now. The fix looks good for me. > > 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 . You could create a request for enhancement on it. Thanks, Alexandr. > > Thanks and Regards, > Jayashree Viswanathan > From jviswana at linux.vnet.ibm.com Mon Dec 3 15:12:35 2012 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Mon, 03 Dec 2012 20:42:35 +0530 Subject: Review Request - Jcolorchooser Missing accessible name In-Reply-To: <50BCA034.3050100@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> <50B61513.6080608@linux.vnet.ibm.com> <50BCA034.3050100@oracle.com> Message-ID: <50BCC163.6060409@linux.vnet.ibm.com> On 03-12-2012 6:21 PM, Alexander Scherbatiy wrote: > On 11/28/2012 5:43 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/result.01/ >> http://cr.openjdk.java.net/~jviswana/4631925/webrev.02/ >> >> The No Accessible Name and No accessible Description is fixed now. > > The fix looks good for me. > >> >> 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 . > > You could create a request for enhancement on it. > > Thanks, > Alexandr. > >> >> Thanks and Regards, >> Jayashree Viswanathan >> > > > Hi Alexandr, Thanks for your reply . I will create a enhancement request on it , should I write a JEP ? meanwhile do you think the jcolorchooser changes can be pushed into JDK 8 , if you think the changes looks fine for you ? Regards, Jayashree Viswanathan From Sergey.Bylokhov at oracle.com Tue Dec 4 11:33:31 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Dec 2012 15:33:31 +0400 Subject: Review request for 8003830: NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <4204137.uMKAJHeSPn@logoutik> References: <4204137.uMKAJHeSPn@logoutik> Message-ID: <50BDDF8B.80309@oracle.com> Hi, Jaroslav. Fix looks good. Thanks. 22.11.2012 18:45, 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 > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Dec 4 11:40:57 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Dec 2012 15:40:57 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50AE44A9.4000802@oracle.com> References: <50927965.3030402@oracle.com> <50991E10.5090202@oracle.com> <50A0FA4B.9010402@oracle.com> <50A3E38E.8050806@oracle.com> <50A4BD85.5020103@oracle.com> <50AE44A9.4000802@oracle.com> Message-ID: <50BDE149.2040200@oracle.com> Hi, Alexander. Looks like this code in StyleContext: 903 if (attr instanceof SmallAttributeSet) { 904 return attr == this; 905 } is unnecessary since you add the same chech in: SwingUtilities2.isAttributeSetEqual 22.11.2012 19:28, Alexander Scherbatiy wrote: > > 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. Is it possible to add some comments to the method about this? Thanks. > - 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. >>>>>> >>>>> >>>> >>>> >>> >> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Dec 4 11:45:46 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Dec 2012 15:45:46 +0400 Subject: [8] Review request for 8002077 Possible mnemonic issue on JFileChooser Save button on nimbus L&F In-Reply-To: <50A638E3.7050307@oracle.com> References: <50A638E3.7050307@oracle.com> Message-ID: <50BDE26A.1030703@oracle.com> Hi,Alexander. Fix looks fine. 16.11.2012 17:00, Alexander Scherbatiy wrote: > > 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. > > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Tue Dec 4 13:33:31 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 04 Dec 2012 17:33:31 +0400 Subject: Review Request - Jcolorchooser Missing accessible name In-Reply-To: <50BCC163.6060409@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> <50AB550D.70301@oracle.com> <50B61513.6080608@linux.vnet.ibm.com> <50BCA034.3050100@oracle.com> <50BCC163.6060409@linux.vnet.ibm.com> Message-ID: <50BDFBAB.9070505@oracle.com> On 12/3/2012 7:12 PM, jayashree viswanathan wrote: > > Hi Alexandr, > > Thanks for your reply . I will create a enhancement request on it , > should I write a JEP ? According to the JDK Enhancement-Proposal & Roadmap Process (http://openjdk.java.net/jeps/1/) --------------------------------------------------- An enhancement is an effort to design and implement a nontrivial change to the JDK code base or to do some other kind of work whose goals, progress, and result are worth communicating broadly. A JDK Enhancement Proposal (hereinafter ?JEP?) should be drafted for any work that meets at least one of the following criteria: - It requires two or more weeks of engineering effort, - It makes a significant change to the JDK, or to the processes and infrastructure by which it is developed, or - It is in high demand by developers or customers. --------------------------------------------------- Your proposed utility methods can be added to the SwingUtilities class that has already had some accessibility methods. > meanwhile do you think the jcolorchooser changes can be pushed into > JDK 8 , if you think the changes looks fine for you ? I have pushed your fix to the JDK 8: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4aad3e6f68d2 Thanks, Alexandr. > Regards, > Jayashree Viswanathan > From alexandr.scherbatiy at oracle.com Tue Dec 4 13:59:06 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 04 Dec 2012 17:59:06 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50BDE149.2040200@oracle.com> References: <50927965.3030402@oracle.com> <50991E10.5090202@oracle.com> <50A0FA4B.9010402@oracle.com> <50A3E38E.8050806@oracle.com> <50A4BD85.5020103@oracle.com> <50AE44A9.4000802@oracle.com> <50BDE149.2040200@oracle.com> Message-ID: <50BE01AA.1080903@oracle.com> On 12/4/2012 3:40 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Looks like this code in StyleContext: > > 903 if (attr instanceof SmallAttributeSet) { > 904 return attr == this; > 905 } > This check is preserved because of the backward compatibility (the fix does not change isEqual() and equals() methods logic). It says that two instances of the SmallAttributeSet class are equal only by reference, not by elements. The check from the SwingUtilities2.isAttributeSetEqual method is different and used for a performance reason (comparing a set with itself always returns true). Thanks, Alexandr. > is unnecessary since you add the same chech in: > > SwingUtilities2.isAttributeSetEqual > > 22.11.2012 19:28, Alexander Scherbatiy wrote: >> >> 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. > Is it possible to add some comments to the method about this? > Thanks. >> - 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 Sergey.Bylokhov at oracle.com Tue Dec 4 14:19:49 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Dec 2012 18:19:49 +0400 Subject: [8] Review request for 8001423 javax.swing.text.StyleContext.SmallAttributeSet breaks hashcode/equals contract In-Reply-To: <50BE01AA.1080903@oracle.com> References: <50927965.3030402@oracle.com> <50991E10.5090202@oracle.com> <50A0FA4B.9010402@oracle.com> <50A3E38E.8050806@oracle.com> <50A4BD85.5020103@oracle.com> <50AE44A9.4000802@oracle.com> <50BDE149.2040200@oracle.com> <50BE01AA.1080903@oracle.com> Message-ID: <50BE0685.5080005@oracle.com> Hi, Alexander. Thanks for clarification. I suggest check equal/isEqual contract in the separate CR? Fix looks good. 04.12.2012 17:59, Alexander Scherbatiy wrote: > On 12/4/2012 3:40 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Looks like this code in StyleContext: >> >> 903 if (attr instanceof SmallAttributeSet) { >> 904 return attr == this; >> 905 } >> > This check is preserved because of the backward compatibility (the > fix does not change isEqual() and equals() methods logic). > It says that two instances of the SmallAttributeSet class are equal > only by reference, not by elements. > > The check from the SwingUtilities2.isAttributeSetEqual method is > different and used for a performance reason (comparing a set with > itself always returns true). > > Thanks, > Alexandr. > >> is unnecessary since you add the same chech in: >> >> SwingUtilities2.isAttributeSetEqual >> >> 22.11.2012 19:28, Alexander Scherbatiy wrote: >>> >>> 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. >> Is it possible to add some comments to the method about this? >> Thanks. >>> - 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. >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > -- Best regards, Sergey. From jviswana at linux.vnet.ibm.com Tue Dec 4 14:45:59 2012 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Tue, 04 Dec 2012 20:15:59 +0530 Subject: Review Request - Jcolorchooser Missing accessible name In-Reply-To: <50BDFBAB.9070505@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> <50B61513.6080608@linux.vnet.ibm.com> <50BCA034.3050100@oracle.com> <50BCC163.6060409@linux.vnet.ibm.com> <50BDFBAB.9070505@oracle.com> Message-ID: <50BE0CA7.1010509@linux.vnet.ibm.com> On 04-12-2012 7:03 PM, Alexander Scherbatiy wrote: > On 12/3/2012 7:12 PM, jayashree viswanathan wrote: >> >> Hi Alexandr, >> >> Thanks for your reply . I will create a enhancement request on it , >> should I write a JEP ? > > According to the JDK Enhancement-Proposal & Roadmap Process > (http://openjdk.java.net/jeps/1/) > --------------------------------------------------- > An enhancement is an effort to design and implement a nontrivial > change to the JDK code base or to do some other kind of work whose > goals, progress, and result are worth communicating broadly. A JDK > Enhancement Proposal (hereinafter ?JEP?) should be drafted for any > work that meets at least one of the following criteria: > - It requires two or more weeks of engineering effort, > - It makes a significant change to the JDK, or to the processes and > infrastructure by which it is developed, or > - It is in high demand by developers or customers. > --------------------------------------------------- > > Your proposed utility methods can be added to the SwingUtilities class > that has already had some accessibility methods. > >> meanwhile do you think the jcolorchooser changes can be pushed into >> JDK 8 , if you think the changes looks fine for you ? > I have pushed your fix to the JDK 8: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4aad3e6f68d2 > > Thanks, > Alexandr. > >> Regards, >> Jayashree Viswanathan >> > > Hi Alexander , Thanks a lot for committing the changes . I will work on the utility changes and get back soon . Regards, Jayashree Viswanathan From jaroslav.tulach at oracle.com Tue Dec 4 18:53:38 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 04 Dec 2012 19:53:38 +0100 Subject: Review request for 8003830: NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <50BDDF8B.80309@oracle.com> References: <4204137.uMKAJHeSPn@logoutik> <50BDDF8B.80309@oracle.com> Message-ID: <2386262.apLmzK4PCh@logoutik> Dne ?t 4. prosince 2012 15:33:31, Sergey Bylokhov napsal(a): > Hi, Jaroslav. > Fix looks good. Thanks a log Sergey. Alexandr mentioned a patch should have two reviews and my one seems to have them. That is excellent - I'll be OpenJDK patch contributor soon! -jt > 22.11.2012 18:45, 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 dingxmin at linux.vnet.ibm.com Wed Dec 5 06:12:46 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 05 Dec 2012 14:12:46 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50BC8497.5030409@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> <50B5AF37.3070307@linux.vnet.ibm.com> <50BC8497.5030409@oracle.com> Message-ID: <50BEE5DE.9020803@linux.vnet.ibm.com> Hi Alexandr, I observed the same issue in my environment as well. My proposed patch would cause severe regression issues. I am looking into the locking issue. Thanks, Frank On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote: > > > Could you check the following sample with your latest fix? It just > hangs on my side. > > - put the sample.html and the response.html files on a server > - update path to the html files in the LoadingWebPageToJEditorPane > class > > ------------- sample.html ------------ >
> Username: > >
> ------------- response.html ------------ > > > Hello World! > > > ------------- LoadingWebPageToJEditorPane.html ------------ > import java.net.URL; > import javax.swing.JEditorPane; > import javax.swing.JFrame; > import javax.swing.JScrollPane; > import javax.swing.SwingUtilities; > > public class LoadingWebPageToJEditorPane { > > private static final String HTML_PATH = > "http://serever/path/sample.html"; > > public static void main(String[] a) throws Exception { > > SwingUtilities.invokeAndWait(new Runnable() { > > @Override > public void run() { > try { > > JFrame frame = new JFrame(); > frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > JEditorPane editorPane = new JEditorPane(); > editorPane.setPage(new URL(HTML_PATH)); > > frame.add(new JScrollPane(editorPane)); > frame.setSize(300, 200); > frame.setVisible(true); > SwingUtilities.updateComponentTreeUI(editorPane); > } catch (Exception ex) { > throw new RuntimeException(ex); > } > } > }); > } > } > --------------------------------------- > > Thanks, > Alexandr. > > > On 11/28/2012 10:29 AM, Frank Ding wrote: >> 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 anton.litvinov at oracle.com Wed Dec 5 09:33:48 2012 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 05 Dec 2012 13:33:48 +0400 Subject: [8] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Message-ID: <50BF14FC.8070201@oracle.com> Hello, Please review the following fix for a bug. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 This bug consists in malfunctioning of serialization mechanism for Swing components in "Mac OS X" look and feel (L&F), which is used by default, when this test case is run on OS X operating system. Explicit setting of "Metal" L&F resolves this bug. Thank you, Anton From anthony.petrov at oracle.com Wed Dec 5 09:58:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 05 Dec 2012 13:58:18 +0400 Subject: [8] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50BF14FC.8070201@oracle.com> References: <50BF14FC.8070201@oracle.com> Message-ID: <50BF1ABA.5020705@oracle.com> Hi Anton, This fix seems to resolve the test failure, but not the bug itself. Do you think it makes sense to investigate why the Mac OS X L&F isn't serializable, and perhaps make it serializable so that the test passes w/o any modifications? -- best regards, Anthony On 12/5/2012 1:33 PM, Anton Litvinov wrote: > Hello, > > Please review the following fix for a bug. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 > Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 > > This bug consists in malfunctioning of serialization mechanism for Swing > components in "Mac OS X" look and feel (L&F), which is used by default, > when this test case is run on OS X operating system. Explicit setting of > "Metal" L&F resolves this bug. > > Thank you, > Anton From alexander.potochkin at oracle.com Wed Dec 5 10:40:11 2012 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Wed, 05 Dec 2012 14:40:11 +0400 Subject: [8] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50BF1ABA.5020705@oracle.com> References: <50BF14FC.8070201@oracle.com> <50BF1ABA.5020705@oracle.com> Message-ID: <50BF248B.50900@oracle.com> Hello Anthony > Hi Anton, > > This fix seems to resolve the test failure, but not the bug itself. > > Do you think it makes sense to investigate why the Mac OS X L&F isn't > serializable, and perhaps make it serializable so that the test passes > w/o any modifications? Let me answer this question. It is a known issue that AquaLaF doesn't support serialization. When we integrated this code to our repository I did a research and found that it is too complex and risky to fix, moreover since it works the same way for JDK6 (and no one complained) there is no business reason for doing that. Historically all Swing tests that are not related to a specific LaF are written for Metal. Since only Mac JDK sets its own LaF by default, the explicit setting of Metal is expected in this test. Thanks alexp > > -- > best regards, > Anthony > > On 12/5/2012 1:33 PM, Anton Litvinov wrote: >> Hello, >> >> Please review the following fix for a bug. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 >> >> This bug consists in malfunctioning of serialization mechanism for >> Swing components in "Mac OS X" look and feel (L&F), which is used by >> default, when this test case is run on OS X operating system. >> Explicit setting of "Metal" L&F resolves this bug. >> >> Thank you, >> Anton From anthony.petrov at oracle.com Wed Dec 5 10:39:56 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 05 Dec 2012 14:39:56 +0400 Subject: [8] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50BF248B.50900@oracle.com> References: <50BF14FC.8070201@oracle.com> <50BF1ABA.5020705@oracle.com> <50BF248B.50900@oracle.com> Message-ID: <50BF247C.90606@oracle.com> Hi Alexander, This sounds reasonable. Thanks for the clarification. Could this evaluation be added as a comment to the bug report, so that it would be clear to anyone why the fix simply works around the problem rather than resolves the underlying issue? -- best regards, Anthony On 12/5/2012 2:40 PM, Alexander Potochkin wrote: > Hello Anthony > >> Hi Anton, >> >> This fix seems to resolve the test failure, but not the bug itself. >> >> Do you think it makes sense to investigate why the Mac OS X L&F isn't >> serializable, and perhaps make it serializable so that the test passes >> w/o any modifications? > > Let me answer this question. > > It is a known issue that AquaLaF doesn't support serialization. > > When we integrated this code to our repository > I did a research and found that it is too complex and risky to fix, > moreover since it works the same way for JDK6 (and no one complained) > there is no business reason for doing that. > > Historically all Swing tests that are not related to a specific LaF are > written for Metal. > > Since only Mac JDK sets its own LaF by default, > the explicit setting of Metal is expected in this test. > > Thanks > alexp > >> >> -- >> best regards, >> Anthony >> >> On 12/5/2012 1:33 PM, Anton Litvinov wrote: >>> Hello, >>> >>> Please review the following fix for a bug. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 >>> >>> This bug consists in malfunctioning of serialization mechanism for >>> Swing components in "Mac OS X" look and feel (L&F), which is used by >>> default, when this test case is run on OS X operating system. >>> Explicit setting of "Metal" L&F resolves this bug. >>> >>> Thank you, >>> Anton From alexandr.scherbatiy at oracle.com Wed Dec 5 14:36:09 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 05 Dec 2012 18:36:09 +0400 Subject: [8] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50BF14FC.8070201@oracle.com> References: <50BF14FC.8070201@oracle.com> Message-ID: <50BF5BD9.60402@oracle.com> The fix looks good for me. Thanks, Alexandr. On 12/5/2012 1:33 PM, Anton Litvinov wrote: > Hello, > > Please review the following fix for a bug. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 > Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 > > This bug consists in malfunctioning of serialization mechanism for > Swing components in "Mac OS X" look and feel (L&F), which is used by > default, when this test case is run on OS X operating system. Explicit > setting of "Metal" L&F resolves this bug. > > Thank you, > Anton From anton.litvinov at oracle.com Wed Dec 5 16:53:36 2012 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 05 Dec 2012 20:53:36 +0400 Subject: [8] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50BF247C.90606@oracle.com> References: <50BF14FC.8070201@oracle.com> <50BF1ABA.5020705@oracle.com> <50BF248B.50900@oracle.com> <50BF247C.90606@oracle.com> Message-ID: <50BF7C10.1030200@oracle.com> Hello Anthony, Thank you for the review of this fix. The corresponding comment was added to the bug's page. Unfortunately it is not available on the public bug report yet for the reason of synchronization delay. A copy of this comment is provided below. Comment: It was learnt that incomplete support of serialization by "Mac OS X" look and feel (L&F) is a renowned issue, because of which JDK passes all JCK tests on OS X only with "Metal" L&F. "Metal" L&F is a cross-platform L&F, which is default for any Java application, therefore all Swing regression tests which are not related to another particular L&F, are written for "Metal" implicitly. Since only JDK for OS X changes "Metal" for "Mac OS X" by default, explicit setting of "Metal" L&F could be an acceptable workaround for correction of this test. Thank you, Anton On 12/5/2012 2:39 PM, Anthony Petrov wrote: > Hi Alexander, > > This sounds reasonable. Thanks for the clarification. > > Could this evaluation be added as a comment to the bug report, so that > it would be clear to anyone why the fix simply works around the > problem rather than resolves the underlying issue? > > -- > best regards, > Anthony > > On 12/5/2012 2:40 PM, Alexander Potochkin wrote: >> Hello Anthony >> >>> Hi Anton, >>> >>> This fix seems to resolve the test failure, but not the bug itself. >>> >>> Do you think it makes sense to investigate why the Mac OS X L&F >>> isn't serializable, and perhaps make it serializable so that the >>> test passes w/o any modifications? >> >> Let me answer this question. >> >> It is a known issue that AquaLaF doesn't support serialization. >> >> When we integrated this code to our repository >> I did a research and found that it is too complex and risky to fix, >> moreover since it works the same way for JDK6 (and no one complained) >> there is no business reason for doing that. >> >> Historically all Swing tests that are not related to a specific LaF >> are written for Metal. >> >> Since only Mac JDK sets its own LaF by default, >> the explicit setting of Metal is expected in this test. >> >> Thanks >> alexp >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 12/5/2012 1:33 PM, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Please review the following fix for a bug. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 >>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 >>>> >>>> This bug consists in malfunctioning of serialization mechanism for >>>> Swing components in "Mac OS X" look and feel (L&F), which is used >>>> by default, when this test case is run on OS X operating system. >>>> Explicit setting of "Metal" L&F resolves this bug. >>>> >>>> Thank you, >>>> Anton From anthony.petrov at oracle.com Wed Dec 5 18:31:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 05 Dec 2012 22:31:48 +0400 Subject: [8] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50BF7C10.1030200@oracle.com> References: <50BF14FC.8070201@oracle.com> <50BF1ABA.5020705@oracle.com> <50BF248B.50900@oracle.com> <50BF247C.90606@oracle.com> <50BF7C10.1030200@oracle.com> Message-ID: <50BF9314.8050008@oracle.com> Thank you, Anton. The comment looks fine to me (and so does the fix). -- best regards, Anthony On 12/5/2012 8:53 PM, Anton Litvinov wrote: > Hello Anthony, > > Thank you for the review of this fix. The corresponding comment was > added to the bug's page. Unfortunately it is not available on the public > bug report yet for the reason of synchronization delay. A copy of this > comment is provided below. > > Comment: > It was learnt that incomplete support of serialization by "Mac OS X" > look and feel (L&F) is a renowned issue, because of which JDK passes all > JCK tests on OS X only with "Metal" L&F. "Metal" L&F is a cross-platform > L&F, which is default for any Java application, therefore all Swing > regression tests which are not related to another particular L&F, are > written for "Metal" implicitly. Since only JDK for OS X changes "Metal" > for "Mac OS X" by default, explicit setting of "Metal" L&F could be an > acceptable workaround for correction of this test. > > Thank you, > Anton > > On 12/5/2012 2:39 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> This sounds reasonable. Thanks for the clarification. >> >> Could this evaluation be added as a comment to the bug report, so that >> it would be clear to anyone why the fix simply works around the >> problem rather than resolves the underlying issue? >> >> -- >> best regards, >> Anthony >> >> On 12/5/2012 2:40 PM, Alexander Potochkin wrote: >>> Hello Anthony >>> >>>> Hi Anton, >>>> >>>> This fix seems to resolve the test failure, but not the bug itself. >>>> >>>> Do you think it makes sense to investigate why the Mac OS X L&F >>>> isn't serializable, and perhaps make it serializable so that the >>>> test passes w/o any modifications? >>> >>> Let me answer this question. >>> >>> It is a known issue that AquaLaF doesn't support serialization. >>> >>> When we integrated this code to our repository >>> I did a research and found that it is too complex and risky to fix, >>> moreover since it works the same way for JDK6 (and no one complained) >>> there is no business reason for doing that. >>> >>> Historically all Swing tests that are not related to a specific LaF >>> are written for Metal. >>> >>> Since only Mac JDK sets its own LaF by default, >>> the explicit setting of Metal is expected in this test. >>> >>> Thanks >>> alexp >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 12/5/2012 1:33 PM, Anton Litvinov wrote: >>>>> Hello, >>>>> >>>>> Please review the following fix for a bug. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 >>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 >>>>> >>>>> This bug consists in malfunctioning of serialization mechanism for >>>>> Swing components in "Mac OS X" look and feel (L&F), which is used >>>>> by default, when this test case is run on OS X operating system. >>>>> Explicit setting of "Metal" L&F resolves this bug. >>>>> >>>>> Thank you, >>>>> Anton From dingxmin at linux.vnet.ibm.com Thu Dec 6 08:39:43 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 06 Dec 2012 16:39:43 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50BEE5DE.9020803@linux.vnet.ibm.com> References: <501F6E2E.1020608@linux.vnet.ibm.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> <50B5AF37.3070307@linux.vnet.ibm.com> <50BC8497.5030409@oracle.com> <50BEE5DE.9020803@linux.vnet.ibm.com> Message-ID: <50C059CF.4090806@linux.vnet.ibm.com> Hi Alexandr, I did several attempts but still have hang issues somewhere. It seems the new approach of caching gui components created each time is not practical because of the threading restriction already imposed on HTMLDocument. Can we make compromise by turning to previous solution (v7 in particular) and generalize it to other gui components (which means there would be JCheckBoxWrapper, JRadioButtonWrapper, JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, JComboBoxWrapper, and JButtonWrapper). Or shall we fix JButton only because it causes obvious exception visible to client? I am short of ideas... http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ Best regards, Frank On 12/5/2012 2:12 PM, Frank Ding wrote: > Hi Alexandr, > I observed the same issue in my environment as well. My proposed > patch would cause severe regression issues. I am looking into the > locking issue. > > Thanks, > Frank > > On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote: >> >> >> Could you check the following sample with your latest fix? It just >> hangs on my side. >> >> - put the sample.html and the response.html files on a server >> - update path to the html files in the LoadingWebPageToJEditorPane >> class >> >> ------------- sample.html ------------ >>
>> Username: >> >>
>> ------------- response.html ------------ >> >> >> Hello World! >> >> >> ------------- LoadingWebPageToJEditorPane.html ------------ >> import java.net.URL; >> import javax.swing.JEditorPane; >> import javax.swing.JFrame; >> import javax.swing.JScrollPane; >> import javax.swing.SwingUtilities; >> >> public class LoadingWebPageToJEditorPane { >> >> private static final String HTML_PATH = >> "http://serever/path/sample.html"; >> >> public static void main(String[] a) throws Exception { >> >> SwingUtilities.invokeAndWait(new Runnable() { >> >> @Override >> public void run() { >> try { >> >> JFrame frame = new JFrame(); >> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> >> JEditorPane editorPane = new JEditorPane(); >> editorPane.setPage(new URL(HTML_PATH)); >> >> frame.add(new JScrollPane(editorPane)); >> frame.setSize(300, 200); >> frame.setVisible(true); >> SwingUtilities.updateComponentTreeUI(editorPane); >> } catch (Exception ex) { >> throw new RuntimeException(ex); >> } >> } >> }); >> } >> } >> --------------------------------------- >> >> Thanks, >> Alexandr. >> >> >> On 11/28/2012 10:29 AM, Frank Ding wrote: >>> 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 anton.litvinov at oracle.com Thu Dec 6 09:50:34 2012 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 06 Dec 2012 13:50:34 +0400 Subject: [7u12] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Message-ID: <50C06A6A.3070505@oracle.com> Hello, Please review the following fix for a bug. It is a backport of the fix for JDK 8 which is already reviewed. The fix is identical to the fix for JDK 8. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 Thank you, Anton From alexandr.scherbatiy at oracle.com Thu Dec 6 13:21:15 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 06 Dec 2012 17:21:15 +0400 Subject: Review request for 8003830: NPE at BasicTreeUI$Actions.page:4470 In-Reply-To: <2386262.apLmzK4PCh@logoutik> References: <4204137.uMKAJHeSPn@logoutik> <50BDDF8B.80309@oracle.com> <2386262.apLmzK4PCh@logoutik> Message-ID: <50C09BCB.1060701@oracle.com> On 12/4/2012 10:53 PM, Jaroslav Tulach wrote: > Dne ?t 4. prosince 2012 15:33:31, Sergey Bylokhov napsal(a): >> Hi, Jaroslav. >> Fix looks good. > Thanks a log Sergey. Alexandr mentioned a patch should have two reviews and my > one seems to have them. That is excellent - I'll be OpenJDK patch contributor > soon! I have pushed your fix to JDK 8 and JDK 7u12: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bd175c70684c http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/6e5fb6026484 Thanks, Alexandr. > -jt > >> 22.11.2012 18:45, 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 Dec 6 13:24:09 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 06 Dec 2012 17:24:09 +0400 Subject: [7u12] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50C06A6A.3070505@oracle.com> References: <50C06A6A.3070505@oracle.com> Message-ID: <50C09C79.1070301@oracle.com> The fix looks good for me. Thanks, Alexandr. On 12/6/2012 1:50 PM, Anton Litvinov wrote: > Hello, > > Please review the following fix for a bug. It is a backport of the fix > for JDK 8 which is already reviewed. The fix is identical to the fix > for JDK 8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 > Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 > > Thank you, > Anton From Sergey.Bylokhov at oracle.com Thu Dec 6 13:35:05 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 06 Dec 2012 17:35:05 +0400 Subject: [7u12] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50C06A6A.3070505@oracle.com> References: <50C06A6A.3070505@oracle.com> Message-ID: <50C09F09.3090309@oracle.com> Just FYI You could add additional options to the test via @run tag For example, how to run test 2 times with different lafs: /* * @test * @bug bug6438430 * @summary .... * @run main/othervm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel bug6438430 * @run main/othervm -Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel bug6438430 */ 06.12.2012 13:50, Anton Litvinov ?????: > Hello, > > Please review the following fix for a bug. It is a backport of the fix > for JDK 8 which is already reviewed. The fix is identical to the fix > for JDK 8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 > Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 > > Thank you, > Anton -- Best regards, Sergey. From anton.litvinov at oracle.com Thu Dec 6 14:36:24 2012 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 06 Dec 2012 18:36:24 +0400 Subject: [7u12] Review request for 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx In-Reply-To: <50C09F09.3090309@oracle.com> References: <50C06A6A.3070505@oracle.com> <50C09F09.3090309@oracle.com> Message-ID: <50C0AD68.7020400@oracle.com> Hello Sergey, Thank you for this solution, about which I did not know before. I will remember it. Thank you, Anton On 12/6/2012 5:35 PM, Sergey Bylokhov wrote: > Just FYI > You could add additional options to the test via @run tag > For example, how to run test 2 times with different lafs: > > /* > * @test > * @bug bug6438430 > * @summary .... > * @run main/othervm > -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel bug6438430 > * @run main/othervm > -Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel > bug6438430 > */ > > 06.12.2012 13:50, Anton Litvinov ?????: >> Hello, >> >> Please review the following fix for a bug. It is a backport of the >> fix for JDK 8 which is already reviewed. The fix is identical to the >> fix for JDK 8. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003982 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8003982/webrev.00 >> >> Thank you, >> Anton > > From alexandr.scherbatiy at oracle.com Thu Dec 6 15:01:19 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 06 Dec 2012 19:01:19 +0400 Subject: [8] Review request for 8003978 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on macosx Message-ID: <50C0B33F.2040903@oracle.com> Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978 webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00 The test fails because now Alt+U key combination returns right dead key code instead of the key code for the 'U' key. The solution is to use Ctrl+Alt key combination for menu mnemonics like it is done for button mnemonics. The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get the system depended mnemonic key mask and puts it to the Menu.shortcutKeys property in the BasicLookAndFeel. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Thu Dec 6 15:15:35 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 06 Dec 2012 19:15:35 +0400 Subject: [8] Review request for 8003978 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on macosx In-Reply-To: <50C0B33F.2040903@oracle.com> References: <50C0B33F.2040903@oracle.com> Message-ID: <50C0B697.4090904@oracle.com> Hi, Alexander. Does motif l&f work on macosx with META_MASK - MotifLookAndFeel.java:? 633 "Menu.shortcutKeys", new int[]{ 634 SwingUtilities2.getSystemMnemonicKeyMask(), 635 KeyEvent.META_MASK 636 }, 06.12.2012 19:01, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978 > webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00 > > The test fails because now Alt+U key combination returns right dead > key code instead of the key code for the 'U' key. > The solution is to use Ctrl+Alt key combination for menu mnemonics > like it is done for button mnemonics. > > The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get > the system depended mnemonic key mask and puts it to the > Menu.shortcutKeys property in the BasicLookAndFeel. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Dec 6 15:22:42 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 06 Dec 2012 19:22:42 +0400 Subject: [8] Review request for 8003978 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on macosx In-Reply-To: <50C0B697.4090904@oracle.com> References: <50C0B33F.2040903@oracle.com> <50C0B697.4090904@oracle.com> Message-ID: <50C0B842.4050806@oracle.com> On 12/6/2012 7:15 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Does motif l&f work on macosx with META_MASK - MotifLookAndFeel.java:? Yes, it does. Thanks, Alexandr. > > 633 "Menu.shortcutKeys", new int[]{ > 634 SwingUtilities2.getSystemMnemonicKeyMask(), > 635 KeyEvent.META_MASK > 636 }, > > > 06.12.2012 19:01, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978 >> webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00 >> >> The test fails because now Alt+U key combination returns right dead >> key code instead of the key code for the 'U' key. >> The solution is to use Ctrl+Alt key combination for menu mnemonics >> like it is done for button mnemonics. >> >> The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get >> the system depended mnemonic key mask and puts it to the >> Menu.shortcutKeys property in the BasicLookAndFeel. >> >> Thanks, >> Alexandr. >> > > From dingxmin at linux.vnet.ibm.com Mon Dec 10 07:08:16 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Mon, 10 Dec 2012 15:08:16 +0800 Subject: [Accessibility]Focus unable to traverse in the menubar In-Reply-To: <5072BD4E.6040203@oracle.com> References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill> <4E8C7A0B.7060006@oracle.com> <4E92EB65.6080605@oracle.com> <1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com> <4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com> <4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com> <5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com> <5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com> Message-ID: <50C58A60.1020100@linux.vnet.ibm.com> Hi Pavel, I think pointing out the special behavior in javadoc makes more sense. Could you please take a look at my draft below? http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01 Note that I think in the sentence "By default, methods of this class with return a Component only if it is" it should be "will" not "with", shouldn't it? Expecting your reply. Best regards, Frank On 10/8/2012 7:47 PM, pavel porvatov wrote: > Hi Jonathan, >> Hi Pavel, >> >> On 10/02/2012 11:31 PM, Pavel Porvatov wrote: >>> Hi Jonathan, >>>> Hi Pavel, >>>> >>>> I've filed bug 7198816 for this problem, >>>> >>>> Regards, Pavel >>>> http://bugs.sun.com/view_bug.do?bug_id=7198816 >>> This bug was not ported to jira, so I created another bug: >>> https://jbs.oracle.com/bugs/browse/JDK-8000326 >> >> Thanks for porting, but I have trouble with opening that link. > Sorry, use the following link: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326 > > but the bug is not available yet... It contains the same description > as the original bug. > >> Any comments on the patch? > The fix looks dangerous for me. After the fix the > setFocusTraversalKeysEnabled method doesn't work for JMenuBar (when > ContainerOrderFocusTraversalPolicy is used) - it ignores this property... > > Regards, Pavel >> >> best regards >> Jonathan >> >>> >>> Regards, Pavel >>>> >>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote: >>>>> Hi Jing, >>>>>> Thanks Pavel, >>>>>> >>>>>> It seems fine to me, if no other suggestions/opinions, I >>>>>> guess we can move on with this? >>>>> Yes, we can. Could you please file a bug for the problem as well? >>>>> >>>>> Thanks, Pavel >>>>>> >>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote: >>>>>>> Hi Jing, >>>>>>>> >>>>>>>> Hello Anton, >>>>>>>> >>>>>>>> Thanks for the review. I am still trying to figure out some >>>>>>>> real case and provide more detail the customer may fail. >>>>>>>> Anyway, I agree we'd better update the java spec to make it >>>>>>>> clear for the customers. I'd like to know if anyone can help >>>>>>>> with that? >>>>>>> I'm not sure that javadoc changing is a good decision in this >>>>>>> case. ContainerOrderFocusTraversalPolicy is designed for AWT, >>>>>>> but I don't know why that policy cannot be used for Swing >>>>>>> components as well. I see several problems: >>>>>>> 1. We cannot change javadoc of >>>>>>> ContainerOrderFocusTraversalPolicy because of backward >>>>>>> compatibility >>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) from the >>>>>>> JMenuBar#JMenuBar() constructor because of backward compatibility >>>>>>> >>>>>>> May be the best decision is to specify, that JMenuBar creates >>>>>>> menu with the focusTraversalKeysEnabled = false >>>> >>>> Did you mean that for the new menu >>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does not >>>> seem to work for this problem. >>>> >>>> if my understanding is incorrect, please help to fix me. >>>> >>>>>>> >>>>>>> Regards, Pavel >>>>>>>> >>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote: >>>>>>>>> Hi Neil, >>>>>>>>> >>>>>>>>> On 10/10/2011 7:01 PM, Neil Richards wrote: >>>>>>>>>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote: >>>>>>>>>>> Hi Neil and Jing, >>>>>>>>>>> I'm afraid that it's wrong to use >>>>>>>>>>> ContainerOrderFocusTraversalPolicy >>>>>>>>>>> for swing components. This policy is designed for AWT. >>>>>>>>>>> JMenuBar calls setFocusTraversalKeysEnabled(false) in its >>>>>>>>>>> ctor which >>>>>>>>>>> means that it "swallows" focus traversal keys (like >>>>>>>>>>> TAB/SHIFT-TAB >>>>>>>>>>> etc.) >>>>>>>>>>> and so it can't be a member of a focus traversal chain. Swing's >>>>>>>>>>> default traversal policy (LayoutFocusTraversalPolicy) excludes >>>>>>>>>>> JMenuBar >>>>>>>>>>> from a focus traversal cycle. >>>>>>>>>>> ContainerOrderFocusTraversalPolicy is >>>>>>>>>>> not "aware" about JMenuBar and so it allows it. >>>>>>>>>>> >>>>>>>>>>> So, either a default Swing policy should be used, or a >>>>>>>>>>> custom policy. >>>>>>>>>>> At worst, ContainerOrderFocusTraversalPolicy should be >>>>>>>>>>> overriden >>>>>>>>>>> to exclude JMenuBar from a cycle (override its >>>>>>>>>>> accept(Component) >>>>>>>>>>> method). >>>> >>>> I agree that backward compatibility should not be broken by the >>>> fix, so here's a patch from me for the worst case, could you please >>>> help to take a look? >>>> >>>> http://cr.openjdk.java.net/~luchsh/7198816/ >>>> >>>> Thanks >>>> Jonathan >>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Anton. >>>>>>>>>> Hi Anton, >>>>>>>>>> Thanks for reviewing the suggestion, and for your insights >>>>>>>>>> into this >>>>>>>>>> scenario. >>>>>>>>>> >>>>>>>>>> > From the Javadoc, it seems that >>>>>>>>>> setFocusTraversalKeysEnabled() is mainly >>>>>>>>>> concerned with choosing whether focus traversal key presses >>>>>>>>>> (normally >>>>>>>>>> TAB and SHIFT-TAB) are processed "automatically" (when >>>>>>>>>> 'true') or are >>>>>>>>>> delivered to the Component as key events (for the component's >>>>>>>>>> code to >>>>>>>>>> process "manually"). >>>>>>>>>> >>>>>>>>>> (In the case of JMenuBar, it makes them come through as key >>>>>>>>>> events, but >>>>>>>>>> doesn't do anything special to process these events, which is >>>>>>>>>> why they >>>>>>>>>> get discarded.) >>>>>>>>> >>>>>>>>> That is right, though it doesn't directly relate to the issue >>>>>>>>> we're talking about =) >>>>>>>>> >>>>>>>>>> Your description above, though, seems to suggest that it is >>>>>>>>>> generally >>>>>>>>>> undesirable for the JMenuBar to be given the focus, as all the >>>>>>>>>> Swing-aware focus traversal policies make a point of not >>>>>>>>>> giving focus to >>>>>>>>>> JMenuBar items. >>>>>>>>>> >>>>>>>>>> If this is so, then wouldn't it make sense to call >>>>>>>>>> setFocusable(false) >>>>>>>>>> from its constructor (too), to ensure it doesn't get focus ? >>>>>>>>>> >>>>>>>>>> Or, to put it another way, could you explain a little of the >>>>>>>>>> reasoning >>>>>>>>>> or scenario behind why it is desirable for JMenuBar items to be >>>>>>>>>> generally focusable, even though they aren't focus-traversable ? >>>>>>>>>> >>>>>>>>>> I think such an explanation would be really helpful in >>>>>>>>>> clearing up my >>>>>>>>>> confusion on this point. >>>>>>>>>> >>>>>>>>>> Thanks, Neil >>>>>>>>>> >>>>>>>>> >>>>>>>>> Well, I suspect that the core of the problem is that adding >>>>>>>>> JMenuBar as JComponent to a swing >>>>>>>>> container doesn't make much sense. Though it is not directly >>>>>>>>> prohibited, doing so may cause >>>>>>>>> side effects like the one you've discovered. When JMenuBar is >>>>>>>>> set properly onto a JFrame its focus >>>>>>>>> is managed by JRootPane and its focusability just isn't taken >>>>>>>>> into account. That's may be the reason >>>>>>>>> it's not declared unfocusable. Honestly, I can't tell you >>>>>>>>> exactly. >>>>>>>>> >>>>>>>>> If you do it, you probably won't make any harm, but I >>>>>>>>> personally don't think this is a vital fix >>>>>>>>> (unless you have a good use case of the scenario you've >>>>>>>>> provided). Anyway, this is a swing question >>>>>>>>> (I'm, as an AWT dev member, leaving the decision to swing guys). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Anton. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Dec 10 10:40:24 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 10 Dec 2012 14:40:24 +0400 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50C059CF.4090806@linux.vnet.ibm.com> References: <501F6E2E.1020608@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> <50B5AF37.3070307@linux.vnet.ibm.com> <50BC8497.5030409@oracle.com> <50BEE5DE.9020803@linux.vnet.ibm.com> <50C059CF.4090806@linux.vnet.ibm.com> Message-ID: <50C5BC18.8030009@oracle.com> On 12/6/2012 12:39 PM, Frank Ding wrote: > Hi Alexandr, > I did several attempts but still have hang issues somewhere. It > seems the new approach of caching gui components created each time is > not practical because of the threading restriction already imposed on > HTMLDocument. > Can we make compromise by turning to previous solution (v7 in > particular) and generalize it to other gui components (which means > there would be JCheckBoxWrapper, JRadioButtonWrapper, The issue is that models contain listeners from all previous components. Models are used to store data and state of components when form view is recreated. FormView adds it's own listeners to components (and as result to the models). Could you make a little investigation to check which other listeners can the models hold? Can a user adds a listener? Can listeners be added by other parts of the swing.text.html library? If old listeners does not play role, it is possible just to remove them all. Thanks, Alexandr. > JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, > JComboBoxWrapper, and JButtonWrapper). Or shall we fix JButton only > because it causes obvious exception visible to client? I am short of > ideas... > http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ > > Best regards, > Frank > > On 12/5/2012 2:12 PM, Frank Ding wrote: >> Hi Alexandr, >> I observed the same issue in my environment as well. My proposed >> patch would cause severe regression issues. I am looking into the >> locking issue. >> >> Thanks, >> Frank >> >> On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote: >>> >>> >>> Could you check the following sample with your latest fix? It just >>> hangs on my side. >>> >>> - put the sample.html and the response.html files on a server >>> - update path to the html files in the >>> LoadingWebPageToJEditorPane class >>> >>> ------------- sample.html ------------ >>>
>>> Username: >>> >>>
>>> ------------- response.html ------------ >>> >>> >>> Hello World! >>> >>> >>> ------------- LoadingWebPageToJEditorPane.html ------------ >>> import java.net.URL; >>> import javax.swing.JEditorPane; >>> import javax.swing.JFrame; >>> import javax.swing.JScrollPane; >>> import javax.swing.SwingUtilities; >>> >>> public class LoadingWebPageToJEditorPane { >>> >>> private static final String HTML_PATH = >>> "http://serever/path/sample.html"; >>> >>> public static void main(String[] a) throws Exception { >>> >>> SwingUtilities.invokeAndWait(new Runnable() { >>> >>> @Override >>> public void run() { >>> try { >>> >>> JFrame frame = new JFrame(); >>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>> >>> JEditorPane editorPane = new JEditorPane(); >>> editorPane.setPage(new URL(HTML_PATH)); >>> >>> frame.add(new JScrollPane(editorPane)); >>> frame.setSize(300, 200); >>> frame.setVisible(true); >>> SwingUtilities.updateComponentTreeUI(editorPane); >>> } catch (Exception ex) { >>> throw new RuntimeException(ex); >>> } >>> } >>> }); >>> } >>> } >>> --------------------------------------- >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 11/28/2012 10:29 AM, Frank Ding wrote: >>>> 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 vera.akulova at oracle.com Mon Dec 10 15:29:38 2012 From: vera.akulova at oracle.com (vera akulova) Date: Mon, 10 Dec 2012 19:29:38 +0400 Subject: [8] Review request for JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction Message-ID: <50C5FFE2.4070906@oracle.com> Hello, Please review a fix for the issue: JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction The webrev is http://cr.openjdk.java.net/~kshefov/6757986/webrev.00/ The manual test from closed repo was automated. Fixed test works fine on windows, linux, solaris and macos. Thanks, Vera. From Sergey.Bylokhov at oracle.com Tue Dec 11 12:11:22 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Dec 2012 16:11:22 +0400 Subject: [8] Review request for JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction In-Reply-To: <50C5FFE2.4070906@oracle.com> References: <50C5FFE2.4070906@oracle.com> Message-ID: <50C722EA.9050807@oracle.com> Hello, Vera. setBounds() can be ignored by native system, I suggest to fetch real coordinates from the window instead of 50,50. Also bug5066752 is a typo in 24 @test bug5066752 ? 10.12.2012 19:29, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java > needs correction > > The webrev is http://cr.openjdk.java.net/~kshefov/6757986/webrev.00/ > > The manual test from closed repo was automated. Fixed test works fine > on windows, linux, solaris and macos. > > Thanks, > Vera. -- Best regards, Sergey. From vera.akulova at oracle.com Tue Dec 11 14:44:15 2012 From: vera.akulova at oracle.com (vera akulova) Date: Tue, 11 Dec 2012 18:44:15 +0400 Subject: [8] Review request for JDK-7132383: [macosx] bug6596966.java should be adapted for Mac Message-ID: <50C746BF.1020805@oracle.com> Hello, Please review a fix for the issue: JDK-7132383: [macosx] bug6596966.java should be adapted for Mac The webrev is http://cr.openjdk.java.net/~kshefov/7132383/webrev.00/ Ctrl-Alt-Mnemonic is used now for Mac instead of Alt-Mnemonic. Fixed test works fine on windows, linux, solaris and macos. Thanks, Vera. From vera.akulova at oracle.com Tue Dec 11 14:53:38 2012 From: vera.akulova at oracle.com (vera akulova) Date: Tue, 11 Dec 2012 18:53:38 +0400 Subject: [8] Review request for JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction In-Reply-To: <50C722EA.9050807@oracle.com> References: <50C5FFE2.4070906@oracle.com> <50C722EA.9050807@oracle.com> Message-ID: <50C748F2.7090804@oracle.com> Hello Sergey, Thanks for your reply, I created new webrev: http://cr.openjdk.java.net/~kshefov/6757986/webrev.01 (typo near tag @test fixed, real coordinates are used to get color now) Thanks, Vera On 11.12.2012 16:11, Sergey Bylokhov wrote: > Hello, Vera. > setBounds() can be ignored by native system, I suggest to fetch real > coordinates from the window instead of 50,50. > Also bug5066752 is a typo in 24 @test bug5066752 ? > > 10.12.2012 19:29, vera akulova wrote: >> Hello, >> >> Please review a fix for the issue: >> JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java >> needs correction >> >> The webrev is http://cr.openjdk.java.net/~kshefov/6757986/webrev.00/ >> >> The manual test from closed repo was automated. Fixed test works >> fine on windows, linux, solaris and macos. >> >> Thanks, >> Vera. > > From vera.akulova at oracle.com Tue Dec 11 15:55:08 2012 From: vera.akulova at oracle.com (vera akulova) Date: Tue, 11 Dec 2012 19:55:08 +0400 Subject: [8] Review request for JDK-7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS Message-ID: <50C7575C.3030806@oracle.com> Hello, Please review a fix for the issue: JDK-7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS The webrev is http://cr.openjdk.java.net/~kshefov/7133146/webrev.00/ Metal L&F is used now. Fixed test works fine on windows, linux, solaris and macos. Thanks, Vera. From vera.akulova at oracle.com Tue Dec 11 16:52:06 2012 From: vera.akulova at oracle.com (vera akulova) Date: Tue, 11 Dec 2012 20:52:06 +0400 Subject: [8] Review request for JDK-7132385: [macosx] IconifyTest of RepaintManager could use some delay Message-ID: <50C764B6.5090305@oracle.com> Hello, Please review a fix for the issue: JDK-7132385: [macosx] IconifyTest of RepaintManager could use some delay The webrev is http://cr.openjdk.java.net/~kshefov/7132385/webrev.00/ Added realSync(). Fixed test works fine on windows, linux, solaris and macos. Thanks, Vera. From Sergey.Bylokhov at oracle.com Tue Dec 11 16:56:53 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Dec 2012 20:56:53 +0400 Subject: [8] Review request for JDK-7132385: [macosx] IconifyTest of RepaintManager could use some delay In-Reply-To: <50C764B6.5090305@oracle.com> References: <50C764B6.5090305@oracle.com> Message-ID: <50C765D5.5010600@oracle.com> Hi, Vera. Fix looks good. 11.12.2012 20:52, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-7132385: [macosx] IconifyTest of RepaintManager could use some > delay > > The webrev is http://cr.openjdk.java.net/~kshefov/7132385/webrev.00/ > > Added realSync(). Fixed test works fine on windows, linux, solaris and > macos. > > Thanks, > Vera. -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Dec 12 14:07:50 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 12 Dec 2012 18:07:50 +0400 Subject: [Accessibility]Focus unable to traverse in the menubar In-Reply-To: <50C58A60.1020100@linux.vnet.ibm.com> References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill> <4E8C7A0B.7060006@oracle.com> <4E92EB65.6080605@oracle.com> <1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com> <4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com> <4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com> <5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com> <5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com> <50C58A60.1020100@linux.vnet.ibm.com> Message-ID: <50C88FB6.20103@oracle.com> On 12/10/2012 11:08 AM, Frank Ding wrote: > Hi Pavel, > I think pointing out the special behavior in javadoc makes more > sense. Could you please take a look at my draft below? > http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01 I think that It has more sense to point this special behavior in the JMenuBar class itself. It looks more naturally to read about the JMenuBar focus traversal behaviour from the JMenuBar javadoc. > Note that I think in the sentence "By default, methods of this class > with return a Component only if it is" it should be "will" not "with", > shouldn't it? Thank you that you point it out. Could you create an issue on it? Thanks, Alexandr. > > Expecting your reply. > Best regards, > Frank > > On 10/8/2012 7:47 PM, pavel porvatov wrote: >> Hi Jonathan, >>> Hi Pavel, >>> >>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote: >>>> Hi Jonathan, >>>>> Hi Pavel, >>>>> >>>>> I've filed bug 7198816 for this problem, >>>>> >>>>> Regards, Pavel >>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816 >>>> This bug was not ported to jira, so I created another bug: >>>> https://jbs.oracle.com/bugs/browse/JDK-8000326 >>> >>> Thanks for porting, but I have trouble with opening that link. >> Sorry, use the following link: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326 >> >> but the bug is not available yet... It contains the same description >> as the original bug. >> >>> Any comments on the patch? >> The fix looks dangerous for me. After the fix the >> setFocusTraversalKeysEnabled method doesn't work for JMenuBar (when >> ContainerOrderFocusTraversalPolicy is used) - it ignores this >> property... >> >> Regards, Pavel >>> >>> best regards >>> Jonathan >>> >>>> >>>> Regards, Pavel >>>>> >>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote: >>>>>> Hi Jing, >>>>>>> Thanks Pavel, >>>>>>> >>>>>>> It seems fine to me, if no other suggestions/opinions, I >>>>>>> guess we can move on with this? >>>>>> Yes, we can. Could you please file a bug for the problem as well? >>>>>> >>>>>> Thanks, Pavel >>>>>>> >>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote: >>>>>>>> Hi Jing, >>>>>>>>> >>>>>>>>> Hello Anton, >>>>>>>>> >>>>>>>>> Thanks for the review. I am still trying to figure out >>>>>>>>> some real case and provide more detail the customer may fail. >>>>>>>>> Anyway, I agree we'd better update the java spec to make >>>>>>>>> it clear for the customers. I'd like to know if anyone can >>>>>>>>> help with that? >>>>>>>> I'm not sure that javadoc changing is a good decision in this >>>>>>>> case. ContainerOrderFocusTraversalPolicy is designed for AWT, >>>>>>>> but I don't know why that policy cannot be used for Swing >>>>>>>> components as well. I see several problems: >>>>>>>> 1. We cannot change javadoc of >>>>>>>> ContainerOrderFocusTraversalPolicy because of backward >>>>>>>> compatibility >>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) from >>>>>>>> the JMenuBar#JMenuBar() constructor because of backward >>>>>>>> compatibility >>>>>>>> >>>>>>>> May be the best decision is to specify, that JMenuBar creates >>>>>>>> menu with the focusTraversalKeysEnabled = false >>>>> >>>>> Did you mean that for the new menu >>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does not >>>>> seem to work for this problem. >>>>> >>>>> if my understanding is incorrect, please help to fix me. >>>>> >>>>>>>> >>>>>>>> Regards, Pavel >>>>>>>>> >>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote: >>>>>>>>>> Hi Neil, >>>>>>>>>> >>>>>>>>>> On 10/10/2011 7:01 PM, Neil Richards wrote: >>>>>>>>>>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote: >>>>>>>>>>>> Hi Neil and Jing, >>>>>>>>>>>> I'm afraid that it's wrong to use >>>>>>>>>>>> ContainerOrderFocusTraversalPolicy >>>>>>>>>>>> for swing components. This policy is designed for AWT. >>>>>>>>>>>> JMenuBar calls setFocusTraversalKeysEnabled(false) in its >>>>>>>>>>>> ctor which >>>>>>>>>>>> means that it "swallows" focus traversal keys (like >>>>>>>>>>>> TAB/SHIFT-TAB >>>>>>>>>>>> etc.) >>>>>>>>>>>> and so it can't be a member of a focus traversal chain. >>>>>>>>>>>> Swing's >>>>>>>>>>>> default traversal policy (LayoutFocusTraversalPolicy) excludes >>>>>>>>>>>> JMenuBar >>>>>>>>>>>> from a focus traversal cycle. >>>>>>>>>>>> ContainerOrderFocusTraversalPolicy is >>>>>>>>>>>> not "aware" about JMenuBar and so it allows it. >>>>>>>>>>>> >>>>>>>>>>>> So, either a default Swing policy should be used, or a >>>>>>>>>>>> custom policy. >>>>>>>>>>>> At worst, ContainerOrderFocusTraversalPolicy should be >>>>>>>>>>>> overriden >>>>>>>>>>>> to exclude JMenuBar from a cycle (override its >>>>>>>>>>>> accept(Component) >>>>>>>>>>>> method). >>>>> >>>>> I agree that backward compatibility should not be broken by the >>>>> fix, so here's a patch from me for the worst case, could you >>>>> please help to take a look? >>>>> >>>>> http://cr.openjdk.java.net/~luchsh/7198816/ >>>>> >>>>> Thanks >>>>> Jonathan >>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Anton. >>>>>>>>>>> Hi Anton, >>>>>>>>>>> Thanks for reviewing the suggestion, and for your insights >>>>>>>>>>> into this >>>>>>>>>>> scenario. >>>>>>>>>>> >>>>>>>>>>> > From the Javadoc, it seems that >>>>>>>>>>> setFocusTraversalKeysEnabled() is mainly >>>>>>>>>>> concerned with choosing whether focus traversal key presses >>>>>>>>>>> (normally >>>>>>>>>>> TAB and SHIFT-TAB) are processed "automatically" (when >>>>>>>>>>> 'true') or are >>>>>>>>>>> delivered to the Component as key events (for the >>>>>>>>>>> component's code to >>>>>>>>>>> process "manually"). >>>>>>>>>>> >>>>>>>>>>> (In the case of JMenuBar, it makes them come through as key >>>>>>>>>>> events, but >>>>>>>>>>> doesn't do anything special to process these events, which >>>>>>>>>>> is why they >>>>>>>>>>> get discarded.) >>>>>>>>>> >>>>>>>>>> That is right, though it doesn't directly relate to the issue >>>>>>>>>> we're talking about =) >>>>>>>>>> >>>>>>>>>>> Your description above, though, seems to suggest that it is >>>>>>>>>>> generally >>>>>>>>>>> undesirable for the JMenuBar to be given the focus, as all the >>>>>>>>>>> Swing-aware focus traversal policies make a point of not >>>>>>>>>>> giving focus to >>>>>>>>>>> JMenuBar items. >>>>>>>>>>> >>>>>>>>>>> If this is so, then wouldn't it make sense to call >>>>>>>>>>> setFocusable(false) >>>>>>>>>>> from its constructor (too), to ensure it doesn't get focus ? >>>>>>>>>>> >>>>>>>>>>> Or, to put it another way, could you explain a little of the >>>>>>>>>>> reasoning >>>>>>>>>>> or scenario behind why it is desirable for JMenuBar items to be >>>>>>>>>>> generally focusable, even though they aren't >>>>>>>>>>> focus-traversable ? >>>>>>>>>>> >>>>>>>>>>> I think such an explanation would be really helpful in >>>>>>>>>>> clearing up my >>>>>>>>>>> confusion on this point. >>>>>>>>>>> >>>>>>>>>>> Thanks, Neil >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Well, I suspect that the core of the problem is that adding >>>>>>>>>> JMenuBar as JComponent to a swing >>>>>>>>>> container doesn't make much sense. Though it is not directly >>>>>>>>>> prohibited, doing so may cause >>>>>>>>>> side effects like the one you've discovered. When JMenuBar is >>>>>>>>>> set properly onto a JFrame its focus >>>>>>>>>> is managed by JRootPane and its focusability just isn't taken >>>>>>>>>> into account. That's may be the reason >>>>>>>>>> it's not declared unfocusable. Honestly, I can't tell you >>>>>>>>>> exactly. >>>>>>>>>> >>>>>>>>>> If you do it, you probably won't make any harm, but I >>>>>>>>>> personally don't think this is a vital fix >>>>>>>>>> (unless you have a good use case of the scenario you've >>>>>>>>>> provided). Anyway, this is a swing question >>>>>>>>>> (I'm, as an AWT dev member, leaving the decision to swing guys). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Anton. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From peter.brunet at oracle.com Wed Dec 12 16:45:50 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 12 Dec 2012 10:45:50 -0600 Subject: [Accessibility]Focus unable to traverse in the menubar In-Reply-To: <50C88FB6.20103@oracle.com> References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill> <4E8C7A0B.7060006@oracle.com> <4E92EB65.6080605@oracle.com> <1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com> <4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com> <4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com> <5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com> <5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com> <50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com> Message-ID: <50C8B4BE.9000104@oracle.com> Hi, The word Accessibility in the subject line caught my eye when cleaning out my inbox this morning. I couldn't determine the essence of the issue in the history below but wanted to throw out one comment in case it's useful. If the comment isn't useful then please ignore. I don't know the specified expected UI behavior of a Swing menu bar but if I were a blind user using keyboard navigation I'd expect to be able to press Alt + some letter to get to the menu bar and then use the arrow keys to explore the entire menu and then alt or esc twice to get out of the menu. This is the behavior I see when using Notepad on Win. I have seen some apps, e.g. Visual Studio 2010, that allow tab navigation through the menu bar drop downs but I wouldn't expect it. -Pete On 12/12/12 8:07 AM, Alexander Scherbatiy wrote: > On 12/10/2012 11:08 AM, Frank Ding wrote: >> Hi Pavel, >> I think pointing out the special behavior in javadoc makes more >> sense. Could you please take a look at my draft below? >> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01 > I think that It has more sense to point this special behavior in > the JMenuBar class itself. > It looks more naturally to read about the JMenuBar focus > traversal behaviour from the JMenuBar javadoc. > >> Note that I think in the sentence "By default, methods of this >> class with return a Component only if it is" it should be "will" not >> "with", shouldn't it? > Thank you that you point it out. Could you create an issue on it? > > Thanks, > Alexandr. >> >> Expecting your reply. >> Best regards, >> Frank >> >> On 10/8/2012 7:47 PM, pavel porvatov wrote: >>> Hi Jonathan, >>>> Hi Pavel, >>>> >>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote: >>>>> Hi Jonathan, >>>>>> Hi Pavel, >>>>>> >>>>>> I've filed bug 7198816 for this problem, >>>>>> >>>>>> Regards, Pavel >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816 >>>>> This bug was not ported to jira, so I created another bug: >>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326 >>>> >>>> Thanks for porting, but I have trouble with opening that link. >>> Sorry, use the following link: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326 >>> >>> but the bug is not available yet... It contains the same description >>> as the original bug. >>> >>>> Any comments on the patch? >>> The fix looks dangerous for me. After the fix the >>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar (when >>> ContainerOrderFocusTraversalPolicy is used) - it ignores this >>> property... >>> >>> Regards, Pavel >>>> >>>> best regards >>>> Jonathan >>>> >>>>> >>>>> Regards, Pavel >>>>>> >>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote: >>>>>>> Hi Jing, >>>>>>>> Thanks Pavel, >>>>>>>> >>>>>>>> It seems fine to me, if no other suggestions/opinions, I >>>>>>>> guess we can move on with this? >>>>>>> Yes, we can. Could you please file a bug for the problem as well? >>>>>>> >>>>>>> Thanks, Pavel >>>>>>>> >>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote: >>>>>>>>> Hi Jing, >>>>>>>>>> >>>>>>>>>> Hello Anton, >>>>>>>>>> >>>>>>>>>> Thanks for the review. I am still trying to figure out >>>>>>>>>> some real case and provide more detail the customer may fail. >>>>>>>>>> Anyway, I agree we'd better update the java spec to make >>>>>>>>>> it clear for the customers. I'd like to know if anyone can >>>>>>>>>> help with that? >>>>>>>>> I'm not sure that javadoc changing is a good decision in this >>>>>>>>> case. ContainerOrderFocusTraversalPolicy is designed for AWT, >>>>>>>>> but I don't know why that policy cannot be used for Swing >>>>>>>>> components as well. I see several problems: >>>>>>>>> 1. We cannot change javadoc of >>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward >>>>>>>>> compatibility >>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) from >>>>>>>>> the JMenuBar#JMenuBar() constructor because of backward >>>>>>>>> compatibility >>>>>>>>> >>>>>>>>> May be the best decision is to specify, that JMenuBar creates >>>>>>>>> menu with the focusTraversalKeysEnabled = false >>>>>> >>>>>> Did you mean that for the new menu >>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does not >>>>>> seem to work for this problem. >>>>>> >>>>>> if my understanding is incorrect, please help to fix me. >>>>>> >>>>>>>>> >>>>>>>>> Regards, Pavel >>>>>>>>>> >>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote: >>>>>>>>>>> Hi Neil, >>>>>>>>>>> >>>>>>>>>>> On 10/10/2011 7:01 PM, Neil Richards wrote: >>>>>>>>>>>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote: >>>>>>>>>>>>> Hi Neil and Jing, >>>>>>>>>>>>> I'm afraid that it's wrong to use >>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy >>>>>>>>>>>>> for swing components. This policy is designed for AWT. >>>>>>>>>>>>> JMenuBar calls setFocusTraversalKeysEnabled(false) in its >>>>>>>>>>>>> ctor which >>>>>>>>>>>>> means that it "swallows" focus traversal keys (like >>>>>>>>>>>>> TAB/SHIFT-TAB >>>>>>>>>>>>> etc.) >>>>>>>>>>>>> and so it can't be a member of a focus traversal chain. >>>>>>>>>>>>> Swing's >>>>>>>>>>>>> default traversal policy (LayoutFocusTraversalPolicy) >>>>>>>>>>>>> excludes >>>>>>>>>>>>> JMenuBar >>>>>>>>>>>>> from a focus traversal cycle. >>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy is >>>>>>>>>>>>> not "aware" about JMenuBar and so it allows it. >>>>>>>>>>>>> >>>>>>>>>>>>> So, either a default Swing policy should be used, or a >>>>>>>>>>>>> custom policy. >>>>>>>>>>>>> At worst, ContainerOrderFocusTraversalPolicy should be >>>>>>>>>>>>> overriden >>>>>>>>>>>>> to exclude JMenuBar from a cycle (override its >>>>>>>>>>>>> accept(Component) >>>>>>>>>>>>> method). >>>>>> >>>>>> I agree that backward compatibility should not be broken by the >>>>>> fix, so here's a patch from me for the worst case, could you >>>>>> please help to take a look? >>>>>> >>>>>> http://cr.openjdk.java.net/~luchsh/7198816/ >>>>>> >>>>>> Thanks >>>>>> Jonathan >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Anton. >>>>>>>>>>>> Hi Anton, >>>>>>>>>>>> Thanks for reviewing the suggestion, and for your insights >>>>>>>>>>>> into this >>>>>>>>>>>> scenario. >>>>>>>>>>>> >>>>>>>>>>>> > From the Javadoc, it seems that >>>>>>>>>>>> setFocusTraversalKeysEnabled() is mainly >>>>>>>>>>>> concerned with choosing whether focus traversal key presses >>>>>>>>>>>> (normally >>>>>>>>>>>> TAB and SHIFT-TAB) are processed "automatically" (when >>>>>>>>>>>> 'true') or are >>>>>>>>>>>> delivered to the Component as key events (for the >>>>>>>>>>>> component's code to >>>>>>>>>>>> process "manually"). >>>>>>>>>>>> >>>>>>>>>>>> (In the case of JMenuBar, it makes them come through as key >>>>>>>>>>>> events, but >>>>>>>>>>>> doesn't do anything special to process these events, which >>>>>>>>>>>> is why they >>>>>>>>>>>> get discarded.) >>>>>>>>>>> >>>>>>>>>>> That is right, though it doesn't directly relate to the >>>>>>>>>>> issue we're talking about =) >>>>>>>>>>> >>>>>>>>>>>> Your description above, though, seems to suggest that it is >>>>>>>>>>>> generally >>>>>>>>>>>> undesirable for the JMenuBar to be given the focus, as all the >>>>>>>>>>>> Swing-aware focus traversal policies make a point of not >>>>>>>>>>>> giving focus to >>>>>>>>>>>> JMenuBar items. >>>>>>>>>>>> >>>>>>>>>>>> If this is so, then wouldn't it make sense to call >>>>>>>>>>>> setFocusable(false) >>>>>>>>>>>> from its constructor (too), to ensure it doesn't get focus ? >>>>>>>>>>>> >>>>>>>>>>>> Or, to put it another way, could you explain a little of >>>>>>>>>>>> the reasoning >>>>>>>>>>>> or scenario behind why it is desirable for JMenuBar items >>>>>>>>>>>> to be >>>>>>>>>>>> generally focusable, even though they aren't >>>>>>>>>>>> focus-traversable ? >>>>>>>>>>>> >>>>>>>>>>>> I think such an explanation would be really helpful in >>>>>>>>>>>> clearing up my >>>>>>>>>>>> confusion on this point. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Neil >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Well, I suspect that the core of the problem is that adding >>>>>>>>>>> JMenuBar as JComponent to a swing >>>>>>>>>>> container doesn't make much sense. Though it is not directly >>>>>>>>>>> prohibited, doing so may cause >>>>>>>>>>> side effects like the one you've discovered. When JMenuBar >>>>>>>>>>> is set properly onto a JFrame its focus >>>>>>>>>>> is managed by JRootPane and its focusability just isn't >>>>>>>>>>> taken into account. That's may be the reason >>>>>>>>>>> it's not declared unfocusable. Honestly, I can't tell you >>>>>>>>>>> exactly. >>>>>>>>>>> >>>>>>>>>>> If you do it, you probably won't make any harm, but I >>>>>>>>>>> personally don't think this is a vital fix >>>>>>>>>>> (unless you have a good use case of the scenario you've >>>>>>>>>>> provided). Anyway, this is a swing question >>>>>>>>>>> (I'm, as an AWT dev member, leaving the decision to swing >>>>>>>>>>> guys). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Anton. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From dingxmin at linux.vnet.ibm.com Thu Dec 13 09:01:54 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 13 Dec 2012 17:01:54 +0800 Subject: [Accessibility]Focus unable to traverse in the menubar In-Reply-To: <50C88FB6.20103@oracle.com> References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill> <4E8C7A0B.7060006@oracle.com> <4E92EB65.6080605@oracle.com> <1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com> <4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com> <4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com> <5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com> <5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com> <50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com> Message-ID: <50C99982.4040307@linux.vnet.ibm.com> Hi Alexandr, I made another change according to your comment @ http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please review it. I submitted a bug whose internal review ID is 2401619 about one wording mistake in ContainerOrderFocusTraversalPolicy. But since the bug system transition, newly submitted bugs cannot pass review and get publicly available. Can you help me to have somebody review it? Thanks and Best regards, Frank On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote: > On 12/10/2012 11:08 AM, Frank Ding wrote: >> Hi Pavel, >> I think pointing out the special behavior in javadoc makes more >> sense. Could you please take a look at my draft below? >> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01 > I think that It has more sense to point this special behavior in > the JMenuBar class itself. > It looks more naturally to read about the JMenuBar focus > traversal behaviour from the JMenuBar javadoc. > >> Note that I think in the sentence "By default, methods of this >> class with return a Component only if it is" it should be "will" not >> "with", shouldn't it? > Thank you that you point it out. Could you create an issue on it? > > Thanks, > Alexandr. >> >> Expecting your reply. >> Best regards, >> Frank >> >> On 10/8/2012 7:47 PM, pavel porvatov wrote: >>> Hi Jonathan, >>>> Hi Pavel, >>>> >>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote: >>>>> Hi Jonathan, >>>>>> Hi Pavel, >>>>>> >>>>>> I've filed bug 7198816 for this problem, >>>>>> >>>>>> Regards, Pavel >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816 >>>>> This bug was not ported to jira, so I created another bug: >>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326 >>>> >>>> Thanks for porting, but I have trouble with opening that link. >>> Sorry, use the following link: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326 >>> >>> but the bug is not available yet... It contains the same description >>> as the original bug. >>> >>>> Any comments on the patch? >>> The fix looks dangerous for me. After the fix the >>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar (when >>> ContainerOrderFocusTraversalPolicy is used) - it ignores this >>> property... >>> >>> Regards, Pavel >>>> >>>> best regards >>>> Jonathan >>>> >>>>> >>>>> Regards, Pavel >>>>>> >>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote: >>>>>>> Hi Jing, >>>>>>>> Thanks Pavel, >>>>>>>> >>>>>>>> It seems fine to me, if no other suggestions/opinions, I >>>>>>>> guess we can move on with this? >>>>>>> Yes, we can. Could you please file a bug for the problem as well? >>>>>>> >>>>>>> Thanks, Pavel >>>>>>>> >>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote: >>>>>>>>> Hi Jing, >>>>>>>>>> >>>>>>>>>> Hello Anton, >>>>>>>>>> >>>>>>>>>> Thanks for the review. I am still trying to figure out >>>>>>>>>> some real case and provide more detail the customer may fail. >>>>>>>>>> Anyway, I agree we'd better update the java spec to make >>>>>>>>>> it clear for the customers. I'd like to know if anyone can >>>>>>>>>> help with that? >>>>>>>>> I'm not sure that javadoc changing is a good decision in this >>>>>>>>> case. ContainerOrderFocusTraversalPolicy is designed for AWT, >>>>>>>>> but I don't know why that policy cannot be used for Swing >>>>>>>>> components as well. I see several problems: >>>>>>>>> 1. We cannot change javadoc of >>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward >>>>>>>>> compatibility >>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) from >>>>>>>>> the JMenuBar#JMenuBar() constructor because of backward >>>>>>>>> compatibility >>>>>>>>> >>>>>>>>> May be the best decision is to specify, that JMenuBar creates >>>>>>>>> menu with the focusTraversalKeysEnabled = false >>>>>> >>>>>> Did you mean that for the new menu >>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does not >>>>>> seem to work for this problem. >>>>>> >>>>>> if my understanding is incorrect, please help to fix me. >>>>>> >>>>>>>>> >>>>>>>>> Regards, Pavel >>>>>>>>>> >>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote: >>>>>>>>>>> Hi Neil, >>>>>>>>>>> >>>>>>>>>>> On 10/10/2011 7:01 PM, Neil Richards wrote: >>>>>>>>>>>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote: >>>>>>>>>>>>> Hi Neil and Jing, >>>>>>>>>>>>> I'm afraid that it's wrong to use >>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy >>>>>>>>>>>>> for swing components. This policy is designed for AWT. >>>>>>>>>>>>> JMenuBar calls setFocusTraversalKeysEnabled(false) in its >>>>>>>>>>>>> ctor which >>>>>>>>>>>>> means that it "swallows" focus traversal keys (like >>>>>>>>>>>>> TAB/SHIFT-TAB >>>>>>>>>>>>> etc.) >>>>>>>>>>>>> and so it can't be a member of a focus traversal chain. >>>>>>>>>>>>> Swing's >>>>>>>>>>>>> default traversal policy (LayoutFocusTraversalPolicy) >>>>>>>>>>>>> excludes >>>>>>>>>>>>> JMenuBar >>>>>>>>>>>>> from a focus traversal cycle. >>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy is >>>>>>>>>>>>> not "aware" about JMenuBar and so it allows it. >>>>>>>>>>>>> >>>>>>>>>>>>> So, either a default Swing policy should be used, or a >>>>>>>>>>>>> custom policy. >>>>>>>>>>>>> At worst, ContainerOrderFocusTraversalPolicy should be >>>>>>>>>>>>> overriden >>>>>>>>>>>>> to exclude JMenuBar from a cycle (override its >>>>>>>>>>>>> accept(Component) >>>>>>>>>>>>> method). >>>>>> >>>>>> I agree that backward compatibility should not be broken by the >>>>>> fix, so here's a patch from me for the worst case, could you >>>>>> please help to take a look? >>>>>> >>>>>> http://cr.openjdk.java.net/~luchsh/7198816/ >>>>>> >>>>>> Thanks >>>>>> Jonathan >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Anton. >>>>>>>>>>>> Hi Anton, >>>>>>>>>>>> Thanks for reviewing the suggestion, and for your insights >>>>>>>>>>>> into this >>>>>>>>>>>> scenario. >>>>>>>>>>>> >>>>>>>>>>>> > From the Javadoc, it seems that >>>>>>>>>>>> setFocusTraversalKeysEnabled() is mainly >>>>>>>>>>>> concerned with choosing whether focus traversal key presses >>>>>>>>>>>> (normally >>>>>>>>>>>> TAB and SHIFT-TAB) are processed "automatically" (when >>>>>>>>>>>> 'true') or are >>>>>>>>>>>> delivered to the Component as key events (for the >>>>>>>>>>>> component's code to >>>>>>>>>>>> process "manually"). >>>>>>>>>>>> >>>>>>>>>>>> (In the case of JMenuBar, it makes them come through as key >>>>>>>>>>>> events, but >>>>>>>>>>>> doesn't do anything special to process these events, which >>>>>>>>>>>> is why they >>>>>>>>>>>> get discarded.) >>>>>>>>>>> >>>>>>>>>>> That is right, though it doesn't directly relate to the >>>>>>>>>>> issue we're talking about =) >>>>>>>>>>> >>>>>>>>>>>> Your description above, though, seems to suggest that it is >>>>>>>>>>>> generally >>>>>>>>>>>> undesirable for the JMenuBar to be given the focus, as all the >>>>>>>>>>>> Swing-aware focus traversal policies make a point of not >>>>>>>>>>>> giving focus to >>>>>>>>>>>> JMenuBar items. >>>>>>>>>>>> >>>>>>>>>>>> If this is so, then wouldn't it make sense to call >>>>>>>>>>>> setFocusable(false) >>>>>>>>>>>> from its constructor (too), to ensure it doesn't get focus ? >>>>>>>>>>>> >>>>>>>>>>>> Or, to put it another way, could you explain a little of >>>>>>>>>>>> the reasoning >>>>>>>>>>>> or scenario behind why it is desirable for JMenuBar items >>>>>>>>>>>> to be >>>>>>>>>>>> generally focusable, even though they aren't >>>>>>>>>>>> focus-traversable ? >>>>>>>>>>>> >>>>>>>>>>>> I think such an explanation would be really helpful in >>>>>>>>>>>> clearing up my >>>>>>>>>>>> confusion on this point. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Neil >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Well, I suspect that the core of the problem is that adding >>>>>>>>>>> JMenuBar as JComponent to a swing >>>>>>>>>>> container doesn't make much sense. Though it is not directly >>>>>>>>>>> prohibited, doing so may cause >>>>>>>>>>> side effects like the one you've discovered. When JMenuBar >>>>>>>>>>> is set properly onto a JFrame its focus >>>>>>>>>>> is managed by JRootPane and its focusability just isn't >>>>>>>>>>> taken into account. That's may be the reason >>>>>>>>>>> it's not declared unfocusable. Honestly, I can't tell you >>>>>>>>>>> exactly. >>>>>>>>>>> >>>>>>>>>>> If you do it, you probably won't make any harm, but I >>>>>>>>>>> personally don't think this is a vital fix >>>>>>>>>>> (unless you have a good use case of the scenario you've >>>>>>>>>>> provided). Anyway, this is a swing question >>>>>>>>>>> (I'm, as an AWT dev member, leaving the decision to swing >>>>>>>>>>> guys). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Anton. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Thu Dec 13 10:10:21 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 13 Dec 2012 14:10:21 +0400 Subject: [8] Review request for JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction In-Reply-To: <50C748F2.7090804@oracle.com> References: <50C5FFE2.4070906@oracle.com> <50C722EA.9050807@oracle.com> <50C748F2.7090804@oracle.com> Message-ID: <50C9A98D.7010305@oracle.com> The fix looks good for me. Thanks, Alexandr. On 12/11/2012 6:53 PM, vera akulova wrote: > Hello Sergey, > > Thanks for your reply, I created new webrev: > http://cr.openjdk.java.net/~kshefov/6757986/webrev.01 > (typo near tag @test fixed, real coordinates are used to get color now) > > Thanks, > Vera > > On 11.12.2012 16:11, Sergey Bylokhov wrote: >> Hello, Vera. >> setBounds() can be ignored by native system, I suggest to fetch real >> coordinates from the window instead of 50,50. >> Also bug5066752 is a typo in 24 @test bug5066752 ? >> >> 10.12.2012 19:29, vera akulova wrote: >>> Hello, >>> >>> Please review a fix for the issue: >>> JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java >>> needs correction >>> >>> The webrev is http://cr.openjdk.java.net/~kshefov/6757986/webrev.00/ >>> >>> The manual test from closed repo was automated. Fixed test works >>> fine on windows, linux, solaris and macos. >>> >>> Thanks, >>> Vera. >> >> From alexandr.scherbatiy at oracle.com Thu Dec 13 10:14:14 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 13 Dec 2012 14:14:14 +0400 Subject: [8] Review request for JDK-7132383: [macosx] bug6596966.java should be adapted for Mac In-Reply-To: <50C746BF.1020805@oracle.com> References: <50C746BF.1020805@oracle.com> Message-ID: <50C9AA76.9040606@oracle.com> The fix looks good for me. Thanks, Alexandr. On 12/11/2012 6:44 PM, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-7132383: [macosx] bug6596966.java should be adapted for Mac > > The webrev is http://cr.openjdk.java.net/~kshefov/7132383/webrev.00/ > > Ctrl-Alt-Mnemonic is used now for Mac instead of Alt-Mnemonic. > Fixed test works fine on windows, linux, solaris and macos. > > Thanks, > Vera. From alexandr.scherbatiy at oracle.com Thu Dec 13 10:30:34 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 13 Dec 2012 14:30:34 +0400 Subject: [8] Review request for JDK-7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS In-Reply-To: <50C7575C.3030806@oracle.com> References: <50C7575C.3030806@oracle.com> Message-ID: <50C9AE4A.20805@oracle.com> The try/catch block in the init method just prints the caught exception. The jtreg treats that as test passes. It is better to rethrow the exception as a RuntimeException. Thanks, Alexandr. On 12/11/2012 7:55 PM, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-7133146: [macosx] > closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS > > The webrev is http://cr.openjdk.java.net/~kshefov/7133146/webrev.00/ > > Metal L&F is used now. Fixed test works fine on windows, linux, > solaris and macos. > > Thanks, > Vera. From alexandr.scherbatiy at oracle.com Thu Dec 13 10:39:15 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 13 Dec 2012 14:39:15 +0400 Subject: [8] Review request for JDK-7132385: [macosx] IconifyTest of RepaintManager could use some delay In-Reply-To: <50C764B6.5090305@oracle.com> References: <50C764B6.5090305@oracle.com> Message-ID: <50C9B053.70205@oracle.com> The fix looks good for me. Thanks, Alexandr. On 12/11/2012 8:52 PM, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-7132385: [macosx] IconifyTest of RepaintManager could use some > delay > > The webrev is http://cr.openjdk.java.net/~kshefov/7132385/webrev.00/ > > Added realSync(). Fixed test works fine on windows, linux, solaris and > macos. > > Thanks, > Vera. From Sergey.Bylokhov at oracle.com Thu Dec 13 18:31:21 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 13 Dec 2012 22:31:21 +0400 Subject: [8] Review request for JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction In-Reply-To: <50C748F2.7090804@oracle.com> References: <50C5FFE2.4070906@oracle.com> <50C722EA.9050807@oracle.com> <50C748F2.7090804@oracle.com> Message-ID: <50CA1EF9.8080107@oracle.com> Hi, Vera. Fix looks good. 11.12.2012 18:53, vera akulova wrote: > Hello Sergey, > > Thanks for your reply, I created new webrev: > http://cr.openjdk.java.net/~kshefov/6757986/webrev.01 > (typo near tag @test fixed, real coordinates are used to get color now) > > Thanks, > Vera > > On 11.12.2012 16:11, Sergey Bylokhov wrote: >> Hello, Vera. >> setBounds() can be ignored by native system, I suggest to fetch real >> coordinates from the window instead of 50,50. >> Also bug5066752 is a typo in 24 @test bug5066752 ? >> >> 10.12.2012 19:29, vera akulova wrote: >>> Hello, >>> >>> Please review a fix for the issue: >>> JDK-6757986: javax/swing/JInternalFrame/5066752/bug5066752.java >>> needs correction >>> >>> The webrev is http://cr.openjdk.java.net/~kshefov/6757986/webrev.00/ >>> >>> The manual test from closed repo was automated. Fixed test works >>> fine on windows, linux, solaris and macos. >>> >>> Thanks, >>> Vera. >> >> -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Dec 14 12:32:35 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 14 Dec 2012 16:32:35 +0400 Subject: [8] Review request for 8005019 JTable passes row index instead of length when inserts selection interval Message-ID: <50CB1C63.3070201@oracle.com> Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005019 webrev: http://cr.openjdk.java.net/~alexsch/8005019/webrev.00 Fixed type in the modelSelection.insertIndexInterval() method call which requires length in the second argument instead of endModelIndex. Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Fri Dec 14 12:40:22 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 14 Dec 2012 16:40:22 +0400 Subject: [Accessibility]Focus unable to traverse in the menubar In-Reply-To: <50C99982.4040307@linux.vnet.ibm.com> References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill> <4E8C7A0B.7060006@oracle.com> <4E92EB65.6080605@oracle.com> <1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com> <4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com> <4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com> <5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com> <5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com> <50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com> <50C99982.4040307@linux.vnet.ibm.com> Message-ID: <50CB1E36.6020000@oracle.com> On 12/13/2012 1:01 PM, Frank Ding wrote: > Hi Alexandr, > I made another change according to your comment @ > http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please > review it. > I submitted a bug whose internal review ID is 2401619 about one > wording mistake in ContainerOrderFocusTraversalPolicy. But since the > bug system transition, newly submitted bugs cannot pass review and get > publicly available. Can you help me to have somebody review it? I resent the both issues 8000326 and 2401619 to the JDK doc team to review. Thanks, Alexandr. > > Thanks and Best regards, > Frank > > On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote: >> On 12/10/2012 11:08 AM, Frank Ding wrote: >>> Hi Pavel, >>> I think pointing out the special behavior in javadoc makes more >>> sense. Could you please take a look at my draft below? >>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01 >> I think that It has more sense to point this special behavior in >> the JMenuBar class itself. >> It looks more naturally to read about the JMenuBar focus >> traversal behaviour from the JMenuBar javadoc. >> >>> Note that I think in the sentence "By default, methods of this >>> class with return a Component only if it is" it should be "will" not >>> "with", shouldn't it? >> Thank you that you point it out. Could you create an issue on it? >> >> Thanks, >> Alexandr. >>> >>> Expecting your reply. >>> Best regards, >>> Frank >>> >>> On 10/8/2012 7:47 PM, pavel porvatov wrote: >>>> Hi Jonathan, >>>>> Hi Pavel, >>>>> >>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote: >>>>>> Hi Jonathan, >>>>>>> Hi Pavel, >>>>>>> >>>>>>> I've filed bug 7198816 for this problem, >>>>>>> >>>>>>> Regards, Pavel >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816 >>>>>> This bug was not ported to jira, so I created another bug: >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326 >>>>> >>>>> Thanks for porting, but I have trouble with opening that link. >>>> Sorry, use the following link: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326 >>>> >>>> but the bug is not available yet... It contains the same >>>> description as the original bug. >>>> >>>>> Any comments on the patch? >>>> The fix looks dangerous for me. After the fix the >>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar (when >>>> ContainerOrderFocusTraversalPolicy is used) - it ignores this >>>> property... >>>> >>>> Regards, Pavel >>>>> >>>>> best regards >>>>> Jonathan >>>>> >>>>>> >>>>>> Regards, Pavel >>>>>>> >>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote: >>>>>>>> Hi Jing, >>>>>>>>> Thanks Pavel, >>>>>>>>> >>>>>>>>> It seems fine to me, if no other suggestions/opinions, I >>>>>>>>> guess we can move on with this? >>>>>>>> Yes, we can. Could you please file a bug for the problem as well? >>>>>>>> >>>>>>>> Thanks, Pavel >>>>>>>>> >>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote: >>>>>>>>>> Hi Jing, >>>>>>>>>>> >>>>>>>>>>> Hello Anton, >>>>>>>>>>> >>>>>>>>>>> Thanks for the review. I am still trying to figure out >>>>>>>>>>> some real case and provide more detail the customer may fail. >>>>>>>>>>> Anyway, I agree we'd better update the java spec to make >>>>>>>>>>> it clear for the customers. I'd like to know if anyone can >>>>>>>>>>> help with that? >>>>>>>>>> I'm not sure that javadoc changing is a good decision in this >>>>>>>>>> case. ContainerOrderFocusTraversalPolicy is designed for AWT, >>>>>>>>>> but I don't know why that policy cannot be used for Swing >>>>>>>>>> components as well. I see several problems: >>>>>>>>>> 1. We cannot change javadoc of >>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward >>>>>>>>>> compatibility >>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) from >>>>>>>>>> the JMenuBar#JMenuBar() constructor because of backward >>>>>>>>>> compatibility >>>>>>>>>> >>>>>>>>>> May be the best decision is to specify, that JMenuBar creates >>>>>>>>>> menu with the focusTraversalKeysEnabled = false >>>>>>> >>>>>>> Did you mean that for the new menu >>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does >>>>>>> not seem to work for this problem. >>>>>>> >>>>>>> if my understanding is incorrect, please help to fix me. >>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, Pavel >>>>>>>>>>> >>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote: >>>>>>>>>>>> Hi Neil, >>>>>>>>>>>> >>>>>>>>>>>> On 10/10/2011 7:01 PM, Neil Richards wrote: >>>>>>>>>>>>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote: >>>>>>>>>>>>>> Hi Neil and Jing, >>>>>>>>>>>>>> I'm afraid that it's wrong to use >>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy >>>>>>>>>>>>>> for swing components. This policy is designed for AWT. >>>>>>>>>>>>>> JMenuBar calls setFocusTraversalKeysEnabled(false) in its >>>>>>>>>>>>>> ctor which >>>>>>>>>>>>>> means that it "swallows" focus traversal keys (like >>>>>>>>>>>>>> TAB/SHIFT-TAB >>>>>>>>>>>>>> etc.) >>>>>>>>>>>>>> and so it can't be a member of a focus traversal chain. >>>>>>>>>>>>>> Swing's >>>>>>>>>>>>>> default traversal policy (LayoutFocusTraversalPolicy) >>>>>>>>>>>>>> excludes >>>>>>>>>>>>>> JMenuBar >>>>>>>>>>>>>> from a focus traversal cycle. >>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy is >>>>>>>>>>>>>> not "aware" about JMenuBar and so it allows it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, either a default Swing policy should be used, or a >>>>>>>>>>>>>> custom policy. >>>>>>>>>>>>>> At worst, ContainerOrderFocusTraversalPolicy should be >>>>>>>>>>>>>> overriden >>>>>>>>>>>>>> to exclude JMenuBar from a cycle (override its >>>>>>>>>>>>>> accept(Component) >>>>>>>>>>>>>> method). >>>>>>> >>>>>>> I agree that backward compatibility should not be broken by the >>>>>>> fix, so here's a patch from me for the worst case, could you >>>>>>> please help to take a look? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/ >>>>>>> >>>>>>> Thanks >>>>>>> Jonathan >>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Anton. >>>>>>>>>>>>> Hi Anton, >>>>>>>>>>>>> Thanks for reviewing the suggestion, and for your insights >>>>>>>>>>>>> into this >>>>>>>>>>>>> scenario. >>>>>>>>>>>>> >>>>>>>>>>>>> > From the Javadoc, it seems that >>>>>>>>>>>>> setFocusTraversalKeysEnabled() is mainly >>>>>>>>>>>>> concerned with choosing whether focus traversal key >>>>>>>>>>>>> presses (normally >>>>>>>>>>>>> TAB and SHIFT-TAB) are processed "automatically" (when >>>>>>>>>>>>> 'true') or are >>>>>>>>>>>>> delivered to the Component as key events (for the >>>>>>>>>>>>> component's code to >>>>>>>>>>>>> process "manually"). >>>>>>>>>>>>> >>>>>>>>>>>>> (In the case of JMenuBar, it makes them come through as >>>>>>>>>>>>> key events, but >>>>>>>>>>>>> doesn't do anything special to process these events, which >>>>>>>>>>>>> is why they >>>>>>>>>>>>> get discarded.) >>>>>>>>>>>> >>>>>>>>>>>> That is right, though it doesn't directly relate to the >>>>>>>>>>>> issue we're talking about =) >>>>>>>>>>>> >>>>>>>>>>>>> Your description above, though, seems to suggest that it >>>>>>>>>>>>> is generally >>>>>>>>>>>>> undesirable for the JMenuBar to be given the focus, as all >>>>>>>>>>>>> the >>>>>>>>>>>>> Swing-aware focus traversal policies make a point of not >>>>>>>>>>>>> giving focus to >>>>>>>>>>>>> JMenuBar items. >>>>>>>>>>>>> >>>>>>>>>>>>> If this is so, then wouldn't it make sense to call >>>>>>>>>>>>> setFocusable(false) >>>>>>>>>>>>> from its constructor (too), to ensure it doesn't get focus ? >>>>>>>>>>>>> >>>>>>>>>>>>> Or, to put it another way, could you explain a little of >>>>>>>>>>>>> the reasoning >>>>>>>>>>>>> or scenario behind why it is desirable for JMenuBar items >>>>>>>>>>>>> to be >>>>>>>>>>>>> generally focusable, even though they aren't >>>>>>>>>>>>> focus-traversable ? >>>>>>>>>>>>> >>>>>>>>>>>>> I think such an explanation would be really helpful in >>>>>>>>>>>>> clearing up my >>>>>>>>>>>>> confusion on this point. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, Neil >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Well, I suspect that the core of the problem is that adding >>>>>>>>>>>> JMenuBar as JComponent to a swing >>>>>>>>>>>> container doesn't make much sense. Though it is not >>>>>>>>>>>> directly prohibited, doing so may cause >>>>>>>>>>>> side effects like the one you've discovered. When JMenuBar >>>>>>>>>>>> is set properly onto a JFrame its focus >>>>>>>>>>>> is managed by JRootPane and its focusability just isn't >>>>>>>>>>>> taken into account. That's may be the reason >>>>>>>>>>>> it's not declared unfocusable. Honestly, I can't tell you >>>>>>>>>>>> exactly. >>>>>>>>>>>> >>>>>>>>>>>> If you do it, you probably won't make any harm, but I >>>>>>>>>>>> personally don't think this is a vital fix >>>>>>>>>>>> (unless you have a good use case of the scenario you've >>>>>>>>>>>> provided). Anyway, this is a swing question >>>>>>>>>>>> (I'm, as an AWT dev member, leaving the decision to swing >>>>>>>>>>>> guys). >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Anton. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Fri Dec 14 14:15:35 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 14 Dec 2012 18:15:35 +0400 Subject: [8] Review request for 8005019 JTable passes row index instead of length when inserts selection interval In-Reply-To: <50CB1C63.3070201@oracle.com> References: <50CB1C63.3070201@oracle.com> Message-ID: <50CB3487.1030209@oracle.com> Hi, Alexander. Fix looks good. 14.12.2012 16:32, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005019 > webrev: http://cr.openjdk.java.net/~alexsch/8005019/webrev.00 > > Fixed type in the modelSelection.insertIndexInterval() method call > which requires length in the second argument instead of endModelIndex. > > Thanks, > Alexandr. > -- Best regards, Sergey. From denis.fokin at oracle.com Mon Dec 17 11:29:09 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Mon, 17 Dec 2012 15:29:09 +0400 Subject: [8] Review request for 8005019 JTable passes row index instead of length when inserts selection interval In-Reply-To: <50CB1C63.3070201@oracle.com> References: <50CB1C63.3070201@oracle.com> Message-ID: <50CF0205.6020009@oracle.com> Looks good. Thank you, Denis. On 12/14/2012 4:32 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005019 > webrev: http://cr.openjdk.java.net/~alexsch/8005019/webrev.00 > > Fixed type in the modelSelection.insertIndexInterval() method call which > requires length in the second argument instead of endModelIndex. > > Thanks, > Alexandr. > From dingxmin at linux.vnet.ibm.com Tue Dec 18 06:36:02 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Tue, 18 Dec 2012 14:36:02 +0800 Subject: [Accessibility]Focus unable to traverse in the menubar In-Reply-To: <50CB1E36.6020000@oracle.com> References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill> <4E8C7A0B.7060006@oracle.com> <4E92EB65.6080605@oracle.com> <1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com> <4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com> <4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com> <5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com> <5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com> <50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com> <50C99982.4040307@linux.vnet.ibm.com> <50CB1E36.6020000@oracle.com> Message-ID: <50D00ED2.4060502@linux.vnet.ibm.com> Thanks, Alexandr. On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote: > On 12/13/2012 1:01 PM, Frank Ding wrote: >> Hi Alexandr, >> I made another change according to your comment @ >> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please >> review it. >> I submitted a bug whose internal review ID is 2401619 about one >> wording mistake in ContainerOrderFocusTraversalPolicy. But since the >> bug system transition, newly submitted bugs cannot pass review and >> get publicly available. Can you help me to have somebody review it? > > I resent the both issues 8000326 and 2401619 to the JDK doc team > to review. > > Thanks, > Alexandr. > >> >> Thanks and Best regards, >> Frank >> >> On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote: >>> On 12/10/2012 11:08 AM, Frank Ding wrote: >>>> Hi Pavel, >>>> I think pointing out the special behavior in javadoc makes more >>>> sense. Could you please take a look at my draft below? >>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01 >>> I think that It has more sense to point this special behavior >>> in the JMenuBar class itself. >>> It looks more naturally to read about the JMenuBar focus >>> traversal behaviour from the JMenuBar javadoc. >>> >>>> Note that I think in the sentence "By default, methods of this >>>> class with return a Component only if it is" it should be "will" >>>> not "with", shouldn't it? >>> Thank you that you point it out. Could you create an issue on it? >>> >>> Thanks, >>> Alexandr. >>>> >>>> Expecting your reply. >>>> Best regards, >>>> Frank >>>> >>>> On 10/8/2012 7:47 PM, pavel porvatov wrote: >>>>> Hi Jonathan, >>>>>> Hi Pavel, >>>>>> >>>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote: >>>>>>> Hi Jonathan, >>>>>>>> Hi Pavel, >>>>>>>> >>>>>>>> I've filed bug 7198816 for this problem, >>>>>>>> >>>>>>>> Regards, Pavel >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816 >>>>>>> This bug was not ported to jira, so I created another bug: >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326 >>>>>> >>>>>> Thanks for porting, but I have trouble with opening that link. >>>>> Sorry, use the following link: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326 >>>>> >>>>> but the bug is not available yet... It contains the same >>>>> description as the original bug. >>>>> >>>>>> Any comments on the patch? >>>>> The fix looks dangerous for me. After the fix the >>>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar >>>>> (when ContainerOrderFocusTraversalPolicy is used) - it ignores >>>>> this property... >>>>> >>>>> Regards, Pavel >>>>>> >>>>>> best regards >>>>>> Jonathan >>>>>> >>>>>>> >>>>>>> Regards, Pavel >>>>>>>> >>>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote: >>>>>>>>> Hi Jing, >>>>>>>>>> Thanks Pavel, >>>>>>>>>> >>>>>>>>>> It seems fine to me, if no other suggestions/opinions, I >>>>>>>>>> guess we can move on with this? >>>>>>>>> Yes, we can. Could you please file a bug for the problem as well? >>>>>>>>> >>>>>>>>> Thanks, Pavel >>>>>>>>>> >>>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote: >>>>>>>>>>> Hi Jing, >>>>>>>>>>>> >>>>>>>>>>>> Hello Anton, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the review. I am still trying to figure out >>>>>>>>>>>> some real case and provide more detail the customer may fail. >>>>>>>>>>>> Anyway, I agree we'd better update the java spec to >>>>>>>>>>>> make it clear for the customers. I'd like to know if anyone >>>>>>>>>>>> can help with that? >>>>>>>>>>> I'm not sure that javadoc changing is a good decision in >>>>>>>>>>> this case. ContainerOrderFocusTraversalPolicy is designed >>>>>>>>>>> for AWT, but I don't know why that policy cannot be used for >>>>>>>>>>> Swing components as well. I see several problems: >>>>>>>>>>> 1. We cannot change javadoc of >>>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward >>>>>>>>>>> compatibility >>>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) from >>>>>>>>>>> the JMenuBar#JMenuBar() constructor because of backward >>>>>>>>>>> compatibility >>>>>>>>>>> >>>>>>>>>>> May be the best decision is to specify, that JMenuBar >>>>>>>>>>> creates menu with the focusTraversalKeysEnabled = false >>>>>>>> >>>>>>>> Did you mean that for the new menu >>>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does >>>>>>>> not seem to work for this problem. >>>>>>>> >>>>>>>> if my understanding is incorrect, please help to fix me. >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, Pavel >>>>>>>>>>>> >>>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote: >>>>>>>>>>>>> Hi Neil, >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/10/2011 7:01 PM, Neil Richards wrote: >>>>>>>>>>>>>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote: >>>>>>>>>>>>>>> Hi Neil and Jing, >>>>>>>>>>>>>>> I'm afraid that it's wrong to use >>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy >>>>>>>>>>>>>>> for swing components. This policy is designed for AWT. >>>>>>>>>>>>>>> JMenuBar calls setFocusTraversalKeysEnabled(false) in >>>>>>>>>>>>>>> its ctor which >>>>>>>>>>>>>>> means that it "swallows" focus traversal keys (like >>>>>>>>>>>>>>> TAB/SHIFT-TAB >>>>>>>>>>>>>>> etc.) >>>>>>>>>>>>>>> and so it can't be a member of a focus traversal chain. >>>>>>>>>>>>>>> Swing's >>>>>>>>>>>>>>> default traversal policy (LayoutFocusTraversalPolicy) >>>>>>>>>>>>>>> excludes >>>>>>>>>>>>>>> JMenuBar >>>>>>>>>>>>>>> from a focus traversal cycle. >>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy is >>>>>>>>>>>>>>> not "aware" about JMenuBar and so it allows it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, either a default Swing policy should be used, or a >>>>>>>>>>>>>>> custom policy. >>>>>>>>>>>>>>> At worst, ContainerOrderFocusTraversalPolicy should be >>>>>>>>>>>>>>> overriden >>>>>>>>>>>>>>> to exclude JMenuBar from a cycle (override its >>>>>>>>>>>>>>> accept(Component) >>>>>>>>>>>>>>> method). >>>>>>>> >>>>>>>> I agree that backward compatibility should not be broken by the >>>>>>>> fix, so here's a patch from me for the worst case, could you >>>>>>>> please help to take a look? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Jonathan >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Anton. >>>>>>>>>>>>>> Hi Anton, >>>>>>>>>>>>>> Thanks for reviewing the suggestion, and for your >>>>>>>>>>>>>> insights into this >>>>>>>>>>>>>> scenario. >>>>>>>>>>>>>> >>>>>>>>>>>>>> > From the Javadoc, it seems that >>>>>>>>>>>>>> setFocusTraversalKeysEnabled() is mainly >>>>>>>>>>>>>> concerned with choosing whether focus traversal key >>>>>>>>>>>>>> presses (normally >>>>>>>>>>>>>> TAB and SHIFT-TAB) are processed "automatically" (when >>>>>>>>>>>>>> 'true') or are >>>>>>>>>>>>>> delivered to the Component as key events (for the >>>>>>>>>>>>>> component's code to >>>>>>>>>>>>>> process "manually"). >>>>>>>>>>>>>> >>>>>>>>>>>>>> (In the case of JMenuBar, it makes them come through as >>>>>>>>>>>>>> key events, but >>>>>>>>>>>>>> doesn't do anything special to process these events, >>>>>>>>>>>>>> which is why they >>>>>>>>>>>>>> get discarded.) >>>>>>>>>>>>> >>>>>>>>>>>>> That is right, though it doesn't directly relate to the >>>>>>>>>>>>> issue we're talking about =) >>>>>>>>>>>>> >>>>>>>>>>>>>> Your description above, though, seems to suggest that it >>>>>>>>>>>>>> is generally >>>>>>>>>>>>>> undesirable for the JMenuBar to be given the focus, as >>>>>>>>>>>>>> all the >>>>>>>>>>>>>> Swing-aware focus traversal policies make a point of not >>>>>>>>>>>>>> giving focus to >>>>>>>>>>>>>> JMenuBar items. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If this is so, then wouldn't it make sense to call >>>>>>>>>>>>>> setFocusable(false) >>>>>>>>>>>>>> from its constructor (too), to ensure it doesn't get focus ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Or, to put it another way, could you explain a little of >>>>>>>>>>>>>> the reasoning >>>>>>>>>>>>>> or scenario behind why it is desirable for JMenuBar items >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> generally focusable, even though they aren't >>>>>>>>>>>>>> focus-traversable ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think such an explanation would be really helpful in >>>>>>>>>>>>>> clearing up my >>>>>>>>>>>>>> confusion on this point. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, Neil >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Well, I suspect that the core of the problem is that >>>>>>>>>>>>> adding JMenuBar as JComponent to a swing >>>>>>>>>>>>> container doesn't make much sense. Though it is not >>>>>>>>>>>>> directly prohibited, doing so may cause >>>>>>>>>>>>> side effects like the one you've discovered. When JMenuBar >>>>>>>>>>>>> is set properly onto a JFrame its focus >>>>>>>>>>>>> is managed by JRootPane and its focusability just isn't >>>>>>>>>>>>> taken into account. That's may be the reason >>>>>>>>>>>>> it's not declared unfocusable. Honestly, I can't tell you >>>>>>>>>>>>> exactly. >>>>>>>>>>>>> >>>>>>>>>>>>> If you do it, you probably won't make any harm, but I >>>>>>>>>>>>> personally don't think this is a vital fix >>>>>>>>>>>>> (unless you have a good use case of the scenario you've >>>>>>>>>>>>> provided). Anyway, this is a swing question >>>>>>>>>>>>> (I'm, as an AWT dev member, leaving the decision to swing >>>>>>>>>>>>> guys). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Anton. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From konstantin.shefov at oracle.com Tue Dec 18 07:20:03 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 18 Dec 2012 11:20:03 +0400 Subject: [8] Review request for 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] In-Reply-To: <50B63EB3.6000703@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> <50B63EB3.6000703@oracle.com> Message-ID: <50D01923.7090805@oracle.com> REMINDER On 28-Nov-12 20:41, Konstantin Shefov wrote: > 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 >>>>>>>>> >>>>>>>> >>>>>> >>>> From konstantin.shefov at oracle.com Tue Dec 18 07:20:29 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 18 Dec 2012 11:20:29 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50B63E2F.40307@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> <50B63E2F.40307@oracle.com> Message-ID: <50D0193D.9050500@oracle.com> REMINDER On 28-Nov-12 20:39, Konstantin Shefov wrote: > 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 yuri.nesterenko at oracle.com Tue Dec 18 08:30:09 2012 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 18 Dec 2012 12:30:09 +0400 Subject: [8] Review request for 7104594 [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default In-Reply-To: <50D0193D.9050500@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> <50B63E2F.40307@oracle.com> <50D0193D.9050500@oracle.com> Message-ID: <50D02991.1070107@oracle.com> Looks OK to me. -yan On 12/18/2012 11:20 AM, Konstantin Shefov wrote: > REMINDER > > On 28-Nov-12 20:39, Konstantin Shefov wrote: >> 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 Tue Dec 18 15:44:59 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 18 Dec 2012 19:44:59 +0400 Subject: [8] Request for approval for CR 8004693 - TEST_BUG: java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java fails In-Reply-To: <50A62B1E.4010607@oracle.com> References: <50A64219.4080409@oracle.com> <50A62B1E.4010607@oracle.com> Message-ID: <50D08F7B.3060106@oracle.com> Hello, Please review a fix for the issue: 8004693 - TEST_BUG: java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java fails The webrev is http://cr.openjdk.java.net/~kshefov/8004693/webrev.00/ This test is broken. The test tells the AWT EventQueue to run the method DefaultPolicyChange_Swing.runTestSwing() (which contains all the actual test code) at a later time (EventQueue.invokeLater(Runnable)). By adding a few printlns to that function, it's easy to see that it starts to run but never finishes. In particular, it never reaches any of the actual test code. First, "((SunToolkit) SunToolkit.getDefaultToolkit()).realSync();" should be added after EventQueue.invokeLater() call for all procedures in this call to be run. After this test starts to fail. It fails since jdk 7 fcs. The fail is caused because test is corrupted. The test should compare JFrame, JWindow and JDialog FocusTraversalPolicies before "currentKFM.setDefaultFocusTraversalPolicy(newFTP)" call and after this call. But instead the test compares something different. In the current variant of this test we see: FocusTraversalPolicy defaultFTP = currentKFM.getDefaultFocusTraversalPolicy(); It returns object java.awt.DefaultFocusTraversalPolicy at 5fe2d461. But JFrame, JWindow and JDialog objects initially have "javax.swing.LayoutFocusTraversalPolicy at 2f81dd44" policy. After "currentKFM.setDefaultFocusTraversalPolicy(newFTP)" call they still have javax.swing.LayoutFocusTraversalPolicy at 2f81dd44. So test should not fail, but it fails. Test needs to be fixed. Thanks, Konstantin From vera.akulova at oracle.com Tue Dec 25 09:58:21 2012 From: vera.akulova at oracle.com (vera akulova) Date: Tue, 25 Dec 2012 13:58:21 +0400 Subject: [8] Review request for JDK-7132383: [macosx] bug6596966.java should be adapted for Mac In-Reply-To: <50C746BF.1020805@oracle.com> References: <50C746BF.1020805@oracle.com> Message-ID: <50D978BD.2070502@oracle.com> Hello Pavel, Could you please review this fix? Thanks, Vera On 11.12.2012 18:44, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-7132383: [macosx] bug6596966.java should be adapted for Mac > > The webrev is http://cr.openjdk.java.net/~kshefov/7132383/webrev.00/ > > Ctrl-Alt-Mnemonic is used now for Mac instead of Alt-Mnemonic. > Fixed test works fine on windows, linux, solaris and macos. > > Thanks, > Vera. From vera.akulova at oracle.com Tue Dec 25 09:58:25 2012 From: vera.akulova at oracle.com (vera akulova) Date: Tue, 25 Dec 2012 13:58:25 +0400 Subject: [8] Review request for JDK-7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS In-Reply-To: <50C7575C.3030806@oracle.com> References: <50C7575C.3030806@oracle.com> Message-ID: <50D978C1.3020408@oracle.com> Hello Sergey, Could you please review this fix? Thanks, Vera On 11.12.2012 19:55, vera akulova wrote: > Hello, > > Please review a fix for the issue: > JDK-7133146: [macosx] > closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS > > The webrev is http://cr.openjdk.java.net/~kshefov/7133146/webrev.00/ > > Metal L&F is used now. Fixed test works fine on windows, linux, > solaris and macos. > > Thanks, > Vera. From Sergey.Bylokhov at oracle.com Tue Dec 25 11:30:02 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Dec 2012 15:30:02 +0400 Subject: [8] Review request for JDK-7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS In-Reply-To: <50D978C1.3020408@oracle.com> References: <50C7575C.3030806@oracle.com> <50D978C1.3020408@oracle.com> Message-ID: <50D98E3A.4090306@oracle.com> Hi, Vera. 25.12.2012 13:58, vera akulova wrote: > Hello Sergey, > Could you please review this fix? I guess this code is incorrect 57 } catch (Exception ex) { 58 System.err.println("Test failed: "); 59 ex.printStackTrace(); 60 } > > Thanks, > Vera > > On 11.12.2012 19:55, vera akulova wrote: >> Hello, >> >> Please review a fix for the issue: >> JDK-7133146: [macosx] >> closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS >> >> The webrev is http://cr.openjdk.java.net/~kshefov/7133146/webrev.00/ >> >> Metal L&F is used now. Fixed test works fine on windows, linux, >> solaris and macos. >> >> Thanks, >> Vera. -- Best regards, Sergey. From alexey.utkin at oracle.com Tue Dec 25 14:47:56 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 25 Dec 2012 18:47:56 +0400 Subject: Review request: JDK-8005250 Downgrade normative references to ${java.home}/lib folder from Java client code. Message-ID: <50D9BC9C.5060103@oracle.com> The bug description: http://bugs.sun.com/view_bug.do?bug_id=8005250 The suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8005250/webrev.01/ The specification change: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8005250/specdiff.01/overview-summary.html Problem: As part of the effort to prepare the platform for modules (see http://openjdk.java.net/jeps/162) we need to re-examine all normative references to files/resources in the ${java.home} directory as these may be candidates to be replaced or candidates to move to module-private locations in the future. The focus of this fix is various client APIs that specify that the default values of client properties are loaded from property files in ${java.home}/lib directory. We need the flexibility to be able to re-locate the property files when we move to modules and a module image in jdk9. Solution: Change the specification to downgrade normative references to ${java.home}/lib directory to non-normative status. All references to this directory have been removed from external or private client APIs. Compatibility risk: minimal There is no compatibility risk as the implementation of the applicable APIs always call the specialized methods to retrieve the values of client properties, and that implementation will continue to pre-populate any properties that have been set in the properties files in ${java.home}/lib directory. Notes have been added to the class summaries of the java.awt.datatransfer.SystemFlavorMap, javax.swing.UIManager, javax.sound.midi.MidiSystem, javax.sound.sampled.AudioSystem, javax.imageio.spi.IIORegistry APIs to state that default values for client properties are read from an implementation-specific location, and the location is typically the ${java.home}/lib directory. Regards, -uta From dingxmin at linux.vnet.ibm.com Fri Dec 28 03:16:01 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Fri, 28 Dec 2012 11:16:01 +0800 Subject: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls In-Reply-To: <50C5BC18.8030009@oracle.com> References: <501F6E2E.1020608@linux.vnet.ibm.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> <50B5AF37.3070307@linux.vnet.ibm.com> <50BC8497.5030409@oracle.com> <50BEE5DE.9020803@linux.vnet.ibm.com> <50C059CF.4090806@linux.vnet.ibm.com> <50C5BC18.8030009@oracle.com> Message-ID: <50DD0EF1.9070908@linux.vnet.ibm.com> Hi Alexandr, I did some more investigations. 1. The model can be accessed as below which is also illustrated in the jtreg test http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/test/javax/swing/text/html/7189299/bug7189299.java.html HTMLEditorKit htmlEditorKit = (HTMLEditorKit) html.getEditorKit(); StyleContext.NamedStyle style = ((StyleContext.NamedStyle) htmlEditorKit.getInputAttributes()); DefaultButtonModel model = ((DefaultButtonModel) style.getAttribute(StyleConstants.ModelAttribute)); Though it needs type conversion, model can be exposed to client code. This implies client code has the chance to add listeners. Another way of updating listener in model is by first getting JButton or other html Swing components and then call listener related api that affects model. I dumped vars above but did not find out possibility for application to get Swing component reference. 2. As of swing.text.html library, I searched 'ModelAttribute' under javax/swing directory with command "grep -R 'ModelAttribute' ." which shows aside from FormView and StyleConstants, the classes referencing it are HTMLDocument, HTMLWriter. This means only FormView adds listeners to model. My first attempt at fixing the problem (only for JButton listener leak) is trying to remove all listeners completely. See http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/. Pavel argued that it may cause existing application to malfunction. Then I came up with http://cr.openjdk.java.net/~dingxmin/7189299/webrev.02/ where only stale listeners are identified and removed using reflection. But Pavel insisted reflection should be prohibited. So I tried to work around it by extending JButton in FormView to access the private listener instance such that only stale listener is removed. The perfect revision is http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/. I propose we fix JButton issue as it leads to NPE visible to application. Bug in other components can be put off if Swing team intend to fix it elegantly or duplicate code like what is in v.07. Any idea or comment, please let me know. Thanks and best regards, Frank On 12/10/2012 6:40 PM, Alexander Scherbatiy wrote: > On 12/6/2012 12:39 PM, Frank Ding wrote: >> Hi Alexandr, >> I did several attempts but still have hang issues somewhere. It >> seems the new approach of caching gui components created each time is >> not practical because of the threading restriction already imposed on >> HTMLDocument. >> Can we make compromise by turning to previous solution (v7 in >> particular) and generalize it to other gui components (which means >> there would be JCheckBoxWrapper, JRadioButtonWrapper, > > The issue is that models contain listeners from all previous > components. Models are used to store data and state of components when > form view is recreated. > FormView adds it's own listeners to components (and as result to > the models). Could you make a little investigation to check which > other listeners can the models hold? > Can a user adds a listener? Can listeners be added by other parts > of the swing.text.html library? > > If old listeners does not play role, it is possible just to remove > them all. > > Thanks, > Alexandr. > >> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, >> JComboBoxWrapper, and JButtonWrapper). Or shall we fix JButton only >> because it causes obvious exception visible to client? I am short of >> ideas... >> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/ >> >> Best regards, >> Frank >> >> On 12/5/2012 2:12 PM, Frank Ding wrote: >>> Hi Alexandr, >>> I observed the same issue in my environment as well. My proposed >>> patch would cause severe regression issues. I am looking into the >>> locking issue. >>> >>> Thanks, >>> Frank >>> >>> On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote: >>>> >>>> >>>> Could you check the following sample with your latest fix? It just >>>> hangs on my side. >>>> >>>> - put the sample.html and the response.html files on a server >>>> - update path to the html files in the >>>> LoadingWebPageToJEditorPane class >>>> >>>> ------------- sample.html ------------ >>>>
>>>> Username: >>>> >>>>
>>>> ------------- response.html ------------ >>>> >>>> >>>> Hello World! >>>> >>>> >>>> ------------- LoadingWebPageToJEditorPane.html ------------ >>>> import java.net.URL; >>>> import javax.swing.JEditorPane; >>>> import javax.swing.JFrame; >>>> import javax.swing.JScrollPane; >>>> import javax.swing.SwingUtilities; >>>> >>>> public class LoadingWebPageToJEditorPane { >>>> >>>> private static final String HTML_PATH = >>>> "http://serever/path/sample.html"; >>>> >>>> public static void main(String[] a) throws Exception { >>>> >>>> SwingUtilities.invokeAndWait(new Runnable() { >>>> >>>> @Override >>>> public void run() { >>>> try { >>>> >>>> JFrame frame = new JFrame(); >>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>> >>>> JEditorPane editorPane = new JEditorPane(); >>>> editorPane.setPage(new URL(HTML_PATH)); >>>> >>>> frame.add(new JScrollPane(editorPane)); >>>> frame.setSize(300, 200); >>>> frame.setVisible(true); >>>> SwingUtilities.updateComponentTreeUI(editorPane); >>>> } catch (Exception ex) { >>>> throw new RuntimeException(ex); >>>> } >>>> } >>>> }); >>>> } >>>> } >>>> --------------------------------------- >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 11/28/2012 10:29 AM, Frank Ding wrote: >>>>> 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 Sergey.Bylokhov at oracle.com Fri Dec 28 14:04:58 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 28 Dec 2012 18:04:58 +0400 Subject: [8] Request for review: 7124525 [macosx] No animation on certain Swing components in Aqua LaF Message-ID: <50DDA70A.9050806@oracle.com> Hello, Please review the fix. Change description: - ImageCache shouldn't cache images for animated components + cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124525 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124525/webrev.00 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swingler at apple.com Sat Dec 29 15:54:50 2012 From: swingler at apple.com (Mike Swingler) Date: Sat, 29 Dec 2012 09:54:50 -0600 Subject: [8] Request for review: 7124525 [macosx] No animation on certain Swing components in Aqua LaF In-Reply-To: <50DDA70A.9050806@oracle.com> References: <50DDA70A.9050806@oracle.com> Message-ID: <9C4E72AE-9A98-462A-887B-AECA0FDC7446@apple.com> On Dec 28, 2012, at 8:04 AM, Sergey Bylokhov wrote: > Hello, > Please review the fix. > Change description: > - ImageCache shouldn't cache images for animated components + cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124525 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124525/webrev.00 Looks good. Glad to see this kind of cleanup happening. Regards, Mike Swingler Apple Inc.