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

[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
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Test.java
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20101123/ca19e39f/Test.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk7.patch
Type: text/x-patch
Size: 15188 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20101123/ca19e39f/jdk7.patch>