JEP 211: Elide Deprecation Warnings on Import Statements

[Eddie Aftandilian]

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> wrote:

> On 10/16/2014 1:44 AM, Florian Weimer wrote:
>
>> On 10/16/2014 02:32 AM, mark.reinhold at oracle.com wrote:
>>
>>> New JEP Candidate: 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141017/fba45153/attachment.html>