hg: lambda/lambda/langtools: Bug fixes:

[Brian Goetz]

No.  You can be a SAM target and have defender methods:

interface Printerator<T> extends Iterable<T> {
     public void printAll() default Util.printAll();
}

Here, Printerator is a SAM (it extends Iterable, which is SAM) but adds more 
defended methods.  That is OK, and adding more defended methods does not 
undermine its SAM-ness.  Removing the defenders would, but that is a binary 
incompatible change just as re-abstracting a concrete method is.

On 8/19/2010 11:31 AM, Collin Fagan wrote:
> So you can be a SAM target OR use defender methods, but not both. That
> sounds rather limiting, why would anyone purposefully choose defender
> methods when it eliminates the possibility of ever using an interface as a
> SAM type? What about inherited methods? Does extending an interface that
> uses defender methods disallow SAM conversion?
>
> Sorry just confused.
>
> On Thu, Aug 19, 2010 at 9:42 AM, Peter Levart<peter.levart at marand.si>wrote:
>
>> I just noticed that this would not solve the problem, since the following
>> transformation:
>>
>> public interface UncleSam {
>>    extension BigDecimal calculateTaxes(String taxPayerId) default Tax.calc;
>>     BigDecimal calculateSomethingElse(String taxPayerId);
>> }
>>
>> into:
>>
>> public interface UncleSam {
>>    extension BigDecimal calculateTaxes(String taxPayerId) default Tax.calc;
>>     extension BigDecimal calculateSomethingElse(String taxPayerId) default
>> Tax.calc2;
>> }
>>
>> would allways change a SAM type into a non-SAM type.
>>
>> Peter
>>
>> On 08/19/10, Peter Levart wrote:
>>> It's only for consistency if nothing else. Currently, for all other
>> purposes, adding a default to a normal interface method (transforming it to
>> a defender method) is a source and binary compatible change. Not with SAM
>> interfaces though.
>>>
>>> What would be wrong with this definition of SAM types:
>>>
>>> SAM type is a reference type with a single non-Object abstract
>> non-defender method and any number of abstract defender methods or a
>> reference type with a single abstract defender method and no non-Object
>> abstract non-defender methods.
>>>
>>>
>>> Regards, Peter
>>>
>>> On 08/19/10, Brian Goetz wrote:
>>>> I say no.  This is a Zero Abstract Method (ZAM) type :)
>>>>
>>>>
>>>> On 8/19/2010 9:00 AM, Peter Levart wrote:
>>>>> On 08/19/10, maurizio.cimadamore at oracle.com wrote:
>>>>>> Changeset: ce46b6012362
>>>>>> Author:    mcimadamore
>>>>>> Date:      2010-08-19 13:11 +0100
>>>>>> URL:
>> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ce46b6012362
>>>>>>
>>>>>> Bug fixes:
>>>>>> *) check that the compiler emits meaningful diagnostics when the
>> lambda body contains bad statements
>>>>>> *) the routine that checks for SAM types should skip defender
>> methods in extended interfaces
>>>>>
>>>>> I don't know, but should this extended interface be considered a SAM
>> type or not?
>>>>>
>>>>> public interface UncleSam {
>>>>>     extension BigDecimal calculateTaxes(String taxPayerId) default
>> Tax.calc;
>>>>> }
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>
>>>>>> *) failure of regression test CheckExamples.java depending on
>> localization settings
>>>>>>
>>>>>> ! src/share/classes/com/sun/tools/javac/code/Types.java
>>>>>> ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
>>>>>> ! test/tools/javac/diags/examples/IllegalChar.java
>>>>>> + test/tools/javac/lambda/BadStatementInLambda.java
>>>>>> + test/tools/javac/lambda/BadStatementInLambda.out
>>>>>> + test/tools/javac/lambda/Defender01.java
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>