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

Andrew Haley aph at redhat.com
Wed Oct 5 15:38:22 UTC 2016

On 05/10/16 15:39, Justin Sampson wrote:

> 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().

We're moving Java to support some new ways of working, and these
changes will inevitably mean that some parts of the project will be
obsolescent.  We need to be able to flag the old ways of doing things
in some way.

Deprecation is a way to do that.  I don't think that Thread.stop() is
a typical case.

> 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.

OK.  But we really do need a way to do that.


More information about the core-libs-dev mailing list