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

[Stuart Marks]

On 4/26/16 2:55 PM, Brian Goetz wrote:
> Stepping back a bit ... one of the most frequent complaints we get is "mistakes
> never get fixed".  So, we've decided to be more serious about deprecation -- Dr.
> Deprecator is suiting up!  But that means, for any given item, some people are
> going to disagree about whether deprecation is suitable, and some will be
> inconvenienced by the deprecation -- this is unavoidable.
> ...
> I'd like to see it fixed, and the sooner the better.

Thanks Brian.

I should probably offer a mea culpa of my own, which is that I just started 
pumping out webrevs without providing any context. For some of the previous ones 
this hasn't been a big deal, but this most recent one has turned into an 
unpleasant surprise for several of you.

JEP 277 (Enhanced Deprecation) is not only about refining the @Deprecated 
annotation itself, but employing it to deprecate things that have needed to be 
deprecated for quite a long time. I've been working a list of such things for 
some time. So what I'll do is set aside the Optional.get() webrev for the moment 
and start a new thread for discussion of the deprecation list. This should give 
people a chance to see what we're trying to do, and to assess the impact of 
deprecating things and how to assess the tradeoffs in doing so, independently of 
any particular webrev.

I'll try to get this out in the next day or so. I'll send it here 
(core-libs-dev) since all the things on the list so far fall within the core 
libs area.

s'marks