Will JDK 8 support SAM that is Abstract Class ?

[Brian Goetz]

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

Static *methods* are on the radar -- but they're not "default methods", since they can't be overridden.  But, yes.  Though likely not to make the cut for 8.   


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