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

[Stuart Marks]

On 10/5/16 10:04 AM, Andrew Haley wrote:
> On 05/10/16 17:55, Vladimir Ivanov wrote:
>>> On 10/5/16 7:39 AM, Justin Sampson wrote:
>>>> 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.
>> Doesn't enhanced deprecation [1] in 9 cover that?
>
> I can't tell.  As far as I can see there is no annotation which
> covers exactly our case:
>
>     the API is flawed and is impractical to fix,
>
>     usage of the API is likely to lead to errors,
>
>     the API has been superseded by another API,
>
>     the API is obsolete,
>
>     the API is experimental and is subject to incompatible changes,
>
>     or any combination of the above.
>
> we'd perhaps need to add
>
>     this method over here is better in most cases
>
> ...which perhaps implies obsolescent rather than obsolete.


(Vladimir, thanks for mentioning JEP 277. [1])

Andrew, all,

The list of criteria from JEP 277 isn't intended to be restrictive. It turns out 
that the criteria for deprecating something are quite subjective, and it's 
really hard to boil them down to specific reasons or attributes or whatever.

To my eye, "has been superseded by" includes "this method over here is better in 
most cases" but I'm sure we could find differences if we went looking for them.

The main contribution of JEP 277 in this area is the addition of the boolean 
forRemoval element to the @Deprecated annotation. If true, it means there is a 
plan to remove the annotated API -- for the JDK, most likely in the next major 
release. If false, it means there are no plans to remove the API at present.

To get back to this specific case, if you're looking over the shoulder of 
someone who's using *FieldUpdater, and your reaction is "you should be using 
VarHandles instead" then that's an argument for deprecating the FieldUpdaters 
with forRemoval=false.

On the other hand, if there are still things you can do with FieldUpdaters that 
you cannot (yet) do with VarHandles or some other construct, that's an argument 
for *not* deprecating the FieldUpdaters (yet).

I'm not familiar enough with the current state of things in this area to make an 
informed recommendation here.

s'marks


[1] http://openjdk.java.net/jeps/277