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