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