JEP 277: Enhanced Deprecation

[Stephen Colebourne]

I agree with the basic concept of enhancing deprecation. Just trying
to focus on the detail.

1) CONDEMNED. A very strong name, and it seems to me that condemned is
not a "reason" at all. Instead, I propose that a new method is added -
toBeRemovedIn() - returning a string, with similar semantics to the
proposed since() method. When this method returns a non-empty value,
the method/class can be considered to be "condemned". As such, there
is no need for the CONDEMNED reason code.

2) EXPERIMENTAL. Does not really feel like it should be part of
@Deprecated at all.

3) Removing CONDEMNED and EXPERIMENTAL might mean the reason() method
can only return one code.

3) Methods to update. How about java.util.Date and java.util.Calendar?
:-)  And the constructors on String/Boolean/Integer/Double etc

4) The definitions should be made less-JVM/JDK specific. @Deprecated
is of use to everyone.

Stephen


On 29 October 2015 at 11:43, David M. Lloyd <david.lloyd at redhat.com> wrote:
> On 10/28/2015 03:24 PM, mark.reinhold at oracle.com wrote:
>>
>> New JEP Candidate: http://openjdk.java.net/jeps/277
>
>
> A couple of comments.
>
> Firstly, this seems highly JDK-centric and/or seems (in some respects) to
> revolve around specific policies related to the JDK.  Some of the enum
> values in fact go so far as to reference JDK releases.
>
> Secondly, the enums seem to range from categories of deprecation (i.e.
> relating to the future of the class/member) to characterizations of the
> behavior of the class/member in question.
>
> It seems like this might be better accomplished with multiple annotations,
> perhaps some being JDK-internal (e.g. CONDEMNED).  If a non-JDK-specific
> annotation for "condemnation" (man, that's a really harsh term) is desired,
> it's probably best to put that information in (ideally in a JSR-376 style
> version string) to the annotation e.g. @ScheduledForRemovalIn("10").
>
> I think "experimental" should be its own annotation.  The reason is the
> development lifecycle of a method, which might go experimential ->
> (supported) -> deprecated -> (removed), optionally skipping any number of
> steps along the way.  While things might be both experimental and
> deprecated, they have inherently different meanings.
>
> I don't have any clear thoughts about DANGEROUS or UNIMPLEMENTED, except
> that they just generally don't feel like a proper fit for some reason. The
> fact that UNSPECIFIED is necessary is possibly a clue into this.
>
> --
> - DML