[concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

Justin Sampson jsampson at guidewire.com
Wed Oct 5 14:39:10 UTC 2016

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.


-----Original Message-----
From: Concurrency-interest [mailto:concurrency-interest-bounces at 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.


Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu

More information about the core-libs-dev mailing list