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

[Brian Goetz]

So far, this thread has been mostly "I DON'T LIKE THIS CHANGE." But 
let's talk about a real underlying issue instead, mkay?

While no one has actually said this (I guess everyone was too busy 
slinging rhetoric and raising strawman objections) there is at least one 
real issue here, which is:

  - I have a library
  - I want it to be free of deprecation warnings
  - I want it to compile cleanly on platform versions N...N+k, where 
something is deprecated with an alternative in M>N, and the alternative 
does not exist in N.

That leaves the hypothetical library provider above (which I assume is 
Stephen's situation, though it was left unsaid) with some bad choices:
  - @SuppressWarnings the use everywhere
  - Compile without deprecation warnings
  - Have multiple sourcebases

I think the real issue is that @SuppressWarnings is too blunt a tool to 
be useful in this situation, so deprecation causes collateral pain for 
library developers.  If we can make the deprecation more painless for 
this class of developers (the ones disproportionately affeted), then I 
think much of the noise goes away.

On 4/27/2016 1:42 AM, Stuart Marks wrote:
> On 4/26/16 3:43 AM, Stephen Colebourne wrote:
>> In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this
>> would be painful and add no value.
>
> Hi Stephen,
>
> I just sent a reply [1] to Kevin B, wherein I clarified "rename."
>
> Briefly, it strictly isn't a rename. The old method would be 
> deprecated not-for-removal, and would be left in place indefinitely.
>
> Does this still create pain? If so, is there some way the proposal can 
> be modified to reduce it?
>
> s'marks