<Swing Dev> 6303622: Generics: JComboBox: get/setSelectedItem(Object)

[Ricardo Garcia]

In the example I attached in the previous thread:
- Generified editable combobox was supported *if* the generic class had a
constructor: new XXX(String s). It is easy to modify it to accept an empty
contructor plus a setter method setName(String s) or whatever
- That solution used ComboBoxModelExtended<I>, so the model was generified.
I dont see any advantage in defining <? extends E> instead. Could you
specify them?

Besides I dont see the point in creating a read-write combobox where the
items are not either specific objects (that contains the special
method/contructor) or strings.

I see more advantages to generifying them than not.

--
Ricardo


On Tue, Dec 15, 2009 at 5:36 PM, Pavel Porvatov <Pavel.Porvatov at sun.com>wrote:

> Hi Florian,
>
>> Hi Pavel,
>>
>> I start here a new thread for the "get/setSelectedItem(Object) methods of
>> JComboBox and ComboBoxModel" discussion.
>>
>> After further analysis of the code and your sample application I think we
>> can and should generify the get/setSelectedItem(Object) methods of JComboBox
>> and ComboBoxModel.
>>
>> Yes, the Javadoc says that JComboBox/ ComboBoxModel supports selected
>> values not managed by the underlying list model. But this does not prohibit
>> to optionally limit the type by using generics und thus to increase type
>> safety.
>> If you need to allow other types from editor than the ones in the list
>> model, you still can use:
>> JComboBox<Object> (or JComboBox, but this is not recommended)
>>
>> So there should be no backward compatibility problem.
>>
>> When using a JComboBox, usually you are interested in the selected value
>> and since you want to do something with it you expect it to have some
>> specific type. So if we generify the get/setSelectedItem(Object), you can
>> profit from that in most cases.
>>
>> Even in cases where you have an initial text in an editable combo box you
>> can profit from that, if you use a "null" value as the selected value, which
>> according to the API is used for "no selection", and a custom editor for
>> rendering that null value. (see attachement; I used your sample application
>> as a base; delete the text to set the selected value to null again).
>>
>>
> I agree that generification of the get/setSelectedItem(Object) methods will
> be useful. But than we will have another generification disadvantage. I
> tried to summarize benefits of two solutions below.
>
> *Generified get/setSelectedItem:*
> a. Simplified usage read-only comboboxes or non read-only comboboxes with
> special editor
>
> b. Disadvantage: if you use generified editable combobox *without* editor
> then ClassCastException will be thrown in runtime
>
> *Not generified get/setSelectedItem:*
> a. A possibility to generify the javax.swing.JComboBox#dataModel as
> ComboBoxModel<? extends E>. It give us more flexible usage of ComboBox:
>
> ComboBoxModel<Integer> cbModel = ....;
> JComboBox<Number> cb = new JComboBox<Number>(cbModel);
>
> Note that it's the main benefit that forced us to suggest not generified
> methods
>
> b. To use not read-only combobox with generified model
>
>
> So I believe that not generified get/setSelectedItem methods give more
> benefits and less disadvantages.
> What do you think about that?
>
> Regards, Pavel
>



-- 
Chipu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20091215/f9c8a47f/attachment.html>