JEP 277: Enhanced Deprecation

[Lars Vogel]

I completely agree to:
------
The definitions should be made less-JVM/JDK specific. @Deprecated
is of use to everyone.
-------

In Eclipse we have our own annotations like @Noreference and it would
be good if we could also switch at some point to the JRE ones.

Best regards, Lars


On Thu, Oct 29, 2015 at 7:22 PM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> 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



-- 
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email: lars.vogel at vogella.com, Web: http://www.vogella.com