Hi Alexander,
Alexander Potochkin schrieb:
Hello Florian
Thank you for the constructive examples!
You're welcome! :-)
I looked at the usage of prototypeCellValue property,
following the JList.updateFixedCellSize() method
Yes, this was the reason for this whole discussion: the list entries and
the prototypeCellValue use the same ListCellRenderer.
If both are of type E, both can use a ListCellRenderer<? super E>
I found this code in the
DefaultListCellRenderer.getListCellRendererComponent():
if (value instanceof Icon) {
setIcon((Icon)value);
setText("");
}
else {
setIcon(null);
setText((value == null) ? "" : value.toString());
}
It means that value always can be an icon,
so we need to do something about that
I already had a short look at DefaultListCellRenderer. I think it has to
be specified something like:
DefaultListCellRenderer implements ListCellRenderer<Object>
since it works for all Objects (toString() ) and Object is a superclass
of Icon. Like this it also fits to ListCellRenderer<? super E> for any
given E and thus should be possible to use it as the default
cellRenderer of JList (which it probably already is, though I can't
check it right now. Somewhere in the UI class?)
I didn't plan to include DefaultListCellRenderer in the first patch, but
can do so, if you prefer.
I also think that shouldn't generify prototypeCellValue,
since it doesn't give as any visible advantage,
This would be option 1) then, because if prototypeCellValue is of type
Object, the ListCellRenderer has to be as well. The value of having a
generified prototypeCellValue is that we can use a generified
ListCellRenderer!
I think it would be a pity if we don't provide a generic ListCellRenderer.
moreover some programmers may use an object of a special type
that toString() method returns something meaningful for
prototypeCellValue
This is still possible with option 3), eg. with JList<Object> or "raw"
JList.
-Florian
Thanks
alexp
Here is a second sample.
It's not really a real-world sample, but should be useful to show
that also JList of other "value" types than String, such as Integer,
Long and Short, can profit from generics.
It also shows why JList should specify
ListCellRenderer<? super E> cellRenderer
rather than
ListCellRenderer<E> cellRenderer
(Here: a common Number-cell renderer is used.)
-Florian
Am Dienstag, 3. März 2009 schrieb Alexander Potochkin:
Hello Tom
It's nice to see you here
Could you please provide a complete example of a JList
with a custom ListCellRenderer that proves that renderer should be
generified
I bet if you used NetBeans to find implementations of ListCellRenderer
even within the JDK most useful implementations would cast the value
argument.
anyway, it is always better to have a fixed set of examples to discuss
(I prefer option 3, btw.)
Thanks
alexp
Tom Hawtin
