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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Nov 8 09:53:46 PST 2012


On 08/11/12 16:29, Maurizio Cimadamore wrote:
> 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.
Fixed now - the compiler now applies the same check in both cases.

Maurizio
> 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
>>
>>
>>
>



More information about the lambda-dev mailing list