Just to clarify:
The downside of option 3) is that if you want an arbitrary Object as
prototypeCellValue, then you need to specify something like
JList<Object> or "raw" JList, and would in this case loose the benefit
of the generified JList. (If it's another superclass of E, you can limit
that loss a bit.)
In contrast: with option 1) you can always benefit from a generified
JList (from the entries getter point of view) but you can never really
benefit from a generified ListCellRenderer, which would be a pity, I
think. (Unsafe casts - see the samples)
Option 2) is somewhere in between: you can always benefit from a
generified JList (from the entries getter-methods point of view - the
first parameter) and can sometimes also benefit from a generified
ListCellRenderer (the second parameter).
-Florian
Florian Brunner schrieb:
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
