Will JDK 8 support SAM that is Abstract Class ?

[Boaz Nahum]

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