<Swing Dev> 6179357: Generics: JList: Constructors & Model

[Florian Brunner]

>> Hello Florian
>>
>> I am sorry if I ask this question too late,
>> but what is the main reason of generifiying these components?
>>
>> It is quite difficult to make it right
>> because we have some difficult to generify public API.
>>
>> If JList and JComboBox are mostly used with Strings values
>> there is an approach #3 - leave them as is
>>
>> Could you provide some test cases that prove
>> the need of generifying those components?
>>
>> Thanks
>> alexp
>>     
>
> I don't use JList/ComboBox/Table mostly with Strings, typically they
> contain domain objects with an appropriate renderer. I'm currently using
> generic ListModels which also implement (most of) the java.util.List
> interface. The generic ListTableModel is similar with an object per row.
> I usually store references to both view and model and use indices to
> retrieve values (with convenience methods on the model like List<T>
> getAll(int[] indices) to use with int[] getSelectedIndices()).
>
>   

Of course, JList/ComboBox/Table etc. are not used only with Strings, but 
also with any other value types (Integer, Long, etc.) and of course many 
(if not most of) the times with domain objects, as mentioned by Walter. 
If you select an entry of eg. a JList, you don't want to get a String 
representation but the actual object. This is about good OO design and 
type safety.

This feature has been requested already many years ago:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6179357
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6303622

and is also one of the main requirements of the recently started Swing 
2.0 project (which, in contrast to the swing-generics project, works 
independently of OpenJDK and doesn't care about 100% backwards 
compatibility, as far as I know):
http://kenai.com/projects/swing2


> Regarding using <E> or <? Extends E>, what I do there is to accept
> List<? extends E> (not a model) in the constructor, but the model is
> always a ListModel<E> to support mutability. See
> http://pastebin.com/f49d4a9b7 for the code.
>
>   
Well, the plan is to have ListModel<E>, but the question is, how should 
it be referenced from JList? (See the discussion history at: 
https://swing-generics.dev.java.net/ )

> A reason I tried a generic JList was be to support generic drag and drop
> between list, storing a Class<T> type so I could do:
> If(type.isInstance(importData)) { model.add(type.cast(importData)); }
> But I'm not sure that is enough reason to make the view generic, as the
> drag and drop classes like DataFlavor, etc would need to be generic as
> well.
> Another reason is that it would be needed for generic renderers - it
> basically comes down to that if you want to use generics, you have to go
> all the way or you still end up casting somewhere.
>
> So since you can use indices, only making the models generic might be an
> easier transition (or as first step to make Swing generic).
>
> Greetings,
> Walter.
>   
Yes, the plan is to "go all the way" to make Swing, as many other parts 
of the Java API, as type safe as possible and limit the need to cast all 
the time (there still will be cases most probably, though). My plan for 
a first patch is to include JList along with ListModel, ListCellRenderer 
etc. (See the discussion history at: https://swing-generics.dev.java.net/ )

-Florian