JEP 277: Enhanced Deprecation

[Sebastian Sickelmann]

Hi,

thanks for starting work on this topic. Would love to help to implement
some parts of this proposal.  

I have some questions and comments:

As some of previous writers suggested I also think it is worth not to
handle this in a too JDK-centric way.
Maybe it can be divided in two topics:
1. the Deprecation API, static analysis-tools and the Runtime Checks
2. the usages of those in the jdk. We maybe should also run the jtreg
tests with Runtime Deprecation Warning enabled and fail tests in them
until the test is marked with a specific tag.


Runtime (Call-time / Link-Time)
===================
I am not sure if is possible to do the checks at linking/resolution time?
It would be nice for all that does not have a test-suite that uses most
of the used path through code.
I think a link-time check can show more hits than a call-time
(calling/using of deprecated elements) solution. And link-time checks
can also show less false-positives that a static analysis-tool.

But i think a link-time checking is more memory-space-intensive than a
call-time checks, because of the fact that you can link against an
interface and the implementation of it can be deprecated and not loaded
at link-time of the use of an interface-method.  Link time checking is
more complex to implement but I think call-time-checking is more
runtime-intensive.

I am not sure if it is possible (JLS / JVMS) to do eager linking at
loadtime of a class when -verbose:deprecation is specified.
When doing link-time checks the special case of invokedynamic must be
handled too. The implementation is heavely call-time based. I am not
sure if it is spec compatible to also do eager linking of invokedynamic?

Nevertheless I think warning printings should be done after bootstrap
method (Indy) is finished. The alternative of this is to integrating
this in the

MethodHandles.Lookup, but I think it is allowed for a bootstrap method
to create MethodHandles that are deprecated and then do not use them in
the returned and linked methodhandle, so this would lead to some more
false positives.

Recursion
======
Is is a good idea to recursively apply deprecation-information and thus
pull those information to the call-sites. Recursion could stop at a
@Stable annotation. So library providers could use @Deprecated API and
mark there implementation with a @Stable to give some guarantees to the
users of the library.



For all thinks there seems always a choice between "find all possible
cases" and "limit  the false positives", which seems to me to be an
important part for the adoption in the community.


-- Sebastian

On 10/28/2015 09:24 PM, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/277
>
> - Mark
>