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
