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

[Pavel Porvatov]

Hi Florian,

First of all sorry for delay, I was ill.

> 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.)
It's a bad idea to use prototypeCellValue with a type different from 
other values (IMO). Therefore I'm voting for option #3

Regards, Pavel

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