hg: lambda/lambda/langtools: Bug fixes:

[Brian Goetz]

Almost certainly, but the details are not yet specified.

The defender method doc describes some needed reflection changes but is almost 
certainly not complete.  (In particular, we have not yet determined whether to 
describe defended methods as being non-abstract, or to choose another term.)

On 8/19/2010 12:52 PM, Collin Fagan wrote:
> 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
> <mailto: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
>         <mailto: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
>                         <mailto: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
>
>
>
>
>
>
>
>
>
>
>