JDK-6905107 : ListModel of the JList component should be generified as ListModel
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2009-11-26
  • Updated: 2017-05-19
  • Resolved: 2010-01-14
Related Reports
Relates :  
Description
Below is a discussion of it:

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

Comments
PUBLIC COMMENTS We found out that JComboBox cannot be generified as class JComboBox<E>{ ComboBoxModel<? extends E> getModel(); setModel(ComboBoxModel<? extends E>); } There are a couple methods that prevents to do generification in such way: javax.swing.JComboBox#addItem() and javax.swing.JComboBox#insertItemAt() Moreover JTable model cannot be generified with wildcard as well. Therefore the main idea to generify all Swing components in exactly the same way fails. We discussed this situation with Alexander Potochkin and decided to remain generification of JList model as is. I'm closing this CR.
29-11-2010