Defaut methods are not visible if -source 1.7 is set

[Remi Forax]

On 10/29/2013 07:19 PM, Joe Darcy wrote:
> On 10/29/2013 10:48 AM, Brian Goetz 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.
>>
>>> spec shoud be changed to say that adding a default implementation
>>> is not a compatible change
>>
>> There's no way we're doing this to work around a tooling bug.
>
> IMO, the current behavior of javac is the least-bad option.
>
> (The issue before was how AnnotatedElement.isAnnotationPresent should 
> be handled. It was a Java SE 5 method on AnnotatedElement that was 
> turned into a default. The behavior of javac meant that the method 
> "disappeared" from the implementations of the interface, like 
> java.lang.Class, for code being compiled under earlier source 
> versions. We addressed this by adding back concrete implementations in 
> the interface implementations that called back to the default method. 
> That means the method appears present in all source versions and we 
> still get some sharing of the implementation code.)

Yes I understand the details but I disagree with the premise, it's not 
the least bad-option
because it means that Iterator.remove or any abstract method which is 
converted from an abstract method to a default method
not working with javac8 -source 1.7.

Default methods are abstract with -source 1.7 is more appealing to me.

>
> There is no specification that governs how a compiler should present 
> new-in-8 language features when compiling under a older-than-8 source 
> level. More generally, the -source and -target options are not 
> required parts of the platform specification, just a convenience to 
> developers.
>
> -Joe
>

Rémi