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
