<Swing Dev> [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module

[Phil Race]

Hi,
You did not provide a direct reference to the set of warnings that were 
generated.
fortunately I found it here :- 
https://bugs.openjdk.java.net/browse/JDK-8066622

A couple of things I find 'unfortunate' are
1) In order to avoid a deprecation warning on one call/line of a 100 
line method,
the entire method is subject to the annotation. Eg :-
dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: 
warning: [deprecation] show() in Dialog has been deprecated

Other deprecated uses could silently creep into such a body of code.

2) Some significant fraction of all the warnings are for getPeer() :-
dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: 
warning: [deprecation] getPeer() in Component has been deprecated

The issue here is that the deprecation javadoc tag is unable to 
distinguish deprecated for
external usage vs legitimate internal usage. There is no problem with 
code inside the desktop module
calling getPeer() which is defined in this same module.  There may not 
be many other APIs that
have this similar issue, but if there are it might be better to find 
some way to make it clear
that we aren't suppressing warnings until we fix the code : rather we 
really should not be
receiving a warning here anyway since there is nothing to fix. Perhaps 
"Component. getPeer()"
could acquire an annotation  like "module-nodeprecation" which 
automatically suppresses the
annotation processor  warnings for all such cases. If javac doesn't know 
about modules perhaps
we could utilise a javac flag that's used only by the JDK build to 
indicate that an annotation
like that should apply.

Regarding the show() case above I came across a puzzle.
show() is first defined on Component, as is its 'replacement' 
setVisible(boolean).
It turns out that what we have in Component is

public void setVisible(boolean b) {
    show(b);
}

@Deprecated
public void show(boolean b) {
    if (b) {
       show();
   } else {
       hide();
}

@Deprecated
public void show() {
  ...
}

So I am puzzled why those uses within Component aren't suppressed in 
your webrev ?
Is there some automatic suppression of the warnings within the class 
that does
the deprecation ? If so then perhaps the module idea above can be considered
an extension of this. If that isn't what's happening, then what is ?

-phil.





On 12/9/2014 4:41 PM, joe darcy wrote:
> Hello,
>
> In support of JEP 212: Resolve Lint and Doclint Warnings 
> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please 
> review the large but straightforward set of changes in the webrev:
>
>     http://cr.openjdk.java.net/~darcy/8066621.0/
>
> Some background of the approach being taken to address this part of 
> JEP 212 was discussed on core-libs:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>
>
> Briefly, to allow the deprecation warnings to be dealt with and that 
> sole remaining lint warning category enabled in the build, a two-step 
> approach is being taken. The first step is to suppress the deprecation 
> warnings and the second step is for area-experts to examine the 
> specific uses of deprecated APIs in their code. This webrev only 
> attempts to cover the first step.
>
> The webrev is based off of the JDK 9 "dev" forest rather than the 
> "client" forest. Since the change only involves copyright updates and 
> adding annotations, there would be no functional modification in the 
> changeset. Therefore, I would strongly prefer to push these changes 
> directly to dev rather than pushing them to client and waiting for 
> them to propagate to dev to expedite the time when the build warning 
> can be enabled. (If a warning is not enabled in the build, new 
> instances of the warning tend to creep into the code base.)
>
> Thanks,
>
> -Joe