Hi Pavel,
I hope you had nice holidays.
Do you have any news about the patch?
-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?
