Will JDK 8 support SAM that is Abstract Class ?

[Boaz Nahum]

Sorry for nagging

That what I', trying to say. Object has a constructor that does nothing. So
it has no side effect.
Does is still "defeat most of the optimizations that the VM can do" ?


On Mon, Nov 5, 2012 at 8:00 PM, Ricky Clarkson <ricky.clarkson at gmail.com>wrote:

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