Defaut methods are not visible if -source 1.7 is set
brian.goetz at oracle.com
Tue Oct 29 16:37:10 PDT 2013
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.
> 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.)
More information about the lambda-spec-experts