<Swing Dev> 6179357: Generics: JList: ListCellRenderer & prototypeCellValue

[Florian Brunner]

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
>>>
>>>
>>
>