<Swing Dev> JDK 9 RFR of JDK-8043550 : Fix raw and unchecked lint warnings in javax.swing.*

[Petr Pchelko]

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 <joe.darcy at oracle.com> 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<TreeNode> children();
> 
> and that seems to work fine. Something like
> 
>    Enumeration<? extends TreeNode>
> 
> 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<KeyStroke, Object>
> 
>  68     /**
>  69       * maps top-level containers to a sub-hashtable full of keystrokes
>  70       */
>  71     Hashtable<Container, Hashtable<Object, Object>> 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<Object, Object>.
> 
> Thanks,
> 
> -Joe