Defaut methods are not visible if -source 1.7 is set

[David M. Lloyd]

The primary benefit was already somewhat messed up by 1.7: the ability 
to write code that runs on an old JDK *but* detect and use new APIs when 
possible.  But that doesn't really work anymore.  Now you pretty much 
have to stub in manually hacked up weird hybrid classes to do this, 
which is unfortunate.

On 10/29/2013 07:04 PM, Brian Goetz wrote:
> 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
>>> >>


-- 
- DML