Hi Florian,
I just found out that we cannot generify model as ComboBoxModel<?
extends E>, so skip the item 4, please (see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6905107 for details)
Regards, Pavel
Hi Pavel,
Thanks for your response. I will have a look at it.
Regards,
Florian
Am Dienstag 23 November 2010 10:58:15 schrieb Pavel Porvatov:
Hi Florian,
I have several comment about your patch:
1. Run an attached test, enter some text (e.g. "aa") and press enter.
The text disappears, but if you reenter text it stays.
2. The following changes in the
javax.swing.plaf.basic.BasicComboBoxEditor#getItem() looks strange for
me, could you describe them please?
+ if (oldValue instanceof String) {
+ return (E) newValue;
+ } else {...
BTW: The code "Method method = cls.getMethod("valueOf", new
Class[]{String.class});" and other stuff like that were added with the
fix of CR 4239610
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4239610). That code
looks strange for me, I believe the check
"newValue.equals(oldValue.toString())" is enough for that bug...
Moreover the "valueof" method cannot be used as a universal solution for
String->AnyClass conversion because of that's impossible to use in case
oldValue is null.
Therefore I think we should not change the WindowsComboBoxUI.java,
ComboBoxEditor.java, BasicComboBoxEditor.java and
MetalComboBoxEditor.java files at all, because there are no available
API for converting string into *any* class. What do you think about
that? Logically it means that editor can edit only strings but not any
class.
3. After item 2 we will see that it's not possible to generify the
set/getSelectedItem methods in the javax.swing.ComboBoxModel interface
because of some code in the javax.swing.JComboBox#actionPerformed
method. The same set/getSelectedItem methods in the JComboBox class
shouldn't be generified as well. That's also correspondent to my old
proposal:
http://mail.openjdk.java.net/pipermail/swing-dev/2009-December/000878.html
4. As the result of item 3 we can generify
javax.swing.JComboBox#dataModel like this:
protected ComboBoxModel<? extends E> dataModel;
I remember our discussion about JList model generification:
http://mail.openjdk.java.net/pipermail/swing-dev/2009-March/000443.html
So we can improve JList generification as well (it's possible to do
without backward incompatibility because of JList generification is a
jdk7 feature)
5. Some regression tests are needed (like this one
http://hg.openjdk.java.net/jdk7/swing/jdk/file/7bcb1864f424/test/javax/swing/JList/6823603/bug6823603.java).
We should write them after generification will be fully discussed and
coordinated.
I attached a raw patch that contains all changes that I described above.
What do you think about this way of generification?
Regards, Pavel
Hi Pavel,
here is a patch to "generify" JComboBox along with: ComboBoxEditor,
ComboBoxModel,
DefaultComboBoxModel and MutableComboBoxModel.
I fixed the BasicComboBoxEditor as I proposed in my last post.
MutableComboBoxModel.removeElement is not generified currently and thus still
takes an Object as argument. This is consistent with the Collection Framework
(eg. java.util.List.remove). Please tell me if you prefer this method to take a
generic parameter as well.
I also created a new issue in the OpenJDK Bugzilla system:
https://bugs.openjdk.java.net/show_bug.cgi?id=100153
Regards,
Florian
