<div dir="ltr">Agree with Stephen.  At Google, we&#39;ve recently made the decision to stop issuing warnings about these in our internal builds.<div><br></div><div>Jeremy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, Feb 5, 2014 at 2:50 PM, Stephen Colebourne <span dir="ltr">&lt;<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

This happens in pretty much all large codebases over time and would be<br>
a welcome change IMO.<br>
<span class="HOEnZb"><font color="#888888">Stephen<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 5 February 2014 20:20, Joe Darcy &lt;<a href="mailto:joe.darcy@oracle.com">joe.darcy@oracle.com</a>&gt; wrote:<br>
&gt; Hello,<br>
&gt;<br>
&gt; Below is the text of a draft JEP we are considering submitting for JDK 9.<br>
&gt;<br>
&gt; Cheers,<br>
&gt;<br>
&gt; -Joe<br>
&gt;<br>
&gt;<br>
&gt; Summary<br>
&gt; -------<br>
&gt;<br>
&gt; As of Java SE 8, java compilers are required by reasonable<br>
&gt; interpretations of the Java Language Specification to issue<br>
&gt; deprecation warnings when a deprecated type is imported by name or<br>
&gt; when a deprecated member (method, field, nested type) is imported<br>
&gt; statically. These warnings are uninformative and should not be<br>
&gt; required. Deprecation warnings at actual uses of deprecated members<br>
&gt; should remain.<br>
&gt;<br>
&gt; Goals<br>
&gt; -----<br>
&gt;<br>
&gt; The goal of this JEP is to facilitate making large code bases clean of<br>
&gt; lint warnings. The deprecation warnings on imports cannot be<br>
&gt; suppressed using the @SuppressWarnings annotation, unlike uses of<br>
&gt; deprecated members in code. In large code bases like that of the JDK,<br>
&gt; deprecated functionality must often be supported for some time and<br>
&gt; merely importing a deprecated construct does not justify a warning<br>
&gt; message if all the uses of the deprecated construct are intentional<br>
&gt; and suppressed.<br>
&gt;<br>
&gt; Non-Goals<br>
&gt; ---------<br>
&gt;<br>
&gt; It is not a goal of this JEP to actually resolve all the deprecation<br>
&gt; warnings in the JDK code case. However, that might occur as part of a<br>
&gt; separate maintenance effort in JDK 9.<br>
&gt;<br>
&gt; Description<br>
&gt; -----------<br>
&gt;<br>
&gt; From a specification perspective, the needed change is small. In JLS 7<br>
&gt; (text in JLS 8 will be similar), the section on @Deprecated states:<br>
&gt;<br>
&gt; &quot;A Java compiler must produce a deprecation warning when a type,<br>
&gt; method, field, or constructor whose declaration is annotated with the<br>
&gt; annotation @Deprecated is used (i.e. overridden, invoked, or<br>
&gt; referenced by name), unless:<br>
&gt;<br>
&gt;     * The use is within an entity that is itself annotated with the<br>
&gt;       annotation @Deprecated; or<br>
&gt;<br>
&gt;     * The use is within an entity that is annotated to suppress the<br>
&gt;       warning with the annotation @SuppressWarnings(&quot;deprecation&quot;); or<br>
&gt;<br>
&gt;     * The use and declaration are both within the same outermost class.&quot;<br>
&gt;<br>
&gt; The specification change would be something like adding another bullet<br>
&gt; stating the additional exclusion:<br>
&gt;<br>
&gt;     * The use is within an import statement.<br>
&gt;<br>
&gt; In the javac reference implementation, there would be a simple check<br>
&gt; to skip over import statements when looking for deprecation warnings.<br>
&gt;<br>
&gt; Testing<br>
&gt; -------<br>
&gt;<br>
&gt; Normal unit tests should suffice to test this feature. A handful of<br>
&gt; JCK tests may need to be updated for the changed specification.<br>
&gt;<br>
&gt; Impact<br>
&gt; ------<br>
&gt;<br>
&gt;   - Other JDK components: The change would ease getting and keeping<br>
&gt;      the JDK code base free of deprecations warnings.<br>
&gt;   - Compatibility: Since warning will be issued in fewer cases, there is<br>
&gt; negligible compatibility impact.<br>
&gt;   - User experience: Fewer uninformative warnings will be issued by the<br>
&gt; compiler.<br>
&gt;   - TCK: As noted earlier, a handful of JCK test may need updating.<br>
&gt;<br>
</div></div></blockquote></div><br></div>