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

[Erik Lundqvist]

I still say option 3 since what we are trying to achieve here is to make the
every day use of Swing easier by introducing generics. If that is the case
we should try and make the more common use cases easier and it would be
acceptable to have the more uncommon ones slightly more cumbersom to
perform. The use of prototypeCellValue would in my opinion belong to the
latter category.

2009/3/5 Florian Brunner <fbrunnerlist at gmx.ch>

> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090306/fc43e376/attachment.html>