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