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

[Florian Brunner]

Hi Pavel,

great to see on the list. I hope you feel well again.

I think all voted for option #3 now (correct me if I'm wrong), so let's go for option #3.

-Florian

Am Mittwoch, 11. März 2009 schrieb 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