RFR(m): 8140281 deprecate Optional.get()

[Peter Levart]

On 05/11/2016 06:32 PM, Martin Buchholz wrote:
> On Wed, May 11, 2016 at 9:17 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Martin,
>>
>>
>>
>> On 05/11/2016 05:59 PM, Martin Buchholz wrote:
>>> On Wed, May 11, 2016 at 12:05 AM, Peter Levart <peter.levart at gmail.com>
>>> wrote:
>>>> Couldn't this new @Deprecated.since annotation attribute play a role
>>>> here?
>>>> For example, if you are building with JDK 9 javac, but specify -release 8
>>>> option, then you don't get deprecation warning for methods annotated with
>>>> @Deprecated(since = "9").
>>> It helps, but ... the library maintainer and the invoker of javac are
>>> not the same, so a conscientious (and omniscient and indefatigable)
>>> library maintainer will still add @SuppressWarnings to their jdk6+
>>> library the day it is @Deprecated in jdk9.
>>>
>>> We could add something like @TargetedRelease, which java has
>>> historically been reluctant to do.
>>> Compare with API conformance macros in C
>>> #define _XOPEN_SOURCE 500
>>> placed at the top of every source file.
>>
>> I don't think you are making sense. Are you saying that the library
>> maintainer will not the be only person that will be compiling library
>> sources to produce binary artifacts? That one guy may want to compile the
>> library sources on the JDK 6 platform and some other guy may want to compile
>> the same sources on the JDK 9 platform?
> It's surely possible to combine many jar files, each compiled for
> their own target platform, perhaps by their maintainer.
> But in my part of the world it's much more common to collect all the
> java sources for a java program and compile them all in a single javac
> invocation, with a single target release.  In part because people
> don't trust "binary blobs".

Ok, that makes sense now. We seem to live in different parts of the 
world ;-)

Regards, Peter