Defaut methods are not visible if -source 1.7 is set

[Remi Forax]

On 10/29/2013 07:26 PM, Paul Benedict wrote:
> It makes sense to me that -source 1.7 can't see default methods. 
> Really, the issue comes down to: does it makes sense to use a JDK 8 
> compiler to compile JDK 7 source? I never liked the idea of splitting 
> -source/-target. Thankfully, these options will be phased out eventually.
>
> Paul

It's a practical issue, there are lot of codes that compiles using 
-source/-target,
I've always found it was easier to not do that and compiles with the 
latest version
and then retrofit the bytecode (or fail) to the version you want to be 
compatible with.

Rémi

>
>
> On Tue, Oct 29, 2013 at 12:48 PM, Brian Goetz <brian.goetz at oracle.com 
> <mailto: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.
>
>         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.
>
>
>     On 10/29/2013 1: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
>
>
>
>
> -- 
> Cheers,
> Paul