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

[Florian Brunner]

Hi Pavel,

no problem, I presumably don't have much time in June anyway. Just tell me when there are some news 
about the patch.

-Florian

Am Montag, 1. Juni 2009 schrieb Pavel Porvatov:
> Hi Florian,
>
> I've filed request about changing API according to your fix.
>
> A couple comments:
> 1. Because of J1 approve of changing API can be delayed
>
> 2. We should generify all subclasses of generified classes and
> interfaces in the JDK
>
> 3. One of our developers Alexander Potochkin suggests the next
> generification step:
>
> ---------------
> I'd like to suggest the next generification step
> - ComponentUI and descendants
>
> the fix should be quite simple:
>
> class ComponentUI<C extends JComponent> {
>
>    public void installUI(C c) {
>      }
>
>     public void paint(Graphics g, C c) {
>      }
>
>   // and so on
> }
>
> and then:
>
> class ButtonUI extends ComponentUI<AbstractButton>
>
> it's okay if RadioButtonUI, CheckBoxUI etc...
> will inherit AbstractButton as the generic type,
> because they cast JComponent to AbstractButton anyway
>
> class TableUI extends ComponentUI<JTable> etc...
>
> note that the JComponent subclasses will not be modified
> -------------
>
> Regards, Pavel
>
> > Hi Pavel,
> >
> > as far as I remember, the problem with
> > E[] getSelectedValues()
> >
> > was, that it is not possible to create a generic array.
> >
> > As for:
> > public E[] getSelectedValues(E[] a)
> >
> > you can get this array already with
> > getSelectedValuesList().toArray(array)
> >
> > Of course, the other way around would work, too, but since lists should
> > generally be preferred to arrays for various reasons (see item 25 of
> > Joshua Bloch's book "Effective Java", 2nd edition, for some of them), I
> > think we should prefer
> >
> > List<E> getSelectedValuesList()
> >
> > over
> >
> > E[] getSelectedValues(E[] a)
> >
> > As for deprecating the original getSelectedValues() method:
> > It's not absolutly needed, but then we would have 2 methods, which would
> > do pretty much the same. This could confuse users, which one to use. By
> > deprecating the old one, we tell users that for new code, lists and
> > generics are preferred. They still can get an array when needed without
> > getting a deprecated warning, by calling one of the toArray-methods.
> >
> > And since people are complaining, that the Swing API is already bloated
> > (eg. see the Swing 2.0 discussions at
> > http://kenai.com/projects/swing2/lists ), I think it's a good thing to
> > reduce the API by deprecating methods, if there are other methods which
> > should be preferred.
> >
> > -Florian
> >
> >> Hi Florian,
> >>
> >> Some time ago we discussed two different ways to add the new method
> >> "getSelectedValuesList()". The first one is the current implementation
> >> in your fix:
> >>
> >> 1. public List<E> getSelectedValuesList()
> >> Benefits:
> >>    a. easy to use
> >>    b. Collection framework is very flexible
> >>
> >> The second way is:
> >>
> >> 2. public E[] getSelectedValues(E[] a)
> >> Benefits:
> >>    a. The same pattern used in the java.util.Collection#toArray(T[] a)
> >> method
> >>    b. a little bit easer to port an old code
> >>
> >> Also a lot of people noticed that there is no need to deprecate the
> >> javax.swing.JList#getSelectedValues method because it still can be
> >> useful.
> >>
> >> Any ideas?
> >>
> >> Regards, 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?