Draft JEP: Elide deprecation warnings on import statements

[Martijn Verburg]

+1 - would be nice to eliminate false positives in large code bases (like
PCGen)

Cheers,
Martijn


On 6 February 2014 06:26, Jeremy Manson <jeremymanson at google.com> wrote:

> Agree with Stephen.  At Google, we've recently made the decision to stop
> issuing warnings about these in our internal builds.
>
> Jeremy
>
>
> On Wed, Feb 5, 2014 at 2:50 PM, Stephen Colebourne <scolebourne at joda.org>wrote:
>
>> This happens in pretty much all large codebases over time and would be
>> a welcome change IMO.
>> Stephen
>>
>> On 5 February 2014 20:20, Joe Darcy <joe.darcy at oracle.com> wrote:
>> > Hello,
>> >
>> > Below is the text of a draft JEP we are considering submitting for JDK
>> 9.
>> >
>> > Cheers,
>> >
>> > -Joe
>> >
>> >
>> > Summary
>> > -------
>> >
>> > As of Java SE 8, java compilers are required by reasonable
>> > interpretations of the Java Language Specification to issue
>> > deprecation warnings when a deprecated type is imported by name or
>> > when a deprecated member (method, field, nested type) is imported
>> > statically. These warnings are uninformative and should not be
>> > required. Deprecation warnings at actual uses of deprecated members
>> > should remain.
>> >
>> > Goals
>> > -----
>> >
>> > The goal of this JEP is to facilitate making large code bases clean of
>> > lint warnings. The deprecation warnings on imports cannot be
>> > suppressed using the @SuppressWarnings annotation, unlike uses of
>> > deprecated members in code. In large code bases like that of the JDK,
>> > deprecated functionality must often be supported for some time and
>> > merely importing a deprecated construct does not justify a warning
>> > message if all the uses of the deprecated construct are intentional
>> > and suppressed.
>> >
>> > Non-Goals
>> > ---------
>> >
>> > It is not a goal of this JEP to actually resolve all the deprecation
>> > warnings in the JDK code case. However, that might occur as part of a
>> > separate maintenance effort in JDK 9.
>> >
>> > Description
>> > -----------
>> >
>> > From a specification perspective, the needed change is small. In JLS 7
>> > (text in JLS 8 will be similar), the section on @Deprecated states:
>> >
>> > "A Java compiler must produce a deprecation warning when a type,
>> > method, field, or constructor whose declaration is annotated with the
>> > annotation @Deprecated is used (i.e. overridden, invoked, or
>> > referenced by name), unless:
>> >
>> >     * The use is within an entity that is itself annotated with the
>> >       annotation @Deprecated; or
>> >
>> >     * The use is within an entity that is annotated to suppress the
>> >       warning with the annotation @SuppressWarnings("deprecation"); or
>> >
>> >     * The use and declaration are both within the same outermost class."
>> >
>> > The specification change would be something like adding another bullet
>> > stating the additional exclusion:
>> >
>> >     * The use is within an import statement.
>> >
>> > In the javac reference implementation, there would be a simple check
>> > to skip over import statements when looking for deprecation warnings.
>> >
>> > Testing
>> > -------
>> >
>> > Normal unit tests should suffice to test this feature. A handful of
>> > JCK tests may need to be updated for the changed specification.
>> >
>> > Impact
>> > ------
>> >
>> >   - Other JDK components: The change would ease getting and keeping
>> >      the JDK code base free of deprecations warnings.
>> >   - Compatibility: Since warning will be issued in fewer cases, there is
>> > negligible compatibility impact.
>> >   - User experience: Fewer uninformative warnings will be issued by the
>> > compiler.
>> >   - TCK: As noted earlier, a handful of JCK test may need updating.
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140210/33bc7d3a/attachment.html