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

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