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

[Florian Brunner]

Hi Pavel,

enjoy your holidays! My holidays start from 27th June till 8th July, so we can continue the work on 
generics afterwards again.

-Florian

Am Donnerstag, 11. Juni 2009 schrieb Pavel Porvatov:
> Hi Florian,
>
> > 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.
>
> Sure.
>
> Regards, Pavel
>
> P.S. Note that I have vacation from 15th till 30th June.
>
> > -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?