Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30

[Joe Darcy]

Hi Andrej,

On 09/17/2014 12:53 AM, Andrej Golovnin wrote:
> Hi Joe,
>
> I have tested JDK 9b30 with my project and I still have compile 
> errors. I have a code which looks like this:
>
> class BeanNode extends DefaultMutableTreeNode {
>  ...
> }
>
> @SuppressWarnings("unchecked")
> private void aMethod() {
>     BeanNode node = ....
>     ....
>     Enumeration<BeanNode> children = node.children();
>     ...
> }
>
> The compiler reports for this code following error:
>
> error: incompatible types: Enumeration<TreeNode> cannot be converted 
> to Enumeration<BeanNode>
>
> because the DefaultMutableTreeNode defines the method #children() as:
>
> public Enumeration<TreeNode> children() {
>    ...
> }

The ability to alllow children method to be overriden with a covariant 
override was one of the major fixes in the generification refinement. 
However, that was done in the TreeNode interface, but not propagated 
down to the DefaultMutableTreeNode implementation of TreeNode.

If this issue with DefaultMutableTreeNode is common, we can consider 
making an analogous change there too to have children return an 
Enumeration<? extends TreeNode> rather than Enumeration<TreeNode>.

Thanks,

-Joe

> Best regards,
> Andrej Golovnin
>
> On Wed, Sep 17, 2014 at 6:11 AM, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hello swing developers,
>
>     In response to the earlier call for feedback on the initial swing
>     generification changes, several bugs were filed and fixed:
>
>         JDK-8054360: Refine generification of javax.swing
>     https://bugs.openjdk.java.net/browse/JDK-8054360
>
>         JDK-8055254: Address source incompatability of JSlider
>     generification
>     https://bugs.openjdk.java.net/browse/JDK-8055254
>
>     These fixes are now present in JDK 9 b30:
>
>     https://jdk9.java.net/download/
>
>     Please give b30 a try when recompiling your favorite swing code
>     base and report on how the refined generification works.
>
>     Thanks,
>
>     -Joe
>
>     On 8/5/2014 9:25 AM, Joe Darcy wrote:
>
>         Hello,
>
>         A quick follow-up, I've filed
>
>             JDK-8054360: Refine generification of javax.swing
>         https://bugs.openjdk.java.net/browse/JDK-8054360#comment-13532821
>
>         to tweak the generification of TreeNode and possibly a few
>         other types.
>
>         Thanks for the feedback,
>
>         -Joe
>
>         On 7/30/2014 7:54 AM, Joe Darcy wrote:
>
>             Hi Andrej and Martijn,
>
>             Thanks for responding.
>
>             On 7/28/2014 5:04 AM, Andrej Golovnin wrote:
>
>                 Hi Joe,
>
>                 I'm not sure if it is what you are looking for.
>
>
>             For context, the general evolution policy of the JDK:
>
>             http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy
>             <http://cr.openjdk.java.net/%7Edarcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy>
>
>
>             includes "avoid introducing source incompatibilities." As
>             this is a large generification change to swing, some level
>             of source incompatibility may be acceptable in a platform
>             release like JDK 9, but if there are very widespread
>             issues, some of the changes may be reconsidered.
>
>             The request to try out the changes was to get enough
>             information to see if any (partial) reconsideration was
>             warranted.
>
>
>                 But I tried to compile my project with the new build.
>                 And I got a compile error in one of my classes. I have
>                 a class which implements the TreeNode interface and
>                 looks like this:
>
>                 class MyTreeNode implements TreeNode {
>                 ....
>                     @Override
>                     public Enumeration<MyTreeNode> children() {
>                         return ....;
>                     }
>                 ...
>                 }
>
>                 The error message is: "return type
>                 Enumeration<MyTreeNode> is not compatible with
>                 Enumeration<TreeNode>".
>
>
>                 because the DefaultMutableTreeNode defines the method
>                 #children() as:
>
>                 public Enumeration<TreeNode> children() {
>                    ...
>                 }
>
>                 If I change (see attached patch) the definition of the
>                 children()-method in the TreeNode-interface to:
>
>                 public interface TreeNode {
>                 ...
>                     Enumeration<? extends TreeNode> children();
>                 ...
>                 }
>
>                 then my code compiles.
>
>
>             That design issue was raised during code review:
>
>             http://mail.openjdk.java.net/pipermail/swing-dev/2014-June/003643.html
>
>             "It was not immediately clear how
>             javax.swing.tree.TreeNode.children(),
>             which returns a raw Enumeration, should be generified. I
>             changed it to
>
>                  Enumeration<TreeNode> children();
>
>             and that seems to work fine. Something like
>
>                  Enumeration<? extends TreeNode>
>
>             with a covariant override would save a few casts in a private
>             implementation, but generally doesn't seem to be a good
>             trade-off since
>             many normal clients could be inconvenienced dealing with
>             the wildcard."
>
>             If generified subclasses of TreeNode are common, the
>             generification of children may need reconsideration.
>
>
>                 BTW, a good test for your changes would be to try to
>                 compile NetBeans and/or IntelliJ IDEA using the new
>                 JDK 9 build. They both are really big Swing
>                 applications which make use maybe of all Swing APIs.
>
>
>
>             My preference would be for the NetBeans and IntelliJ teams
>             to do that task :-)
>
>             Thanks,
>
>             -Joe
>
>
>
>