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

[Alexander Potochkin]

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>

it makes sense

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

Yes please

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

Using the "raw" types is not an option for me,
we should never use raw types of generified objects
or encourage programmers to use them

JList<Object> is fine, so I also vote for the option #3

Thank you
alexp

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