hg: lambda/lambda/langtools: Bug fixes:
Collin Fagan
collin.fagan at gmail.com
Thu Aug 19 08:31:34 PDT 2010
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
> > > >>
> > > >>
> > > >>
> > > >
> > >
> >
> >
>
>
More information about the lambda-dev
mailing list