<Swing Dev> JDK 9 RFR of JDK-8054360: Refine generification of javax.swing

[Joe Darcy]

Hi Sergey,

On 08/16/2014 12:38 PM, Sergey Bylokhov wrote:
> Hello. Joe.
> This change broke the full image build of the client ws.

Oh no!

Sorry about that. I'll look into an immediate fix. A longer term fix 
will probably require some further changes to the swing generification, 
possibly making JSlider raw again.

-Joe

>
> /repool/java_re/builds/workspace/9-2-build-solaris-sparcv9/jdk9-client/1141/jdk/src/closed/share/demo/jfc/SwingSet2/SliderDemo.java:167: 
> error: incompatible types: JLabel cannot be converted to CAP#1
>         s.getLabelTable().put(new Integer(11), new JLabel(new 
> Integer(11).toString(), JLabel.CENTER));
>                                                ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends JComponent from capture of ? extends JComponent
>
>
> On 13.08.2014 2:51, Joe Darcy wrote:
>> *ping*
>>
>> Any other comments here?
>>
>> Thanks,
>>
>> -Joe
>>
>> On 08/07/2014 07:20 PM, Joe Darcy wrote:
>>> Hello,
>>>
>>> Please review my changes for
>>>
>>>     JDK-8054360: Refine generification of javax.swing h
>>> http://cr.openjdk.java.net/~darcy/8054360.3/
>>>
>>> Full patch below.
>>>
>>> This resolves many of the source incompatibility exemplars Jan 
>>> Lahoda found in a corpus of programs using swing.
>>>
>>> A few comments on the changes.
>>>
>>> It seems many existing implementations of the TreeNode interface 
>>> have a covariant override of the old raw
>>>
>>>     Enumeration children();
>>>
>>> method which returns an enumeration of the specific TreeNode 
>>> implementation type. The revised generification of
>>>
>>>     Enumeration<? extends TreeNode> children();
>>>
>>> allows those existing implementations to still compile. This is a 
>>> lower-impact way of allowing those types to still compile compared 
>>> to trying to add a type variable to TreeNode.
>>>
>>> After some expert generics advice from Dan Smith, I but together a 
>>> different generification of
>>>
>>>     src/share/classes/javax/swing/table/DefaultTableModel.java
>>>
>>> which has better source compatibility. Quoting from the changes:
>>>
>>>   73     @SuppressWarnings("rawtypes")
>>>   74     protected Vector<Vector>    dataVector;
>>>   75
>>>   76     /** The <code>Vector</code> of column identifiers. */
>>>   77     @SuppressWarnings("rawtypes")
>>>   78     protected Vector    columnIdentifiers;
>>>   79     // Unfortunately, for greater source compatibility the 
>>> inner-most
>>>   80     // Vector in the two fields above is being left raw. The 
>>> Vector is
>>>   81     // read as well as written so using Vector<?> is not 
>>> suitable and
>>>   82     // using Vector<Object> (without adding copying of input 
>>> Vectors),
>>>   83     // would disallow existing code that used, say, a 
>>> Vector<String>
>>>   84     // as an input parameter.
>>>
>>> The setter methods used for these fields are changes to have 
>>> parameters of type Vector<?> and Vector<? extends Vector>, 
>>> respectively.
>>>
>>> The type Vector<? extends Vector> is the most general type which 
>>> captures the implicit constraint of the dataVector field: it is a 
>>> Vector of other Vectors. (It would probably be possible to update 
>>> dataVector to the somewhat more general Vector<List>, but that would 
>>> require changes to the code in other methods of the class.)
>>>
>>> The changes in 
>>> src/share/classes/sun/tools/jconsole/inspector/TableSorter.java 
>>> change the code back to how it was before the swing generification 
>>> changes went in based on the changes to DefaultTableModel.
>>>
>>> Once the exact generification is settled, I'll file the internal ccc 
>>> paperwork.
>>>
>>> Early feedback on using this revised generification on swing code is 
>>> welcome!
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>
>
>