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

Pavel Porvatov Pavel.Porvatov at Sun.COM
Wed Jul 22 13:32:00 UTC 2009


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