Will JDK 8 support SAM that is Abstract Class ?

[Ricky Clarkson]

That's exactly what I'm doing to Functional Java.  Only static methods
cause a problem (are static defenders on the radar?).  Final methods
becoming defender methods is a little concerning because they can then
be overridden.

All classes, including Object, have a constructor.  Object's just
doesn't do anything.

On Mon, Nov 5, 2012 at 2:52 PM, Boaz Nahum <boaznahum at gmail.com> wrote:
> Do you think converting adapter class
>
>     class TransitionHandler {
>
>          String getName() { return null; }
>
>          abstract void noTransition();
>      }
>
> to interface:
>     interface TransitionHandler {
>
>          String getName() default { return null; }
>
>          void noTransition();
>      }
>
> abuse the "Defender Methods" idea ? Do you see any problem with this ?
>
> And why can't the compiler deduce that no ctor is involved ? (I hope no one
> plans to add ctor to Object ?)
>
> Thanks
> Boaz
>
>
>
>
>
>
> On Mon, Nov 5, 2012 at 7:13 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> On 11/05/2012 04:08 PM, Boaz Nahum wrote:
>> > Does it mean that all 'old' inner classes extending adapters cant be
>> > converted to lambda(assuming converting the adapter to SAM)?
>> > Please say no: (
>>
>> We drop that support because an abstract class has a constructor (at
>> least one)
>> that can observe the creation of the lambda so it defeat most of the
>> optimizations
>> that the VM can do.
>>
>> The other problem was to deal with abstract class with a constructor
>> that may throw an exception
>> because again, the construction of the lambda is observable.
>>
>> You can still retrofit your code to use lambda using delegation instead
>> of inheritance.
>> By example:
>>
>> abstract class Foo<T> {
>>    Foo() {
>>       // some side effects
>>    }
>>    public abstract void m(T element);
>> }
>>
>> Foo<String> foo = new Foo<String>() {
>>    public void m(String s) {
>>      // lambda code
>>    }
>> };
>>
>> can be retrofitted to:
>>
>> class Foo<T> {
>>    private final Block<? super T> block;
>>    Foo(Block<? super T> block) {
>>       this.block = block;
>>       // some side effects
>>    }
>>    public void m(T element) {
>>      block.apply(element);
>>    }
>> }
>>
>> Foo<String> foo = new Foo<String>((String s) -> {
>>    // lambda code
>> });
>>
>>
>> >
>> > Thanks
>> > Boaz
>>
>> Cheers,
>> Rémi
>>
>> > On Nov 5, 2012 5:01 PM, "Reinier Zwitserloot" <reinier at zwitserloot.com>
>> > wrote:
>> >
>> >> It was part of the original plan, but I believe non-interface SAMs have
>> >> been dropped. I'm guessing because it was difficult to handle the
>> peculiars
>> >> of working with MethodHandles and not actually making a new instance of
>> the
>> >> SAM type.
>> >>
>> >>   --Reinier Zwitserloot
>> >>
>> >>
>> >>
>> >> On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum <boaznahum at gmail.com> wrote:
>> >>
>> >>> I can't find what the spec is saying, but I remember that Abstract
>> class
>> >>> with one abstract method is also SAM.
>> >>>
>> >>> Currently in b63 I got java: incompatible types: the target type must
>> be a
>> >>> functional interface
>> >>>
>> >>> Will it be supported in the future ?
>> >>>
>> >>> Thanks
>> >>> Boaz
>> >>>
>> >>>
>>
>>
>>
>