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

[Pavel Porvatov]

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