https://stackoverflow.com/questions/17956556
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianIt's a bug: the culprit is a null ObjectToStringConverter in decorating a textComponent with the items of a JList, using the two-parameter method:
public static void decorate(JList list, JTextComponent textComponent) {
decorate(list, textComponent, null);
}
A quick fix is to use the three-parameter method and pass-in the default converter:
JTextComponent test = new JTextField(20);
String[] data = {"one", "two", "three", "four"};
JList dataList = new JList(data);
AutoCompleteDecorator.decorate(dataList, test, ObjectToStringConverter.DEFAULT_IMPLEMENTATION);
Filed Issue #1570 - fixed as of revision #4305
Morning Musings (can safely be ignored :-)
The technical reason is improper constructor chaining: inserting the default should be handled by the do-it-all constructor (alternatively it should throw a NPE)
public ListAdaptor(JList list, JTextComponent textComponent) {
this(list, textComponent, ObjectToStringConverter.DEFAULT_IMPLEMENTATION);
}
public ListAdaptor(JList list, JTextComponent textComponent, ObjectToStringConverter stringConverter) {
this.list = list;
this.textComponent = textComponent;
this.stringConverter = stringConverter;
// when a new item is selected set and mark the text
list.addListSelectionListener(this);
}
The underlying reason is a subtle shift in ownership of the converter: its usual owner is the custom document which handles the autoComplete, this document guards itself against a null. With a JList variant, its the ListAdaptor which is not accustomed to that burden ... The shift is not incorrect (in fact, the exact way to go), just introduces an ever so slight inconsistency which is easy to overlook.
