55

JCombobox in Java 7 has been updated to use generics - I always thought it was a bit of an oversight that it didn't already so I was pleased to see this change.

However, when attempting to use JCombobox in this way, I realised that the methods I expected to use these generic types still just return Object.

Why on earth is this? It seems like a silly design decision to me. I realise the underlying ListModel has a generic getElementAt() method so I'll use that instead - but it's a bit of a roundabout way of doing something that appears like it could have been changed on JComboBox itself.

Michael Berry
  • 70,193
  • 21
  • 157
  • 216
  • 2
    maybe http://forums.oracle.com/forums/thread.jspa?threadID=2266782&tstart=0 +1 for Java7 – mKorbel Aug 11 '11 at 13:01
  • @mKorbel Perhaps I'm missing something, but what part of the thread explains it? – Michael Berry Aug 11 '11 at 13:07
  • in APIs I can't see changes between Java6 and Java7 for that http://download.oracle.com/javase/7/docs/api/javax/swing/JComboBox.html#setSelectedItem%28java.lang.Object%29 , nor for http://download.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode%28%29 – mKorbel Aug 11 '11 at 13:36

2 Answers2

65

I suppose you refer to getSelectedItem()?

The reason is that if the combo box is editable, the selected item is not necessarily contained in the backing model and not constrained to the generic type. E.g. if you have an editable JComboBox<Integer> with the model [1, 2, 3], you can still type "foo" in the component and getSelectedItem() will return the String "foo" and not an object of type Integer.

If the combo box is not editable, you can always defer to cb.getItemAt(cb.getSelectedIndex()) to achieve type safety. If nothing is selected this will return null, which is the same behaviour as getSelectedItem().

Duncan Jones
  • 67,400
  • 29
  • 193
  • 254
jarnbjo
  • 33,923
  • 7
  • 70
  • 94
  • Ah, that makes a lot of sense - after a memory lapse I forgot about the editable side of JComboBoxes. Most probably because none of them are editable in my application! The method you describe there is what I have been using instead - it seemed like a roundabout way of doing it but now I see why. – Michael Berry Aug 11 '11 at 14:01
  • You don't need to be sure an item is selected. If `getItemAt` is given an invalid value (e.g. -1), it returns `null`. This is the same behaviour as `getSelectedItem()` if nothing is selected. – Duncan Jones Apr 23 '13 at 12:47
  • @DuncanJones: You are right. Without checking, I assumed that getItemAt would throw an IllegalArgumentException, IndexArrayOutOfBoundsException or something like that if invoked with an invalid index. – jarnbjo Apr 23 '13 at 20:06
  • @jarnbjo It's definitely unusual behaviour. I would add a comment to my code if I were ever to rely on it. – Duncan Jones Apr 24 '13 at 06:25
  • If I had an editable combo box that I wanted to constrain to , I think that it's reasonable to expect that I can only type in a custom value if it's a valid integer. So I would have preferred them to give us some kind of convertor interface to convert the string to and from the types in the combo box. But for some reason, whoever designed the API wasn't fond of type safety. They didn't update JFormattedTextField either. – Hakanai Oct 04 '16 at 05:19
1

Here is a type-safe version:

public static <T> T getSelectedItem(JComboBox<T> comboBox)
{
    int index = comboBox.getSelectedIndex();
    return comboBox.getItemAt(index);
}
BullyWiiPlaza
  • 17,329
  • 10
  • 113
  • 185