Defaut methods are not visible if -source 1.7 is set

[Remi Forax]

On 10/29/2013 08:14 PM, Dan Smith wrote:
> 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

yes, great idea.
the implementing vs using comes to my mind but I did not think that the 
policy can be different.

Rémi