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

[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?
> 
>