<Swing Dev> [PATCH] 6179357: Generics: JList

[Pavel Porvatov]

Hi Florian,

> Hi Pavel,
> 
> I don't understand, what exactly you want to do. DefaultListCellRender 
> implements ListCellRenderer<Object>, which means it is an 
> implementation, which can be savely (without risking a 
> ClassCastException) be used with ANY object. That is due the fact, that 
> it checks if it is an instance of Icon or else calls Object.toString, 
> which is defined for any Object:
> 
> if (value instanceof Icon) {
>        setIcon((Icon)value);
>        setText("");
>    }
>    else {
>        setIcon(null);
>        setText((value == null) ? "" : value.toString());
>    }
Ok, that code actually prevents to use generics in the 
DefaultListCellRender class.

Thanks, Pavel

> 
> There is no gain in calling eg.:
> new DefaultListCellRender<Foo>()
> 
> because the existing implementation (DefaultListCellRender implements 
> ListCellRenderer<Object>) already handles Foo.
> 
> The only limitation is with sub-classing: Subclasses cannot change the 
> parameter type.
> But this can be solved with using composition instead of inheritance, eg:
> 
> public class FooRenderer implements ListCellRenderer<Foo>{
>    private DefaultListCellRender defaultRenderer = new 
> DefaultListCellRender();
> 
> public Component getListCellRendererComponent(
>        JList<? extends Foo> list,
>        Foo value,
>        int index,
>        boolean isSelected,
>        boolean cellHasFocus)
>    {
>        doSomethingWithFoo(foo);
>        return defaultRenderer.getListCellRendererComponent(list, value, 
> index, isSelected, cellHasFocus);
>    }
> 
>  private void doSomethingWithFoo(Foo foo){
>      // do something
>  }
> }
> 
> So, I think the answer is yes, it could be changed, but I see no real 
> benefit and more, client code needs then to specify a parameter, which 
> currently it doesn't.
> 
> -Florian
> 
> Pavel Porvatov schrieb:
>> Hi Florian,
>>
>> I have a question about the DefaultListCellRenderer class. Can we 
>> modify it to use generics?
>>
>> Thanks, Pavel
>>
>>> Hi Pavel, hi Alexander,
>>>
>>> I'm back from holiday.
>>>
>>> What is the status of this patch? Any news?
>>>
>>> -Florian
>>>
>>> Alexander Potochkin schrieb:
>>>> Hello Florian
>>>>
>>>>> Great! :-)
>>>>>
>>>>> In the case of other issues please note that I'm on holiday until 
>>>>> the end of next week.
>>>>
>>>> Have a nice holiday!
>>>>
>>>> (I am reviewing the fix right now)
>>>>
>>>> Thanks
>>>> alexp
>>>>
>>>>>
>>>>> -Florian
>>>>>
>>>>> Pavel Porvatov schrieb:
>>>>>> Hi Florian,
>>>>>>
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>> I agree that we should avoid to mix several different fixes in 
>>>>>>> one fix, but since in this fix we change
>>>>>>>
>>>>>>> AbstractListModel to AbstractListModel<E>
>>>>>>> and
>>>>>>> JList(ListModel dataModel) to JList(ListModel<E> dataModel)
>>>>>>>
>>>>>>> I think we should also change usages of AbstractListModel  such 
>>>>>>> as "this (new AbstractListModel()...)" to "this (new 
>>>>>>> AbstractListModel<E>()...)" to avoid warnings.
>>>>>> Ok, then it will not be a problem. Let's include this change in 
>>>>>> your fix. Therefore all my comments are gone and I'm going to 
>>>>>> start our internal process to commit your fix.
>>>>>>
>>>>>> Thanks, Pavel.
>>>>>>
>>>>>>>
>>>>>>> If you don't agree:
>>>>>>> There are several places where I changed the usage of now 
>>>>>>> generified classes to the generic variant. Which ones should I 
>>>>>>> change back? Only this case?
>>>>>>
>>>>>
>>>>
>>>
>>
>