Deprecation is stronger than that -- it says "we're going to remove this, or we wish we could remove it because it's broken, so you'd better change your code a.s.a.p." -- e.g. Thread.stop(). My interpretation of Martin's comment is that using deprecation for things that aren't actually broken just means that people will live with lots of deprecation warnings in their code for years to come. This could be a perfect case for introducing a weaker alternative to deprecation, saying "here's something better that you should really be using for new code" -- e.g. ArrayList vs. Vector. I remember the Guava team talking about that a lot. Don't know if they ever implemented it.
Cheers, Justin -----Original Message----- From: Concurrency-interest [mailto:concurrency-interest-boun...@cs.oswego.edu] On Behalf Of Andrew Haley Sent: Wednesday, October 05, 2016 1:19 AM To: Martin Buchholz; Remi Forax; Paul Sandoz Cc: core-libs-dev; concurrency-interest Subject: Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater On 04/10/16 22:19, Martin Buchholz wrote: > VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet > complete (where is accumulateAndGet?), and when do you deprecate something > when the replacement won't be ubiquitous for 10 years? Surely you have to start somewhere: deprecation is no more than saying to programmers "Don't use this, use that." And if you were leaning over someone's shoulder that's what you would say. Andrew. _______________________________________________ Concurrency-interest mailing list concurrency-inter...@cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest
