JEP 211: Elide Deprecation Warnings on Import Statements

[Alex Buckley]

Great feedback. I think the import of non-deprecated static members of a 
deprecated type should continue to generate warnings, so that the 
use-by-simple-name of the imported static members continues to _not_ 
generate warnings.

It looks like we want to distinguish:

   import z.Bar;  // No warning please, because simple uses of Bar get 
warnings (unless suppressed).

from:

   import [static] z.Bar.$MEMBER;  // Warning please, because simple 
uses of $MEMBER don't get warnings.

That is possible by sharpening the proposed spec change from:

   * The use is within an import statement.

to:

   * The use is within an import statement that imports the type or 
member whose declaration is annotated with @Deprecated.

To be clear, 'import z.Bar.B;' contains a use of the deprecated type 
Bar, and the use is NOT within an import statement importing the 
@Deprecated Bar, so the warning is NOT turned off.

For completeness, suppose B's declaration is made @Deprecated, and Bar's 
declaration is still @Deprecated. 'import z.Bar.B;' contains a use of 
the deprecated type Bar, and the logic above still applies (warning NOT 
turned off) ... it also contains a use of the deprecated member B within 
an import statement importing that very member B, so the warning IS 
turned off. But don't worry - now that B's declaration is @Deprecated, 
the simple name 'B' throughout Foo will give a warning.

Alex

On 10/17/2014 10:35 AM, Eddie Aftandilian wrote:
> I wanted to pass along something that Kevin Bourrillion pointed out:
>
>     I've now realized it's less simple than this.  Javac doesn't seem to
>     propagate deprecation status down the containment tree.  That is,
>     for example, deprecating a class doesn't cause members of the class
>     to be treated as deprecated. So in code like the following, the
>     imports are actually the /only/ things generating a warning!
>
>     package z;
>     import static z.Bar.a;
>     import z.Bar.B;
>     class Foo {
>        public static void main(String[] args) {
>          a(); // expect a warning
>          B b = null; // expect a warning
>          b = new B(); // expect a warning
>          b.c(); // expect a warning
>        }
>        void foo(B b) {} // expect a warning
>        B bar() { return null; } // expect a warning
>     }
>     @Deprecated // should cascade to all members
>     class Bar {
>        public static void a() {}
>        public static class B {
>          public static void c() {}
>        }
>     }
>
>     So now I think that if they only elide the warnings from imports but
>     don't fix this as well, it would actually be worse than doing
>     nothing, as this code above would start compiling cleanly.
>     Yet just making deprecation propagate could cause a huge upsurge in
>     the number of warnings people get, so I don't know what the right
>     answer is.
>
>
> On Thu, Oct 16, 2014 at 9:27 AM, Joe Darcy <joe.darcy at oracle.com
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     On 10/16/2014 1:44 AM, Florian Weimer wrote:
>
>         On 10/16/2014 02:32 AM, mark.reinhold at oracle.com
>         <mailto:mark.reinhold at oracle.com> wrote:
>
>             New JEP Candidate: http://openjdk.java.net/jeps/__211
>             <http://openjdk.java.net/jeps/211>
>
>
>         Would it make sense to suppress then warning on an import
>         statement only if (a) there are uses of this import statement
>         and (b) all these uses are annotated with @Deprecated?
>
>         Or is this too complicated and we should rely on the existing
>         unused-import warning?
>
>
>     I believe relying on existing unused imports warnings is sufficient
>     in this case.
>
>     Cheers,
>
>     -Joe
>
>