From petr.pchelko at oracle.com Tue Jul 1 08:17:12 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 1 Jul 2014 12:17:12 +0400 Subject: JDK 9 RFR of JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* In-Reply-To: <53B18E62.9030306@oracle.com> References: <53B18E62.9030306@oracle.com> Message-ID: Hello, Joe. It's hard to understand what to review and what not to review. Could you please generate a separate webrev for the changes that needs to be reviewed next time? I've looked only to the javax.swing package, so I'm not sure I've reviewed everything that needed to be reviewed. 1. JComboBox: 1983 - no need to suppress warning 2. JComponent: 4121 - the change is incorrect. Value can be not an instance of Set. It depends on the property name. See line 4124 where it's cast to Boolean 3. SpinnerNumberModel: 90 - There's a typo in the comment with braces. Also, could you please clarify what do you mean under "awkward to use"? With best regards. Petr. On 30 ???? 2014 ?., at 20:20, Joe Darcy wrote: > Hello, > > Please review the final batch of changes to resolve all the unchecked and rawtypes warnings in swing: > > JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* > http://cr.openjdk.java.net/~darcy/8043550.0/ > > For completeness, this webrev also includes the in-progress changes for > > 8043548: Fix raw and unchecked lint warnings in javax.swing.plaf.* > 8042849: Fix raw and unchecked warnings in com.sun.java.swing > > For 8043548, there is still some review work going on to sort out some of the details; 8042849 has been approved, but not pushed yet as it could conceivably need updating based on other changes in swing. > > It was not immediately clear how javax.swing.tree.TreeNode.children(), which returns a raw Enumeration, should be generified. I changed it to > > Enumeration children(); > > and that seems to work fine. Something like > > Enumeration > > with a covariant override would save a few casts in a private implementation, but generally doesn't seem to be a good trade-off since many normal clients could be inconvenienced dealing with the wildcard. > > How to best generify the field javax.swing.KeyboardManager.containerMap was not immediately clear either. The documentation implies the nested Hashtable could be something like a Hashtable > > 68 /** > 69 * maps top-level containers to a sub-hashtable full of keystrokes > 70 */ > 71 Hashtable> containerMap = new Hashtable<>(); > > but that doesn't work out throughout the entire file since there is code that add entries using a Class object as the key. In the end, I just used the not-very-precise Hashtable. > > Thanks, > > -Joe From anton.tarasov at oracle.com Tue Jul 1 15:22:49 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 01 Jul 2014 19:22:49 +0400 Subject: [9] Review Request: 8048887 SortingFocusTraversalPolicy throws IllegalArgumentException from the sort method Message-ID: <53B2D249.40307@oracle.com> Hello, Please review a fix: bug: https://bugs.openjdk.java.net/browse/JDK-8048887 webrev: http://cr.openjdk.java.net/~ant/JDK-8048887/webrev.0 The problem is that SortingFocusTraversalPolicy uses ROW_TOLERANCE conception to alter a disposition of components in a focus cycle for the sake of visually more appropriate traversal order. This however breaks the transitivity rule, which in case of using the default tim-sort algo leads to an exception. We've got a number of complaints filed against this issue, so I eventually agreed to use reflection as suggested in JDK-7075600. I've tested performance in the following way. In a jframe I was adding up to 10.000 components a) at random location (with frame's null Layout) so that to completely untie traversal order from container order (hard case for the sort), and b) sequentially, so that to have the traversal order pre-sorted. Then I counted time spent in the sorting procedure. The results of the legacy merge-sort and the default tim-sort were pretty close. So, the fallback to the legacy sorting algo shouldn't hit performance for Swing. Just for the case of any unpredictable issue (and for the testing purpose), I left an ability to switch to the default tim-sort via setting the (undocumented) "swing.legacySortingFTPEnabled" property to false. Regards, Anton. From steve.sides at oracle.com Tue Jul 1 15:50:47 2014 From: steve.sides at oracle.com (Steve Sides) Date: Tue, 01 Jul 2014 08:50:47 -0700 Subject: Review Request for 8042284: Add block tags for @return and @param to swing plaf classes Message-ID: <53B2D8D7.2000504@oracle.com> ------------------------------------------------------------------------ Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8042284 Webrev corresponding: http://cr.openjdk.java.net/~ssides/8042284/8042284.3/ This addresses missing @parm and @return block tags in javadoc for javax/swing/plaf classes as noted by doclint. It does not address methods which are missing javadoc comment altogether, of which there are several. thanks, -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.sides at oracle.com Tue Jul 1 15:52:43 2014 From: steve.sides at oracle.com (Steve Sides) Date: Tue, 01 Jul 2014 08:52:43 -0700 Subject: Review request for JDK-8046590 fix doclint issues in swing classes, part 1 of 4 In-Reply-To: <53A51204.4040507@oracle.com> References: <53A221F9.2070507@oracle.com> <53A51204.4040507@oracle.com> Message-ID: <53B2D94B.9010905@oracle.com> Hello, A reminder,...could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8046590 Webrev corresponding: http://cr.openjdk.java.net/~ssides/8046590/8046590.3/ This addresses missing @parm and @return block tags in javadoc for javax/swing classes as noted by doclint and some reformatting. thanks, -steve On 6/20/2014 10:03 PM, Steve Sides wrote: > > On 6/19/2014 12:17 AM, Petr Pchelko wrote: >> Hello, Steve. >> >> A couple of comments: >> >> 1. CellRendererPane:192 - I've never seen that we write one-liner >> javadoc. >> May be it's better to split it into 3 lines to conform to the >> common pattern? > I think I borrowed that from existing in JFrame. I put it in several > places....changed them to 3 lines. > >> 2. DefaultDesktopManager:480 - "iconifyFrame()" is definetely a >> candidate to add @code tag >> line 603 - you have an extra space before "the" >> 3. InputMap:78 - extra space > These were actually intentional after I read on Stephen Colbournes > blog on Javadoc coding standards noted 2 spaces after param name, so I > checked and noticed all the @param samples on "How to Write Doc > Comments for the Javadoc Tool" also had 2 spaces (or more) after the > param name. > However, I changed the above to 1 for consistency. >> line 91: the javadoc comment "an Object" is quite useless. You >> could add something like "an action map key" >> 4. JEditorPane: 1256 as you are updating the doc for this method, >> could you please also update this line to also use @code >> 5. JFileChooser:2005 the one-liner javadoc >> 6. JMenu: 764 strange alignment of the block. > > all other noted issues addressed, > http://cr.openjdk.java.net/~ssides/8046590/8046590.3/ > > -steve > >> >> With best regards. Petr. >> >> On 19 ???? 2014 ?., at 3:34, Steve Sides wrote: >> >>> Hello, >>> >>> Could you please review the fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8046590 >>> >>> Webrev corresponding: (there were a couple typos in rev 1) >>> http://cr.openjdk.java.net/~ssides/8046590/8046590.2/ >>> >>> This addresses missing @parm and @return block tags in javadoc for >>> javax/swing classes as noted by doclint and some reformatting. >>> >>> thanks, >>> >>> -steve >>> > From steve.sides at oracle.com Tue Jul 1 15:53:04 2014 From: steve.sides at oracle.com (Steve Sides) Date: Tue, 01 Jul 2014 08:53:04 -0700 Subject: Review request for JDK-8046597 fix doclint issues in swing classes, part 4 of 4 Message-ID: <53B2D960.4050600@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8046597 Webrev corresponding: http://cr.openjdk.java.net/~ssides/8046597/ These changes address doclint missing tag and comment issues. thanks, -steve From joe.darcy at oracle.com Tue Jul 1 16:22:45 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Jul 2014 09:22:45 -0700 Subject: JDK 9 RFR of JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* In-Reply-To: References: <53B18E62.9030306@oracle.com> Message-ID: <53B2E055.4030405@oracle.com> Hi Petr, On 07/01/2014 01:17 AM, Petr Pchelko wrote: > Hello, Joe. > > It's hard to understand what to review and what not to review. Could you please generate a separate webrev for the changes that needs to be reviewed next time? > I've looked only to the javax.swing package, so I'm not sure I've reviewed everything that needed to be reviewed. > > 1. JComboBox: 1983 - no need to suppress warning Unnecessary suppression removed. > 2. JComponent: 4121 - the change is incorrect. Value can be not an instance of Set. It depends on the property name. See line 4124 where it's cast to Boolean Noted; I've changed this to have a declaration of strokeSet in each of the if block where the unchecked cast used to occur. (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) > 3. SpinnerNumberModel: 90 - There's a typo in the comment with braces. Also, could you please clarify what do you mean under "awkward to use"? Typo fixed. The actual Comparable mins and max people are likely to pass in are values of type java.lang.Double, java.lang.Integer, etc. Such types are correctly declared as Comparable to themselves: public final class Double extends Number implements Comparable {...} public final class Integer extends Number implements Comparable {...} This means that in the class for Double, there are two compareTo methods, one that takes a Double argument and one that takes an Object argument; the latter is the bridge method for the former. Of note is that there is *not* a compareTo method taking a Number as an argument. The Number type is a bit misnamed as an abstraction; it just means "convertible to primitive." Therefore, two arbitrary Number types are not mutually Comparable so it is sensible that Double doesn't have a compareTo bridge method for Number. If the minimum and maximum values were declared as Comparable with the aim of comparing two Number instances with them, in practice that would mean calling a compareTo(Number) method which doesn't exist. In that sense, it would be awkward to use Comparable ;-) (This degree of explanation struck me as overkill for a comment, but I can work on adding something along these lines if you think it would be helpful to future readers of the code.) The changes in javax.swing.tree and javax.swing.undo are new in this request. Thanks, -Joe > > With best regards. Petr. > > On 30 ???? 2014 ?., at 20:20, Joe Darcy wrote: > >> Hello, >> >> Please review the final batch of changes to resolve all the unchecked and rawtypes warnings in swing: >> >> JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* >> http://cr.openjdk.java.net/~darcy/8043550.0/ >> >> For completeness, this webrev also includes the in-progress changes for >> >> 8043548: Fix raw and unchecked lint warnings in javax.swing.plaf.* >> 8042849: Fix raw and unchecked warnings in com.sun.java.swing >> >> For 8043548, there is still some review work going on to sort out some of the details; 8042849 has been approved, but not pushed yet as it could conceivably need updating based on other changes in swing. >> >> It was not immediately clear how javax.swing.tree.TreeNode.children(), which returns a raw Enumeration, should be generified. I changed it to >> >> Enumeration children(); >> >> and that seems to work fine. Something like >> >> Enumeration >> >> with a covariant override would save a few casts in a private implementation, but generally doesn't seem to be a good trade-off since many normal clients could be inconvenienced dealing with the wildcard. >> >> How to best generify the field javax.swing.KeyboardManager.containerMap was not immediately clear either. The documentation implies the nested Hashtable could be something like a Hashtable >> >> 68 /** >> 69 * maps top-level containers to a sub-hashtable full of keystrokes >> 70 */ >> 71 Hashtable> containerMap = new Hashtable<>(); >> >> but that doesn't work out throughout the entire file since there is code that add entries using a Class object as the key. In the end, I just used the not-very-precise Hashtable. >> >> Thanks, >> >> -Joe From alexander.potochkin at oracle.com Tue Jul 1 19:26:14 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 01 Jul 2014 23:26:14 +0400 Subject: [9] Review request for JDK-8041982 Use of animated icon in JLayer causes CPU spin Message-ID: <53B30B56.7070703@oracle.com> Hello Please review the fix the the following RFE: https://bugs.openjdk.java.net/browse/JDK-8041982 JLayer/LayerUI classes don't currently allow to override the imageUpate() method to control the specific cases involved animated gif images. The proposed API change provides the required API for JDK9 http://cr.openjdk.java.net/~alexp/8041982/webrev.00/ The request to the public API change will be filed after the technical review Thanks alexp From petr.pchelko at oracle.com Tue Jul 1 20:51:41 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Jul 2014 00:51:41 +0400 Subject: JDK 9 RFR of JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* In-Reply-To: <53B2E055.4030405@oracle.com> References: <53B18E62.9030306@oracle.com> <53B2E055.4030405@oracle.com> Message-ID: <3F0A10E2-64A1-46B2-B141-7530F3D95F73@oracle.com> Hello, Joe. > (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) Interesting question. The history of this code is lost 10 years ago, so I don?t know why == is used here instead of equals. Just looking at the code I do not see any real reason to use ==, so I would say it?s a bug. So I would say we can replace it with switch. > (This degree of explanation struck me as overkill for a comment, but I can work on adding something along these lines if you think it would be helpful to future readers of the code.) Thank you for the detailed explanation, could you please make the comment slightly more explanatory? I think that adding the info that Number subclasses are not comparable with each other as Numbers would be enough. > The changes in javax.swing.tree and javax.swing.undo are new in this request. I?ve looked at these too, no new comments about them. Thank you. With best regards. Petr. > On Jul 1, 2014, at 8:22 PM, Joe Darcy wrote: > > Hi Petr, > > On 07/01/2014 01:17 AM, Petr Pchelko wrote: >> Hello, Joe. >> >> It's hard to understand what to review and what not to review. Could you please generate a separate webrev for the changes that needs to be reviewed next time? >> I've looked only to the javax.swing package, so I'm not sure I've reviewed everything that needed to be reviewed. >> >> 1. JComboBox: 1983 - no need to suppress warning > > Unnecessary suppression removed. > >> 2. JComponent: 4121 - the change is incorrect. Value can be not an instance of Set. It depends on the property name. See line 4124 where it's cast to Boolean > > Noted; I've changed this to have a declaration of strokeSet in each of the if block where the unchecked cast used to occur. > > (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) > >> 3. SpinnerNumberModel: 90 - There's a typo in the comment with braces. Also, could you please clarify what do you mean under "awkward to use"? > > Typo fixed. > > The actual Comparable mins and max people are likely to pass in are values of type java.lang.Double, java.lang.Integer, etc. Such types are correctly declared as Comparable to themselves: > > public final class Double extends Number implements Comparable {...} > > public final class Integer extends Number implements Comparable {...} > > This means that in the class for Double, there are two compareTo methods, one that takes a Double argument and one that takes an Object argument; the latter is the bridge method for the former. Of note is that there is *not* a compareTo method taking a Number as an argument. > > The Number type is a bit misnamed as an abstraction; it just means "convertible to primitive." Therefore, two arbitrary Number types are not mutually Comparable so it is sensible that Double doesn't have a compareTo bridge method for Number. > > If the minimum and maximum values were declared as Comparable with the aim of comparing two Number instances with them, in practice that would mean calling a compareTo(Number) method which doesn't exist. In that sense, it would be awkward to use Comparable ;-) > > (This degree of explanation struck me as overkill for a comment, but I can work on adding something along these lines if you think it would be helpful to future readers of the code.) > > The changes in javax.swing.tree and javax.swing.undo are new in this request. > > Thanks, > > -Joe > >> >> With best regards. Petr. >> >> On 30 ???? 2014 ?., at 20:20, Joe Darcy wrote: >> >>> Hello, >>> >>> Please review the final batch of changes to resolve all the unchecked and rawtypes warnings in swing: >>> >>> JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* >>> http://cr.openjdk.java.net/~darcy/8043550.0/ >>> >>> For completeness, this webrev also includes the in-progress changes for >>> >>> 8043548: Fix raw and unchecked lint warnings in javax.swing.plaf.* >>> 8042849: Fix raw and unchecked warnings in com.sun.java.swing >>> >>> For 8043548, there is still some review work going on to sort out some of the details; 8042849 has been approved, but not pushed yet as it could conceivably need updating based on other changes in swing. >>> >>> It was not immediately clear how javax.swing.tree.TreeNode.children(), which returns a raw Enumeration, should be generified. I changed it to >>> >>> Enumeration children(); >>> >>> and that seems to work fine. Something like >>> >>> Enumeration >>> >>> with a covariant override would save a few casts in a private implementation, but generally doesn't seem to be a good trade-off since many normal clients could be inconvenienced dealing with the wildcard. >>> >>> How to best generify the field javax.swing.KeyboardManager.containerMap was not immediately clear either. The documentation implies the nested Hashtable could be something like a Hashtable >>> >>> 68 /** >>> 69 * maps top-level containers to a sub-hashtable full of keystrokes >>> 70 */ >>> 71 Hashtable> containerMap = new Hashtable<>(); >>> >>> but that doesn't work out throughout the entire file since there is code that add entries using a Class object as the key. In the end, I just used the not-very-precise Hashtable. >>> >>> Thanks, >>> >>> -Joe > From petr.pchelko at oracle.com Wed Jul 2 07:54:05 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Jul 2014 11:54:05 +0400 Subject: Review request for JDK-8046590 fix doclint issues in swing classes, part 1 of 4 In-Reply-To: <53B2D94B.9010905@oracle.com> References: <53A221F9.2070507@oracle.com> <53A51204.4040507@oracle.com> <53B2D94B.9010905@oracle.com> Message-ID: Hello, Steve. Looks good to me. With best regards. Petr. On 01 ???? 2014 ?., at 19:52, Steve Sides wrote: > Hello, > > A reminder,...could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8046590 > > Webrev corresponding: > http://cr.openjdk.java.net/~ssides/8046590/8046590.3/ > > This addresses missing @parm and @return block tags in javadoc for > javax/swing classes as noted by doclint and some reformatting. > > thanks, > > -steve > > > On 6/20/2014 10:03 PM, Steve Sides wrote: >> >> On 6/19/2014 12:17 AM, Petr Pchelko wrote: >>> Hello, Steve. >>> >>> A couple of comments: >>> >>> 1. CellRendererPane:192 - I've never seen that we write one-liner javadoc. >>> May be it's better to split it into 3 lines to conform to the common pattern? >> I think I borrowed that from existing in JFrame. I put it in several places....changed them to 3 lines. >> >>> 2. DefaultDesktopManager:480 - "iconifyFrame()" is definetely a candidate to add @code tag >>> line 603 - you have an extra space before "the" >>> 3. InputMap:78 - extra space >> These were actually intentional after I read on Stephen Colbournes blog on Javadoc coding standards noted 2 spaces after param name, so I checked and noticed all the @param samples on "How to Write Doc Comments for the Javadoc Tool" also had 2 spaces (or more) after the param name. >> However, I changed the above to 1 for consistency. >>> line 91: the javadoc comment "an Object" is quite useless. You could add something like "an action map key" >>> 4. JEditorPane: 1256 as you are updating the doc for this method, could you please also update this line to also use @code >>> 5. JFileChooser:2005 the one-liner javadoc >>> 6. JMenu: 764 strange alignment of the block. >> >> all other noted issues addressed, >> http://cr.openjdk.java.net/~ssides/8046590/8046590.3/ >> >> -steve >> >>> >>> With best regards. Petr. >>> >>> On 19 ???? 2014 ?., at 3:34, Steve Sides wrote: >>> >>>> Hello, >>>> >>>> Could you please review the fix for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8046590 >>>> >>>> Webrev corresponding: (there were a couple typos in rev 1) >>>> http://cr.openjdk.java.net/~ssides/8046590/8046590.2/ >>>> >>>> This addresses missing @parm and @return block tags in javadoc for >>>> javax/swing classes as noted by doclint and some reformatting. >>>> >>>> thanks, >>>> >>>> -steve >>>> >> > From petr.pchelko at oracle.com Wed Jul 2 07:57:44 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Jul 2014 11:57:44 +0400 Subject: Review request for JDK-8046597 fix doclint issues in swing classes, part 4 of 4 In-Reply-To: <53B2D960.4050600@oracle.com> References: <53B2D960.4050600@oracle.com> Message-ID: Hello, Steve. JTextField - wrong formatting of the @return tag Otherwise the fix looks good, no need for a new webrev, just fix the formatting before the push. With best regards. Petr. On 01 ???? 2014 ?., at 19:53, Steve Sides wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8046597 > > Webrev corresponding: > http://cr.openjdk.java.net/~ssides/8046597/ > > These changes address doclint missing tag and comment issues. > > thanks, > > -steve > From alexander.zvegintsev at oracle.com Wed Jul 2 10:53:51 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 02 Jul 2014 14:53:51 +0400 Subject: [9] Review Request: 8048887 SortingFocusTraversalPolicy throws IllegalArgumentException from the sort method In-Reply-To: <53B2D249.40307@oracle.com> References: <53B2D249.40307@oracle.com> Message-ID: <53B3E4BF.30106@oracle.com> Hi Anton, the fix looks good to me. BTW you can use GetBooleanAction instead of GetPropertyAction. Thanks, Alexander. On 07/01/2014 07:22 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8048887 > webrev: http://cr.openjdk.java.net/~ant/JDK-8048887/webrev.0 > > The problem is that SortingFocusTraversalPolicy uses ROW_TOLERANCE > conception to alter a disposition of components in a focus cycle for > the sake of visually more appropriate traversal order. This however > breaks the transitivity rule, which in case of using the default > tim-sort algo leads to an exception. > > We've got a number of complaints filed against this issue, so I > eventually agreed to use reflection as suggested in JDK-7075600. > > I've tested performance in the following way. In a jframe I was adding > up to 10.000 components a) at random location (with frame's null > Layout) so that to completely untie traversal order from container > order (hard case for the sort), and b) sequentially, so that to have > the traversal order pre-sorted. Then I counted time spent in the > sorting procedure. The results of the legacy merge-sort and the > default tim-sort were pretty close. So, the fallback to the legacy > sorting algo shouldn't hit performance for Swing. > > Just for the case of any unpredictable issue (and for the testing > purpose), I left an ability to switch to the default tim-sort via > setting the (undocumented) "swing.legacySortingFTPEnabled" property to > false. > > Regards, > Anton. From alexander.zvegintsev at oracle.com Wed Jul 2 11:06:19 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 02 Jul 2014 15:06:19 +0400 Subject: [9] Review Request: 8048887 SortingFocusTraversalPolicy throws IllegalArgumentException from the sort method In-Reply-To: <53B3E4BF.30106@oracle.com> References: <53B2D249.40307@oracle.com> <53B3E4BF.30106@oracle.com> Message-ID: <53B3E7AB.1000404@oracle.com> Disregard my comment about GetBooleanAction, it does not have default value. Thanks, Alexander. On 07/02/2014 02:53 PM, Alexander Zvegintsev wrote: > Hi Anton, > > the fix looks good to me. > BTW you can use GetBooleanAction instead of GetPropertyAction. > > > Thanks, > > Alexander. > > On 07/01/2014 07:22 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please review a fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8048887 >> webrev: http://cr.openjdk.java.net/~ant/JDK-8048887/webrev.0 >> >> The problem is that SortingFocusTraversalPolicy uses ROW_TOLERANCE >> conception to alter a disposition of components in a focus cycle for >> the sake of visually more appropriate traversal order. This however >> breaks the transitivity rule, which in case of using the default >> tim-sort algo leads to an exception. >> >> We've got a number of complaints filed against this issue, so I >> eventually agreed to use reflection as suggested in JDK-7075600. >> >> I've tested performance in the following way. In a jframe I was >> adding up to 10.000 components a) at random location (with frame's >> null Layout) so that to completely untie traversal order from >> container order (hard case for the sort), and b) sequentially, so >> that to have the traversal order pre-sorted. Then I counted time >> spent in the sorting procedure. The results of the legacy merge-sort >> and the default tim-sort were pretty close. So, the fallback to the >> legacy sorting algo shouldn't hit performance for Swing. >> >> Just for the case of any unpredictable issue (and for the testing >> purpose), I left an ability to switch to the default tim-sort via >> setting the (undocumented) "swing.legacySortingFTPEnabled" property >> to false. >> >> Regards, >> Anton. > From anton.tarasov at oracle.com Wed Jul 2 13:06:48 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 02 Jul 2014 17:06:48 +0400 Subject: [9] Review Request: 8048887 SortingFocusTraversalPolicy throws IllegalArgumentException from the sort method In-Reply-To: <53B3E7AB.1000404@oracle.com> References: <53B2D249.40307@oracle.com> <53B3E4BF.30106@oracle.com> <53B3E7AB.1000404@oracle.com> Message-ID: <53B403E8.6060007@oracle.com> Ok, thanks for the review! Anton. On 02.07.2014 15:06, Alexander Zvegintsev wrote: > Disregard my comment about GetBooleanAction, it does not have default value. > > Thanks, > > Alexander. > > On 07/02/2014 02:53 PM, Alexander Zvegintsev wrote: >> Hi Anton, >> >> the fix looks good to me. >> BTW you can use GetBooleanAction instead of GetPropertyAction. >> >> >> Thanks, >> >> Alexander. >> >> On 07/01/2014 07:22 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please review a fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8048887 >>> webrev: http://cr.openjdk.java.net/~ant/JDK-8048887/webrev.0 >>> >>> The problem is that SortingFocusTraversalPolicy uses ROW_TOLERANCE conception to alter a >>> disposition of components in a focus cycle for the sake of visually more appropriate traversal >>> order. This however breaks the transitivity rule, which in case of using the default tim-sort >>> algo leads to an exception. >>> >>> We've got a number of complaints filed against this issue, so I eventually agreed to use >>> reflection as suggested in JDK-7075600. >>> >>> I've tested performance in the following way. In a jframe I was adding up to 10.000 components >>> a) at random location (with frame's null Layout) so that to completely untie traversal order >>> from container order (hard case for the sort), and b) sequentially, so that to have the >>> traversal order pre-sorted. Then I counted time spent in the sorting procedure. The results of >>> the legacy merge-sort and the default tim-sort were pretty close. So, the fallback to the legacy >>> sorting algo shouldn't hit performance for Swing. >>> >>> Just for the case of any unpredictable issue (and for the testing purpose), I left an ability to >>> switch to the default tim-sort via setting the (undocumented) "swing.legacySortingFTPEnabled" >>> property to false. >>> >>> Regards, >>> Anton. >> > From alexey.ivanov at oracle.com Wed Jul 2 13:28:01 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 02 Jul 2014 17:28:01 +0400 Subject: [9] Review request for JDK-8046559: NPE when changing Windows theme Message-ID: <53B408E1.70008@oracle.com> Hi AWT, Swing teams, Could you please review the fix to JDK-8046559 for jdk9: bug: https://bugs.openjdk.java.net/browse/JDK-8046559 webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/ Problem description: When changing Windows themes from a theme with visual styles (Windows Aero or Windows Basic) to a classic one, NullPointerException could be thrown from Swing code during component tree validation, or InternalError could be thrown during component painting. Root cause: Windows theme data are accessed via XPStyle and ThemeReader. When the theme is switched to a classic one, theme handles become unavailable, and theme data cannot be accessed any more. The change in theme is posted to EDT; at the same time, the UI often needs to repaint before the theme change is completely handled in Swing. This leads to NPE and InternalError as the code tries to access the data that has become unavailable. The fix: Windows desktop properties are updated right on Windows Toolkit thread, and the value of "win.xpstyle.themeActive" is stored in ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop properties are delivered either synchronously on EDT or asynchronously via DesktopPropertyChangeSupport, as it used to be. Getters in XPStyle class check for null values and return dummy defaults if ThemeReader returned null. SkinPainters also check whether theming is still available before asking ThemeReader to paint. Access to XPStyle.xp instance is blocked as soon as user switches themes. The object will be cleaned when the corresponding PropertyChangeEvent is handled by Swing. This new version of the fix addresses issues found with the initial submission of JDK-8039383 fix: - JDK-8046239: Build failure in 9-client on all non-Windows platforms - JDK-8046391: Hang displaying JFileChooser with Windows L&F See also http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/ Regression test: No regression test is provided due to its complexity. Whether NullPointerException or InternalError are thrown depends on the order of event handling, sometimes exceptions do not occur when changing theme of visual styles enabled theme to a classic theme. I included regression test for hang in JFileChooser, JDK-8046391. Thank you, Alexey. From alexandr.scherbatiy at oracle.com Wed Jul 2 14:43:41 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 02 Jul 2014 18:43:41 +0400 Subject: [9] Review Request: 8048887 SortingFocusTraversalPolicy throws IllegalArgumentException from the sort method In-Reply-To: <53B2D249.40307@oracle.com> References: <53B2D249.40307@oracle.com> Message-ID: <53B41A9D.9060504@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/1/2014 7:22 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8048887 > webrev: http://cr.openjdk.java.net/~ant/JDK-8048887/webrev.0 > > The problem is that SortingFocusTraversalPolicy uses ROW_TOLERANCE > conception to alter a disposition of components in a focus cycle for > the sake of visually more appropriate traversal order. This however > breaks the transitivity rule, which in case of using the default > tim-sort algo leads to an exception. > > We've got a number of complaints filed against this issue, so I > eventually agreed to use reflection as suggested in JDK-7075600. > > I've tested performance in the following way. In a jframe I was adding > up to 10.000 components a) at random location (with frame's null > Layout) so that to completely untie traversal order from container > order (hard case for the sort), and b) sequentially, so that to have > the traversal order pre-sorted. Then I counted time spent in the > sorting procedure. The results of the legacy merge-sort and the > default tim-sort were pretty close. So, the fallback to the legacy > sorting algo shouldn't hit performance for Swing. > > Just for the case of any unpredictable issue (and for the testing > purpose), I left an ability to switch to the default tim-sort via > setting the (undocumented) "swing.legacySortingFTPEnabled" property to > false. > > Regards, > Anton. From anton.nashatyrev at oracle.com Wed Jul 2 15:02:24 2014 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Wed, 02 Jul 2014 19:02:24 +0400 Subject: [9] Review request for 8044371: setOneTouchExpandable functionality of JSplitPane will reduce vertical Scrollbar In-Reply-To: <53AADB6B.8030100@oracle.com> References: <53A9A7DF.8070508@oracle.com> <53AACAB0.1060905@oracle.com> <53AAD071.1060100@oracle.com> <53AADB6B.8030100@oracle.com> Message-ID: <53B41F00.3060002@oracle.com> Hi Alexander, thanks for review! is there another volunteer? Thanks! Anton. On 25.06.2014 18:23, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/25/2014 5:36 PM, anton nashatyrev wrote: >> Hi Alexander, >> >> this works on the current testcase. >> What makes me more confident is that before the fix JDK-4502121 a >> negative dimension was also possible and the methods you mentioned >> might be called with such values. It seems the class didn't changed >> dramatically since that time. >> >> Thanks! >> Anton. >> >> On 25.06.2014 17:12, Alexander Scherbatiy wrote: >>> >>> Removing isEmpty variable checking logic leads that some methods >>> (adjustForVSB(...), viewport.toViewCoordinates(...)) could use a >>> rectangle with negative sizes. >>> Do these methods work properly in this case? >>> >>> Thanks, >>> Alexandr. >>> >>> On 6/24/2014 8:31 PM, anton nashatyrev wrote: >>>> Hello, >>>> could you please review the following fix: >>>> >>>> fix: http://cr.openjdk.java.net/~anashaty/8044371/9/webrev.00/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044371 >>>> >>>> Problem: >>>> After the ScrollPane which is scrolled to the bottom resized to >>>> the width 0 and then back its vertical scroll position changes. >>>> >>>> Evaluation: >>>> this is the regression from the fix JDK-4502121 >>>> . >>>> When the viewport size is 0 the >>>> ScrollPaneLayout.layoutContainer decides not to paint/layout the >>>> scrollbars and the viewport height is calculated with no respect to >>>> horizontal scrollbar height. The viewport height thus becomes >>>> larger and its position shifts 25 pixels (the height of the >>>> horisontal scrollbar) up. The expand action doesn't revert the >>>> position which is a normal behavior. >>>> >>>> Fix: >>>> modify the fix for JDK-4502121 >>>> , so it still >>>> solves the original problem, but doesn't add the unwanted behavior: >>>> the layout should take into account the scrollbars even if the size >>>> of the scrollpane is 0. >>>> >>>> Thanks! >>>> Anton. >>> >> > From stuart.marks at oracle.com Wed Jul 2 22:31:54 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 02 Jul 2014 15:31:54 -0700 Subject: [9] Review Request: 8047025 Fix raw and unchecked lint warnings in generated nimbus files Message-ID: <53B4885A.4080607@oracle.com> Hi all, Please review this change for 8047025, "Fix raw and unchecked lint warnings in generated nimbus files." Webrev: http://cr.openjdk.java.net/~smarks/reviews/8047025/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8047025 Although this change modifies only a few lines of template files, it removes 31 raw and unchecked lint warnings. I've done a build with the changes in place, and I've also run SwingSet2 and switched it to the Nimbus L&F and it looked fine to me. Please let me know if I should do additional testing. Thanks, s'marks From henry.jen at oracle.com Wed Jul 2 23:47:09 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 02 Jul 2014 16:47:09 -0700 Subject: [9] Review Request: 8047025 Fix raw and unchecked lint warnings in generated nimbus files In-Reply-To: <53B4885A.4080607@oracle.com> References: <53B4885A.4080607@oracle.com> Message-ID: <53B499FD.90904@oracle.com> Looks good to me. Cheers, Henry On 07/02/2014 03:31 PM, Stuart Marks wrote: > Hi all, > > Please review this change for 8047025, "Fix raw and unchecked lint > warnings in generated nimbus files." > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8047025/webrev.0/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8047025 > > Although this change modifies only a few lines of template files, it > removes 31 raw and unchecked lint warnings. > > I've done a build with the changes in place, and I've also run SwingSet2 > and switched it to the Nimbus L&F and it looked fine to me. Please let > me know if I should do additional testing. > > Thanks, > > s'marks From alexander.potochkin at oracle.com Thu Jul 3 14:16:34 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Thu, 03 Jul 2014 18:16:34 +0400 Subject: [9] Review request for 8044371: setOneTouchExpandable functionality of JSplitPane will reduce vertical Scrollbar In-Reply-To: <53A9A7DF.8070508@oracle.com> References: <53A9A7DF.8070508@oracle.com> Message-ID: <53B565C2.70301@oracle.com> Hello Anton Looks good alexp On 6/24/2014 8:31 PM, anton nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8044371/9/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8044371 > > Problem: > After the ScrollPane which is scrolled to the bottom resized to > the width 0 and then back its vertical scroll position changes. > > Evaluation: > this is the regression from the fix JDK-4502121 > . > When the viewport size is 0 the ScrollPaneLayout.layoutContainer > decides not to paint/layout the scrollbars and the viewport height is > calculated with no respect to horizontal scrollbar height. The > viewport height thus becomes larger and its position shifts 25 pixels > (the height of the horisontal scrollbar) up. The expand action doesn't > revert the position which is a normal behavior. > > Fix: > modify the fix for JDK-4502121 > , so it still solves > the original problem, but doesn't add the unwanted behavior: the > layout should take into account the scrollbars even if the size of the > scrollpane is 0. > > Thanks! > Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 3 14:30:01 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 03 Jul 2014 18:30:01 +0400 Subject: Review request for JDK-8046590 fix doclint issues in swing classes, part 1 of 4 In-Reply-To: <53B2D94B.9010905@oracle.com> References: <53A221F9.2070507@oracle.com> <53A51204.4040507@oracle.com> <53B2D94B.9010905@oracle.com> Message-ID: <53B568E9.30501@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/1/2014 7:52 PM, Steve Sides wrote: > Hello, > > A reminder,...could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8046590 > > Webrev corresponding: > http://cr.openjdk.java.net/~ssides/8046590/8046590.3/ > > This addresses missing @parm and @return block tags in javadoc for > javax/swing classes as noted by doclint and some reformatting. > > thanks, > > -steve > > > On 6/20/2014 10:03 PM, Steve Sides wrote: >> >> On 6/19/2014 12:17 AM, Petr Pchelko wrote: >>> Hello, Steve. >>> >>> A couple of comments: >>> >>> 1. CellRendererPane:192 - I've never seen that we write one-liner >>> javadoc. >>> May be it's better to split it into 3 lines to conform to the >>> common pattern? >> I think I borrowed that from existing in JFrame. I put it in several >> places....changed them to 3 lines. >> >>> 2. DefaultDesktopManager:480 - "iconifyFrame()" is definetely a >>> candidate to add @code tag >>> line 603 - you have an extra space before "the" >>> 3. InputMap:78 - extra space >> These were actually intentional after I read on Stephen Colbournes >> blog on Javadoc coding standards noted 2 spaces after param name, so >> I checked and noticed all the @param samples on "How to Write Doc >> Comments for the Javadoc Tool" also had 2 spaces (or more) after the >> param name. >> However, I changed the above to 1 for consistency. >>> line 91: the javadoc comment "an Object" is quite useless. You >>> could add something like "an action map key" >>> 4. JEditorPane: 1256 as you are updating the doc for this method, >>> could you please also update this line to also use @code >>> 5. JFileChooser:2005 the one-liner javadoc >>> 6. JMenu: 764 strange alignment of the block. >> >> all other noted issues addressed, >> http://cr.openjdk.java.net/~ssides/8046590/8046590.3/ >> >> -steve >> >>> >>> With best regards. Petr. >>> >>> On 19 ???? 2014 ?., at 3:34, Steve Sides >>> wrote: >>> >>>> Hello, >>>> >>>> Could you please review the fix for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8046590 >>>> >>>> Webrev corresponding: (there were a couple typos in rev 1) >>>> http://cr.openjdk.java.net/~ssides/8046590/8046590.2/ >>>> >>>> This addresses missing @parm and @return block tags in javadoc for >>>> javax/swing classes as noted by doclint and some reformatting. >>>> >>>> thanks, >>>> >>>> -steve >>>> >> > From alexandr.scherbatiy at oracle.com Thu Jul 3 14:31:46 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 03 Jul 2014 18:31:46 +0400 Subject: Review request for JDK-8046597 fix doclint issues in swing classes, part 4 of 4 In-Reply-To: <53B2D960.4050600@oracle.com> References: <53B2D960.4050600@oracle.com> Message-ID: <53B56952.7080208@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/1/2014 7:53 PM, Steve Sides wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8046597 > > Webrev corresponding: > http://cr.openjdk.java.net/~ssides/8046597/ > > These changes address doclint missing tag and comment issues. > > thanks, > > -steve > From joe.darcy at oracle.com Thu Jul 3 15:22:00 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 03 Jul 2014 08:22:00 -0700 Subject: JDK 9 RFR of JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* In-Reply-To: <3F0A10E2-64A1-46B2-B141-7530F3D95F73@oracle.com> References: <53B18E62.9030306@oracle.com> <53B2E055.4030405@oracle.com> <3F0A10E2-64A1-46B2-B141-7530F3D95F73@oracle.com> Message-ID: <53B57518.8090305@oracle.com> Hi Petr, On 07/01/2014 01:51 PM, Petr Pchelko wrote: > Hello, Joe. > >> (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) > Interesting question. The history of this code is lost 10 years ago, so I don?t know why == is used here instead of equals. > Just looking at the code I do not see any real reason to use ==, so I would say it?s a bug. So I would say we can replace it with switch. Upon further reflection, I'd prefer the change to using a .equals based comparison being done under a different changeset. Doing so will make it easier to isolate any problems which may arise strictly from generification and warning removal. > >> (This degree of explanation struck me as overkill for a comment, but I can work on adding something along these lines if you think it would be helpful to future readers of the code.) > Thank you for the detailed explanation, could you please make the comment slightly more explanatory? I think that adding the info that Number subclasses are not comparable with each other as Numbers would be enough. Comment expanded. > >> The changes in javax.swing.tree and javax.swing.undo are new in this request. > I?ve looked at these too, no new comments about them. Update webrev: http://cr.openjdk.java.net/~darcy/8043550.1/ Thanks, -Joe > > Thank you. > With best regards. Petr. > >> On Jul 1, 2014, at 8:22 PM, Joe Darcy wrote: >> >> Hi Petr, >> >> On 07/01/2014 01:17 AM, Petr Pchelko wrote: >>> Hello, Joe. >>> >>> It's hard to understand what to review and what not to review. Could you please generate a separate webrev for the changes that needs to be reviewed next time? >>> I've looked only to the javax.swing package, so I'm not sure I've reviewed everything that needed to be reviewed. >>> >>> 1. JComboBox: 1983 - no need to suppress warning >> Unnecessary suppression removed. >> >>> 2. JComponent: 4121 - the change is incorrect. Value can be not an instance of Set. It depends on the property name. See line 4124 where it's cast to Boolean >> Noted; I've changed this to have a declaration of strokeSet in each of the if block where the unchecked cast used to occur. >> >> (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) >> >>> 3. SpinnerNumberModel: 90 - There's a typo in the comment with braces. Also, could you please clarify what do you mean under "awkward to use"? >> Typo fixed. >> >> The actual Comparable mins and max people are likely to pass in are values of type java.lang.Double, java.lang.Integer, etc. Such types are correctly declared as Comparable to themselves: >> >> public final class Double extends Number implements Comparable {...} >> >> public final class Integer extends Number implements Comparable {...} >> >> This means that in the class for Double, there are two compareTo methods, one that takes a Double argument and one that takes an Object argument; the latter is the bridge method for the former. Of note is that there is *not* a compareTo method taking a Number as an argument. >> >> The Number type is a bit misnamed as an abstraction; it just means "convertible to primitive." Therefore, two arbitrary Number types are not mutually Comparable so it is sensible that Double doesn't have a compareTo bridge method for Number. >> >> If the minimum and maximum values were declared as Comparable with the aim of comparing two Number instances with them, in practice that would mean calling a compareTo(Number) method which doesn't exist. In that sense, it would be awkward to use Comparable ;-) >> >> (This degree of explanation struck me as overkill for a comment, but I can work on adding something along these lines if you think it would be helpful to future readers of the code.) >> >> The changes in javax.swing.tree and javax.swing.undo are new in this request. >> >> Thanks, >> >> -Joe >> >>> With best regards. Petr. >>> >>> On 30 ???? 2014 ?., at 20:20, Joe Darcy wrote: >>> >>>> Hello, >>>> >>>> Please review the final batch of changes to resolve all the unchecked and rawtypes warnings in swing: >>>> >>>> JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* >>>> http://cr.openjdk.java.net/~darcy/8043550.0/ >>>> >>>> For completeness, this webrev also includes the in-progress changes for >>>> >>>> 8043548: Fix raw and unchecked lint warnings in javax.swing.plaf.* >>>> 8042849: Fix raw and unchecked warnings in com.sun.java.swing >>>> >>>> For 8043548, there is still some review work going on to sort out some of the details; 8042849 has been approved, but not pushed yet as it could conceivably need updating based on other changes in swing. >>>> >>>> It was not immediately clear how javax.swing.tree.TreeNode.children(), which returns a raw Enumeration, should be generified. I changed it to >>>> >>>> Enumeration children(); >>>> >>>> and that seems to work fine. Something like >>>> >>>> Enumeration >>>> >>>> with a covariant override would save a few casts in a private implementation, but generally doesn't seem to be a good trade-off since many normal clients could be inconvenienced dealing with the wildcard. >>>> >>>> How to best generify the field javax.swing.KeyboardManager.containerMap was not immediately clear either. The documentation implies the nested Hashtable could be something like a Hashtable >>>> >>>> 68 /** >>>> 69 * maps top-level containers to a sub-hashtable full of keystrokes >>>> 70 */ >>>> 71 Hashtable> containerMap = new Hashtable<>(); >>>> >>>> but that doesn't work out throughout the entire file since there is code that add entries using a Class object as the key. In the end, I just used the not-very-precise Hashtable. >>>> >>>> Thanks, >>>> >>>> -Joe From petr.pchelko at oracle.com Thu Jul 3 15:30:56 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 3 Jul 2014 19:30:56 +0400 Subject: JDK 9 RFR of JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* In-Reply-To: <53B57518.8090305@oracle.com> References: <53B18E62.9030306@oracle.com> <53B2E055.4030405@oracle.com> <3F0A10E2-64A1-46B2-B141-7530F3D95F73@oracle.com> <53B57518.8090305@oracle.com> Message-ID: Hello, Joe. The fix looks good. >>> (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) >> Interesting question. The history of this code is lost 10 years ago, so I don?t know why == is used here instead of equals. >> Just looking at the code I do not see any real reason to use ==, so I would say it?s a bug. So I would say we can replace it with switch. Ok, I was thinking about the same. Could you please file a P4 bug against swing? We will handle it further. Thank you. With best regards. Petr. > On Jul 3, 2014, at 7:22 PM, Joe Darcy wrote: > > Hi Petr, > > On 07/01/2014 01:51 PM, Petr Pchelko wrote: >> Hello, Joe. >> >>> (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) >> Interesting question. The history of this code is lost 10 years ago, so I don?t know why == is used here instead of equals. >> Just looking at the code I do not see any real reason to use ==, so I would say it?s a bug. So I would say we can replace it with switch. > > Upon further reflection, I'd prefer the change to using a .equals based comparison being done under a different changeset. Doing so will make it easier to isolate any problems which may arise strictly from generification and warning removal. > >> >>> (This degree of explanation struck me as overkill for a comment, but I can work on adding something along these lines if you think it would be helpful to future readers of the code.) >> Thank you for the detailed explanation, could you please make the comment slightly more explanatory? I think that adding the info that Number subclasses are not comparable with each other as Numbers would be enough. > > Comment expanded. > >> >>> The changes in javax.swing.tree and javax.swing.undo are new in this request. >> I?ve looked at these too, no new comments about them. > > Update webrev: > > http://cr.openjdk.java.net/~darcy/8043550.1/ > > Thanks, > > -Joe > >> >> Thank you. >> With best regards. Petr. >> >>> On Jul 1, 2014, at 8:22 PM, Joe Darcy wrote: >>> >>> Hi Petr, >>> >>> On 07/01/2014 01:17 AM, Petr Pchelko wrote: >>>> Hello, Joe. >>>> >>>> It's hard to understand what to review and what not to review. Could you please generate a separate webrev for the changes that needs to be reviewed next time? >>>> I've looked only to the javax.swing package, so I'm not sure I've reviewed everything that needed to be reviewed. >>>> >>>> 1. JComboBox: 1983 - no need to suppress warning >>> Unnecessary suppression removed. >>> >>>> 2. JComponent: 4121 - the change is incorrect. Value can be not an instance of Set. It depends on the property name. See line 4124 where it's cast to Boolean >>> Noted; I've changed this to have a declaration of strokeSet in each of the if block where the unchecked cast used to occur. >>> >>> (Is is correct that this code is using "==" rather than ".equals" to compare strings? If .equals were correct, I would change this method to use strings in switch.) >>> >>>> 3. SpinnerNumberModel: 90 - There's a typo in the comment with braces. Also, could you please clarify what do you mean under "awkward to use"? >>> Typo fixed. >>> >>> The actual Comparable mins and max people are likely to pass in are values of type java.lang.Double, java.lang.Integer, etc. Such types are correctly declared as Comparable to themselves: >>> >>> public final class Double extends Number implements Comparable {...} >>> >>> public final class Integer extends Number implements Comparable {...} >>> >>> This means that in the class for Double, there are two compareTo methods, one that takes a Double argument and one that takes an Object argument; the latter is the bridge method for the former. Of note is that there is *not* a compareTo method taking a Number as an argument. >>> >>> The Number type is a bit misnamed as an abstraction; it just means "convertible to primitive." Therefore, two arbitrary Number types are not mutually Comparable so it is sensible that Double doesn't have a compareTo bridge method for Number. >>> >>> If the minimum and maximum values were declared as Comparable with the aim of comparing two Number instances with them, in practice that would mean calling a compareTo(Number) method which doesn't exist. In that sense, it would be awkward to use Comparable ;-) >>> >>> (This degree of explanation struck me as overkill for a comment, but I can work on adding something along these lines if you think it would be helpful to future readers of the code.) >>> >>> The changes in javax.swing.tree and javax.swing.undo are new in this request. >>> >>> Thanks, >>> >>> -Joe >>> >>>> With best regards. Petr. >>>> >>>> On 30 ???? 2014 ?., at 20:20, Joe Darcy wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review the final batch of changes to resolve all the unchecked and rawtypes warnings in swing: >>>>> >>>>> JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.* >>>>> http://cr.openjdk.java.net/~darcy/8043550.0/ >>>>> >>>>> For completeness, this webrev also includes the in-progress changes for >>>>> >>>>> 8043548: Fix raw and unchecked lint warnings in javax.swing.plaf.* >>>>> 8042849: Fix raw and unchecked warnings in com.sun.java.swing >>>>> >>>>> For 8043548, there is still some review work going on to sort out some of the details; 8042849 has been approved, but not pushed yet as it could conceivably need updating based on other changes in swing. >>>>> >>>>> It was not immediately clear how javax.swing.tree.TreeNode.children(), which returns a raw Enumeration, should be generified. I changed it to >>>>> >>>>> Enumeration children(); >>>>> >>>>> and that seems to work fine. Something like >>>>> >>>>> Enumeration >>>>> >>>>> with a covariant override would save a few casts in a private implementation, but generally doesn't seem to be a good trade-off since many normal clients could be inconvenienced dealing with the wildcard. >>>>> >>>>> How to best generify the field javax.swing.KeyboardManager.containerMap was not immediately clear either. The documentation implies the nested Hashtable could be something like a Hashtable >>>>> >>>>> 68 /** >>>>> 69 * maps top-level containers to a sub-hashtable full of keystrokes >>>>> 70 */ >>>>> 71 Hashtable> containerMap = new Hashtable<>(); >>>>> >>>>> but that doesn't work out throughout the entire file since there is code that add entries using a Class object as the key. In the end, I just used the not-very-precise Hashtable. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe > From joe.darcy at oracle.com Thu Jul 3 19:44:45 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 03 Jul 2014 12:44:45 -0700 Subject: Supplemental code review request for JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.* Message-ID: <53B5B2AD.3040803@oracle.com> Hello, In the course of fixing JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.* http://cr.openjdk.java.net/~darcy/8043550.1/ I encountered a build failure in jconsole due to a conflict between a recent generification in jconsole 8044865: Fix raw and unchecked lint warnings in management-related code http://hg.openjdk.java.net/jdk9/dev/jdk/rev/81e22723ba57 and the newly generified swing. Fortunately, the adjustment in jconsole to be reviewed is simple: --- a/src/share/classes/sun/tools/jconsole/inspector/TableSorter.java Tue Jul 01 23:09:52 2014 +0000 +++ b/src/share/classes/sun/tools/jconsole/inspector/TableSorter.java Thu Jul 03 12:09:44 2014 -0700 @@ -217,17 +217,17 @@ } } - private Vector getRow(int row) { - return (Vector) dataVector.elementAt(row); + private Vector