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

Florian Brunner fbrunnerlist at gmx.ch
Mon Aug 31 22:31:08 UTC 2009


Hi Pavel,

any news about my patch? What is the status? I understand that approving of the API is not a quick 
step, but then it's already 2-3 months. And we need to do the same for all the other planed API-
changes to "generify" Swing. It would be great if we could speed things up a bit again.

What do you estimate, how much more time this step takes?

Thanks.
-Florian

Am Mittwoch, 22. Juli 2009 schrieben Sie:
> Hi Florian,
>
> > Hi Pavel,
> >
> > I hope you had nice holidays.
> >
> > Do you have any news about the patch?
>
> I'm awaiting approve of API changes. It's not a very quick step because
> a lot of people should take a look at your changes and give approve for
> it...
>
> Regards, Pavel
>
> > -Florian
> >
> > Am Freitag, 19. Juni 2009 schrieb 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?





More information about the swing-dev mailing list