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

[Martin Buchholz]

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".