Defaut methods are not visible if -source 1.7 is set

[Sam Pullara]

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

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

>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20131029/889f1957/attachment-0001.html