Defaut methods are not visible if -source 1.7 is set

[Brian Goetz]

So, this is an argument to get rid of -source entirely.  But if we did 
that, people would HOWL.

On 10/29/2013 8:02 PM, Sam Pullara wrote:
> 1) I don't believe this one. The chances are much higher that you
> accidentally use a method that didn't exist in the previous version.
> 2) you can run your compiled code from an old JDK on the latest JVM.
>
> Sam
>
> ---
> Sent from Boxer
> On Tue, Oct 29, 2013 at 07:37 PM, Brian Goetz wrote:
>> Reason 1: The new compiler often has bugfixes that have not always been
>> backported to older compilers.
>>
>> Reason 2: Lots of shops want to run on the latest JVM (to get
>> performance or serviceability improvements) but not necessarily on the
>> latest language level ("I haven't trained all my people on 'Strings in
>> switch' yet.") So people upgrade to a recent JDK but want to prevent
>> new language features from leaking into their source base.
>>
>> On 10/29/2013 6:07 PM, Sam Pullara wrote:
>> > Why would you want to use the new compiler if you have the old one on
>> > the machine? I'm not really understanding the use case for the
>> > bootclasspath version.
>> >
>> > Sam
>> >
>> > ---
>> > Sent from Boxer
>> > On Tue, Oct 29, 2013 at 05:54 PM, Joseph Darcy wrote:
>> >>
>> >> On 10/29/2013 12:16 PM, Dan Smith wrote:
>> >> > On Oct 29, 2013, at 12:31 PM, Remi Forax wrote:
>> >> >
>> >> >> On 10/29/2013 06:48 PM, Brian Goetz wrote:
>> >> >>> 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.
>> >> >> There is already a warning for that, if you compile -source 1.7
>> >> -target 1.7 with javac,
>> >> >> you will have a warning saying that you have to set the
>> >> bootclasspath to a 1.7 rt. jar
>> >> > I've made this point before, but do note that other libraries on the
>> >> classpath are not subject to this constraint or warning.
>> >> >
>> >>
>> >> And at least some parties do not use javac's bootclasspath mechanism to
>> >> limit the core API that the compiled code uses; a third party API
>> >> checking tool is used instead. In such workflows, by design the javac
>> >> check is circumvented. (I don't necessary think this is a good
>> workflow,
>> >> but it is being used.)
>> >>
>> >> -Joe
>> >>