On 01/16/2018 09:47 AM, Sergey Bylokhov wrote:
On 08/01/2018 08:25, Semyon Sadetsky wrote:
On 05/01/2018 18:01, Semyon Sadetsky wrote:
Can you explain what is wrong with the suggested approach? It is
flexible to handle both null and non-null containing JList.
Because it is wrong direction try to support some approach which is
undefined behavior. The null has a special meaning in
JList.getSelectedValue/setSelectedValue() as well as in a few other
methods mentioned below. The usage of unspecified null values may
result in a run time exception either immediately or at some later
time.
I didn't find any spec that mentions null as a special value
I already listed a methods which use null as an absent of the value.
And current methods were implemented with this intention.
But JList is fully usable without them.
as well as any pointer that JList couldn't contain null.
There are no references to null in the javadoc which means that null
is unsupported. By default the null value is unsupported, and it can
be considered as supported only if spec accept that.
That is a good argument that proves that null is not considered as a
special value.
getSelectedValue() may not be an indicator because there are several
replacements setSelectedIndex(), setSelectedIndices(),
getSelectedValues(), getSelectedValuesList() which supports null.
Other components are unrelated.
Why JComboBox.setSelectedItem() and JList.setSelectedValue() are
unrelated? Both are quite similar and have similar logic. Moreover
JComboBox.setSelectedItem() has much more detailed description which
we should use as an example.
Those are different type of controls. For example, in JComboBox
setSelectedIndex(-1) clears selection unlike JList. Why you don't
propose to fix the current issue by making setSelectedIndex(-1) clearing
selection in JList?
And JComboBox may contain null as well.
If we look at JFX ListView it may also contain null.
