Defaut methods are not visible if -source 1.7 is set

[Dan Smith]

On Oct 29, 2013, at 11:48 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> We discussed this extensively at some point; its not as simple as this, though I admit the details are paging in slowly.
> 
> IIRC, the root problem is this: you have a class
> 
> class Foo extends List { }
> 
> that you want to compile with the 1.8 javac but with -source 1.7.  What could happen?
> 
> 1.  You could fail to compile, because the supertype uses language/VM features you don't support.  This would be not very nice.
> 
> 2.  You could force the user to implement the default methods, since we can't assume they're inherited.  This is also not very nice.
> 
> 3.  We could ignore them.
> 
> The root problem is that -source 1.7 still exposes 1.8 libraries to the compilation, which is just wrong.  What should happen is we should be compiling with the fictitious -platform 1.7, which not only enforces the 1.7 language level, but also puts the 1.7 JDK classes on the bootclasspath.
> 
> Eventually, modularity was supposed help here.  At the time, (3) seemed the least bad alternative.  But this is indeed a problem for methods that acquire defaults.

The problem is that _implementing_ an interface is a different use case than _using_ an interface.

(3) makes sense for the "implementing" case.

In the "using" case, the most convenient thing would be for all methods to be visible.

Remi's concern is focused on the "using" case, while the current behavior of javac is focused on the "implementing" case.

I don't know how hard it would be to get javac (or some other tool) to treat the two cases differently, although it seems reasonably achievable...

—Dan