Diamond with anonymous classes: invoking non-private methods through reflection

[Alex Buckley]

On 6/4/2015 7:04 AM, Georgiy Rakov wrote:
> Hello,
>
> new feature about diamond with anonymous classes demands every
> non-private method declared in the anonymous class to override some
> method from its super type, otherwise compiler error occurs. I
> understand the intention of it which is specified in this comment
> <https://bugs.openjdk.java.net/browse/JDK-8073593?focusedCommentId=13622512&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13622512>:
>
>     When the diamond form is used, the inferred type arguments may not
>     be as anticipated by the programmer. Consequently, the supertype of
>     the anonymous class may not be as anticipated, and methods declared
>     in the anonymous class may not override supertype methods as
>     intended. Treating such methods as if annotated with @Override (if
>     they are not actually annotated with @Override) helps avoid silently
>     incorrect programs.
>
> And this looks reasonable because when some method is declared in the
> anonymous class the only purpose of declaring it as non-private seems to
> be overriding since the method cannot be invoked from outside of the
> anonymous class, at least by the language means. But another purpose
> still exists, namely, invoking such method through reflection by some
> framework. For that purpose it actually becomes impossible to declare
> non-private method in the anonymous class instance created with diamond
> unless such method is declared in its super type.
>
> Could you please tell if you have considered such use case and see it as
> a shortcoming or maybe not that serious one?

If you declare a method in an anonymous class as private, then you're 
not bound by the must-override rule, but since the rule isn't a bad 
rule, there's no reason to go private just to escape the rule. Simply 
use the same (non-private) access level in your method declaration as 
the method in the superclass. No-one can override your non-private 
method anyway. Of course many people can invoke your non-private method 
by referring to its signature in the superclass.

What if a framework vendor wants to reflectively invoke non-private 
methods of anonymous classes "directly", without referring to methods in 
any superclasses? I guess the vendor has told their users to declare 
non-private non-overriding methods in anonymous classes in order for the 
framework to call them back occasionally. Probably the framework detects 
such methods via the presence of framework-specific annotations. Of 
course this will still work -- we are not proposing to change 
j.l.r.Method::invoke to insist on must-override for non-private methods 
in anonymous classes -- but it means the users can't write the diamond 
form in source. I think this is an acceptable limitation.

Alex