<Swing Dev> 6179357: Generics: JList: Constructors & Model

Alexander Potochkin Alexander.Potochkin at Sun.COM
Tue Feb 24 17:37:15 UTC 2009


Hello Florian

I am sorry if I ask this question too late,
but what is the main reason of generifiying these components?

It is quite difficult to make it right
because we have some difficult to generify public API.

If JList and JComboBox are mostly used with Strings values
there is an approach #3 - leave them as is

Could you provide some test cases that prove
the need of generifying those components?

Thanks
alexp


> 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)?
> 
> -Florian
> 
> Am Donnerstag, 19. Februar 2009 schrieb Florian Brunner:
>> Well, there is probably no big issue with JList, because the ListModel is
>> immutable.
>>
>> But when we add generics to JComboBox, which is similar to JList, the
>> situation is a bit more controversial, because the ComboBoxModel is
>> mutable.
>>
>> So if we have something like this:
>> class JComboBox<E>{
>> ComboBoxModel<? extends E> getModel();
>> setModel(ComboBoxModel<? extends E>);
>> }
>>
>> then something like this is not possible:
>> JComboBox<Foo> cb = new JComboBox<Foo>(...);
>> ...
>> Foo foo;
>> ComboBoxModel<? extends Foo> model = cb.getModel();
>> model.setSelectedItem(foo); -> compile time error
>>
>> You would need to do an unchecked (-> not type-safe) cast first:
>> ComboBoxModel<Foo> model = (ComboBoxModel<Foo>) cb.getModel();
>>
>> And type-safty is what generics is all about.
>>
>> -Florian
>>
>> Am Dienstag, 3. Februar 2009 schrieb Pavel Porvatov:
>>> Hi Florian,
>>>
>>>> ----------------------------------------
>>>>
>>>> public JList(ListModel dataModel)
>>>>
>>>> {
>>>>
>>>> if (dataModel == null) {
>>>>
>>>> throw new IllegalArgumentException("dataModel must be non null");
>>>>
>>>> }
>>>>
>>>> // Register with the ToolTipManager so that tooltips from the
>>>>
>>>> // renderer show through.
>>>>
>>>> ToolTipManager toolTipManager = ToolTipManager.sharedInstance();
>>>>
>>>> toolTipManager.registerComponent(this);
>>>>
>>>> layoutOrientation = VERTICAL;
>>>>
>>>> this.dataModel = dataModel;
>>>>
>>>> selectionModel = createSelectionModel();
>>>>
>>>> setAutoscrolls(true);
>>>>
>>>> setOpaque(true);
>>>>
>>>> updateUI();
>>>>
>>>> }
>>>>
>>>> --->
>>>>
>>>> public JList(ListModel<E> dataModel)
>>>>
>>>> {
>>>>
>>>> if (dataModel == null) {
>>>>
>>>> throw new IllegalArgumentException("dataModel must be non null");
>>>>
>>>> }
>>>>
>>>> // Register with the ToolTipManager so that tooltips from the
>>>>
>>>> // renderer show through.
>>>>
>>>> ToolTipManager toolTipManager = ToolTipManager.sharedInstance();
>>>>
>>>> toolTipManager.registerComponent(this);
>>>>
>>>> layoutOrientation = VERTICAL;
>>>>
>>>> this.dataModel = dataModel;
>>>>
>>>> selectionModel = createSelectionModel();
>>>>
>>>> setAutoscrolls(true);
>>>>
>>>> setOpaque(true);
>>>>
>>>> updateUI();
>>>>
>>>> }
>>>>
>>>> We could define the signature also like this:
>>>>
>>>> public JList(ListModel<? extends E> dataModel)
>>>>
>>>> but then we would have to define the dataModel-field also with:
>>>>
>>>> private ListModel<? extends E> dataModel
>>>>
>>>> as well as the model-property. I don't think this would be a good idea
>>>> and thus define the signature as:
>>>>
>>>> public JList(ListModel<E> dataModel)
>>>>
>>>> What do you think?
>>> Why do you think that "private ListModel<? extends E> dataModel" is not
>>> a very good idea?
>>>
>>> Regards, Pavel
> 
> 




More information about the swing-dev mailing list