<Swing Dev> [PATCH] 100153: Generics: JComboBox

[Florian Brunner]

Hi Pavel,

Thanks for your response. I will have a look at it.

Regards,
Florian

Am Dienstag 23 November 2010 10:58:15 schrieb Pavel Porvatov:
> Hi Florian,
> 
> I have several comment about your patch:
> 1. Run an attached test, enter some text (e.g. "aa") and press enter. 
> The text disappears, but if you reenter text it stays.
> 
> 2. The following changes in the 
> javax.swing.plaf.basic.BasicComboBoxEditor#getItem() looks strange for 
> me, could you describe them please?
> +        if (oldValue instanceof String) {
> +            return (E) newValue;
> +        } else {...
> 
> BTW: The code "Method method = cls.getMethod("valueOf", new 
> Class[]{String.class});" and other stuff like that were added with the 
> fix of CR 4239610 
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4239610). That code 
> looks strange for me, I believe the check 
> "newValue.equals(oldValue.toString())" is enough for that bug...  
> Moreover the "valueof" method cannot be used as a universal solution for 
> String->AnyClass conversion because of that's impossible to use in case 
> oldValue is null.
> 
> Therefore I think we should not change the WindowsComboBoxUI.java, 
> ComboBoxEditor.java, BasicComboBoxEditor.java and 
> MetalComboBoxEditor.java files at all, because there are no available 
> API for converting string into *any* class. What do you think about 
> that? Logically it means that editor can edit only strings but not any 
> class.
> 
> 3. After item 2 we will see that it's not possible to generify the 
> set/getSelectedItem methods in the javax.swing.ComboBoxModel interface 
> because of some code in the javax.swing.JComboBox#actionPerformed 
> method. The same set/getSelectedItem methods in the JComboBox class 
> shouldn't be generified as well. That's also correspondent to my old 
> proposal:
> http://mail.openjdk.java.net/pipermail/swing-dev/2009-December/000878.html
> 
> 4. As the result of item 3 we can generify 
> javax.swing.JComboBox#dataModel like this:
> protected ComboBoxModel<? extends E>    dataModel;
> 
> I remember our discussion about JList model generification:
> http://mail.openjdk.java.net/pipermail/swing-dev/2009-March/000443.html
> 
> So we can improve JList generification as well (it's possible to do 
> without backward incompatibility because of JList generification is a 
> jdk7 feature)
> 
> 5. Some regression tests are needed (like this one 
> http://hg.openjdk.java.net/jdk7/swing/jdk/file/7bcb1864f424/test/javax/swing/JList/6823603/bug6823603.java). 
> We should write them after generification will be fully discussed and 
> coordinated.
> 
> I attached a raw patch that contains all changes that I described above. 
> What do you think about this way of generification?
> 
> Regards, Pavel
> 
> > Hi Pavel,
> >
> > here is a patch to "generify" JComboBox along with: ComboBoxEditor, ComboBoxModel,
> > DefaultComboBoxModel and MutableComboBoxModel.
> >
> > I fixed the BasicComboBoxEditor as I proposed in my last post.
> >
> > MutableComboBoxModel.removeElement is not generified currently and thus still takes an Object as argument. This is consistent with the Collection Framework (eg. java.util.List.remove). Please tell me if you prefer this method to take a generic parameter as well.
> >
> >
> > I also created a new issue in the OpenJDK Bugzilla system:
> > https://bugs.openjdk.java.net/show_bug.cgi?id=100153
> >
> > Regards,
> > Florian
> >   
> 
>