Defaut methods are not visible if -source 1.7 is set

[Stephan Herrmann]

In terms of coordinating the behavior of javac and the Eclipse compiler
I'm happy this issue has been raised here.
I couldn't see any real conclusion, yet. Did I miss a relevant post?
How do you think a compiler at -source 1.7 *should* handle default methods?

Here's another example from an earlier instance of this discussion:

Compile at -source 1.8:

   public interface I {
      default void foo() {}
   }

and consuming the .class of the above compile at -source 1.7:

   public class CI implements I {
     void test(I i) {
       this.foo();
       i.foo();
     }
   }

 From two calls to the same method, javac (all versions) flags one:

CI.java:3: error: cannot find symbol
       this.foo();
           ^
   symbol: method foo()
1 error

Will this be the final behavior of javac?

For comparison, the Eclipse compiler (beta) currently reports only this:

         public class CI implements I {
                      ^^
The type CI must implement the inherited abstract method I.foo()
----------
1 problem (1 error)

Whereas the latest release version reports nothing.

Stephan


On 10/29/2013 06:26 PM, Remi Forax wrote:
> This is from enhanced-metadata-spec-discuss mailing list
> but I think this issue can interest this audience because it seems
> that javac doesn't respect the spec we have drafted or the spec has changed without me noticing it.
> Anyway there is a discrepancy somewhere.
>
>  From Joe Darcy:
>
>>> Wouldn't this risk the same issues as when we turned isAnnotationPresent() into a default?
>>>
>>>
>>
>> No; we don't have the same hazard here as with isAnnotationPresent. The issue we ran into with making isAnnotationPresent a
>> default method was that isAnnotationPresent was part of the original AnnotatedElement interface defined way back in Java SE 5. In
>> implementation decision in javac did not expose the existence of default methods to code being compiled under source levels less
>> than 8. That is a pragmatic choice and usually gives the desired result, but not in this case.
>>
>
> So it seems that javac 8 doesn't see default methods if source level is 1.7 (-source 1.7)
> and as Joe notice this hamper to transform any existing abstract method to a default method.
>
> I'm pretty sure that we have talked about that and said that adding default to a method should be
> source compatible when we have discussed about Iterator.remove.
> Otherwise it goes against the intuition that providing a body to an existing abstract method is harmless.
>
> So either javac8 implementation is not correct (BTW, javac7 see default methods)
> or the spec shoud be changed to say that adding a default implementation is not a compatible change
> and Iterator.remove should be re-abstracted.
>
> regards,
> Rémi
>