hg: lambda/lambda/langtools: Bug fixes:

[Collin Fagan]

Thank you for the clarification. The original question was about if a method
with a defender can be the target of a SAM type correct? That answer is 'no'
correct? And this is becouse once you give a method a defender it is no
longer 'abstract'. Would this have ramifications on reflection, specifically
what gets returned from getModifiers()?

Thanks,
Collin

On Thu, Aug 19, 2010 at 10:52 AM, Brian Goetz <brian.goetz at oracle.com>wrote:

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