<Swing Dev> [PATCH] 6179357: Generics: JList

[Pavel Porvatov]

Hi Florian,
> Hi Pavel,
>
> Thanks for the info. I started analyzing this issue some days ago 
> (butI didn't find time to complete the analysis, yet). Up to now I 
> think, too, that it's hard to generify the selected item of a combo 
> box. Still hoping we find a way though. :-/ (it was requested by: 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6303622 )
>
> I can't remember if generifying
> ComboBoxModel.get/setSelectedItem(Object)
> or generifying
> JComboBox.get/setSelectedItem(Object)
> or both was a problem. I will check it. (We need to know this for 
> generifying JComboBox anyway.)
Please run the attached demo. As you can see 
JComboBox.get/setSelectedItem(Object) can operate with any values (not 
only with values from ComboBox items). As you see it is a valid 
situation when the type of the selected value differs from the general 
type of the JComboBox and its model

By the way the spec of the JComboBox.getSelectedItem()
underlines this fact:
    * If the combo box is editable, then this value may not have been added
    * to the combo box with <code>addItem</code>, <code>insertItemAt</code>
    * or the data constructors.

So we shouldn't generify the get/setSelectedItem methods in JComboBox.

The same ideas for the ComboBoxModel class. Below is a part of 
javax.swing.ComboBoxModel javadoc:
   * The selected item may not necessarily be managed by the underlying
   * <code>ListModel</code>. This disjoint behavior allows for the temporary
   * storage and retrieval of a selected item in the model.

Regards, Pavel
>
> -Florian
>
> Pavel Porvatov schrieb:
>> Hi Florian,
>>
>> I prepared a fix for bug 6905107 (see 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6905107) and sent 
>> it for a review. So don't spend time on that issue, please
>>
>> Regards, Pavel
>>> Hi Pavel,
>>>
>>> thanks for pointing this out. I can remember the discussion but not 
>>> Alexander Potochkin's solution. I will check it in detail as soon as 
>>> I find some time.
>>>
>>> -Florian
>>>
>>> Pavel Porvatov schrieb:
>>>> Hi Florian,
>>>>
>>>> I'd like to return to some old discussion:
>>>>> In the case of JComboBox I think it's not even possible to define
>>>>> something like:
>>>>>
>>>>>  class JComboBox<E>{
>>>>>  ComboBoxModel<? extends E> getModel();
>>>>>  setModel(ComboBoxModel<? extends E>);
>>>>>  }
>>>>>
>>>>> because JComboBox internally uses the ComboBoxModel.setSelectedItem
>>>>> method.
>>>>>
>>>>> So the question is what do you think is better:
>>>>>
>>>>> 1) To look at each component individually and try to make each as
>>>>> flexible as possible. So in the JList/ JComboBox case this would 
>>>>> mean:
>>>>>
>>>>>  class JList<E>{
>>>>>  ListModel<? extends E> getModel();
>>>>>  setModel(ListModel<? extends E>);
>>>>>  }
>>>>>
>>>>> but
>>>>>
>>>>>  class JComboBox<E>{
>>>>>  ComboBoxModel<E> getModel();
>>>>>  setModel(ComboBoxModel<E>);
>>>>>  }
>>>>>
>>>>> 2) Make the interfaces as consistent as possible over all components.
>>>>> This would mean for the JList case to use somethink like:
>>>>>  class JList<E>{
>>>>>  ListModel<E> getModel();
>>>>>  setModel(ListModel<E>);
>>>>>  }
>>>>>
>>>>> This approach is slightly less flexible than the approach 1), but 
>>>>> cases
>>>>> where one could benefit from approach 1) are probably rare and 
>>>>> there are
>>>>> various work-arounds (like: wrapping the model/ use a common base 
>>>>> class
>>>>> for the generic parameter/ use raw type/... )
>>>>>
>>>>> So what do you think? Approach 1) or 2)?
>>>> As you remember three people voted for the second variant...
>>>>
>>>> Alexander Potochkin found a third solution that seems better than 
>>>> previous ones.
>>>> 3)
>>>> class JList<E>{
>>>> ListModel<? extends E> getModel();
>>>> setModel(ListModel<? extends E>);
>>>> }
>>>>
>>>> AND
>>>>
>>>> class JComboBox<E>{
>>>> ComboBoxModel<? extends E> getModel();
>>>> setModel(ComboBoxModel<? extends E>);
>>>> }
>>>>
>>>> Below is a quote of his mail, which clarifies possibility of such 
>>>> solution:
>>>> -------------------------------------------------
>>>> I thought a bit more on the generification of the JComobBox and its 
>>>> model and now I am pretty sure that we should not generify
>>>> ComboBoxModel.get/setSelectedItem(Object)
>>>>
>>>> The attached test case illustrates the reason
>>>>
>>>> - Run the test
>>>> - Press enter
>>>> - The selected item will be printed in the console "1" (integer type)
>>>>
>>>> - Write "hello" in the editable combobox
>>>> - Press enter
>>>> - "hello" will be printed (String type)
>>>>
>>>> As you see it is a valid situation when the type of the selected value
>>>> differs from the general type of the JComboBox and its model
>>>>
>>>> By the way the spec of the JComboBox.getSelectedItem()
>>>> underlines this fact:
>>>>
>>>>     * If the combo box is editable, then this value may not have 
>>>> been added
>>>>     * to the combo box with <code>addItem</code>, 
>>>> <code>insertItemAt</code>
>>>>     * or the data constructors.
>>>> -------------------------------------------------
>>>> So, I think we should make a new change for changing generification 
>>>> of JList from ListModel<E> to ListModel<? extends E>. What do you 
>>>> think about that?
>>>>
>>>> Regards, Pavel
>>>>> Great news, thanks!
>>>>>
>>>>> I'll write soon to plan the next steps.
>>>>>
>>>>> -Florian
>>>>>
>>>>> Am Montag, 23. November 2009 schrieb Alexander Potochkin:
>>>>>  
>>>>>> Wow!
>>>>>> Congratulations Pavel & Florian!
>>>>>>
>>>>>> Thanks
>>>>>> alexp
>>>>>>
>>>>>>  
>>>>>>> Hi Florian,
>>>>>>>
>>>>>>> I've got an approve for the fix and committed it:
>>>>>>> http://hg.openjdk.java.net/jdk7/swing/jdk/rev/7bcb1864f424
>>>>>>>
>>>>>>> Thanks for your work,
>>>>>>> Pavel
>>>>>>>       
>>>>
>>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ComboTest.java
Type: text/java
Size: 1056 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20091210/a1bbabf1/ComboTest.java>