Different behavior between (F) and (Object & F)

[Maurizio Cimadamore]

Ah right - this gives IllegalAccessErro... this has been on the todo 
list for a while; I think I will take a stab at it since I'm at it.

Thanks
Maurizio


On 08/11/12 15:17, bitter_fox wrote:
> F#clone was provided default implementation.
> My case is:
>
> interface F
> {
>     default Object clone() {}
>
>     void m();
> }
>
> F f = () -> {};
>
> And it now passes compiler and it makes:
>
> class $$lambda$n implements F
> {
>     public void m()
>     {
>         Enclosing.lambdan();
>     }
>
>     // override protected Object clone()
> }
>
> I think () -> {} shouldn't pass compiler
>
> Regards,
> bitter_fox
>
> 2012/11/9 Maurizio Cimadamore <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>>
>
>     Forget my previous email - I know realize what your email is about
>     - should this code work?
>
>     interface F {
>         Object clone();
>     }
>
>     F f = ()->null;
>
>     I think it should - the metafactory will ggenerate a _public_
>     implementation for the clone method - i.e.
>
>     class $$$lambdaClass$$$ implements F {
>         public Object clone() {
>             return null;
>         }
>     }
>
>     Which is legal...
>
>     Maurizio
>
>     On 08/11/12 14:49, Maurizio Cimadamore wrote:
>
>         On 08/11/12 14:40, bitter_fox wrote:
>
>             In this case, the overridden method is F#clone and this is
>             public, and
>             the overriding method is Object#clone and this is not
>             public. This
>             would be compile-time error.
>
>         Strictly speaking this is all true. Javac (and other compilers
>         too) has
>         a tendency to defer this kind of checks. For instance, even
>         w/o lambdas,
>         it is possible to write code like:
>
>         class Foo<X extends Object & F> { }
>
>         Now, should this be illegal? The current view is that we let the
>         type-witness to provide a public overrider for Object's clone.
>
>         So the well-formedness check for intersection types has been
>         historically loose in this respect; right now, javac is
>         re-using the
>         same well-formedness check regardless of whether the
>         intersection type
>         appears as a type-variable bound or as a cast target; this seems
>         reasonable, however it leaves out few cases as you correctly
>         point out.
>         It is very likely that some additional restrictions on
>         intersection
>         types will come out when they are used as a target of a functional
>         expression.
>
>         Maurizio
>
>
>