<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Phil,<br>
    <br>
    <div class="moz-cite-prefix">On 12/12/2014 12:46 PM, Phil Race
      wrote:<br>
    </div>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">Hi,
      <br>
      You did not provide a direct reference to the set of warnings that
      were generated.
      <br>
      fortunately I found it here :-
      <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8066622">https://bugs.openjdk.java.net/browse/JDK-8066622</a>
      <br>
    </blockquote>
    <br>
    Each "Suppress deprecations warnings in foo" bug is linked to a "Fix
    deprecation warnings in foo" bug which lists the exact warnings.<br>
    <br>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">
      <br>
      A couple of things I find 'unfortunate' are
      <br>
      1) In order to avoid a deprecation warning on one call/line of a
      100 line method,
      <br>
      the entire method is subject to the annotation. Eg :-
      <br>
      dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226:
      warning: [deprecation] show() in Dialog has been deprecated
      <br>
      <br>
      Other deprecated uses could silently creep into such a body of
      code.
      <br>
    </blockquote>
    <br>
    That is true, but today deprecations warnings can (and do) creep
    into the entirely of the JDK without notice. Turning on the
    deprecation lint warning in the build will prevent that for the vast
    majority of code, which is why I want to get the remaining warning
    suppression bugs quickly pushed into JDK 9 so the build warning can
    be enabled. (This suppression effort was on hold until a small
    language change was recently implemented in JDK 9 to eliminate
    deprecation warnings just for importing a deprecated type.)<br>
    <br>
    For the "fix the warning" companion bug to this bug, I would
    recommend factoring out the deprecated method call into its own
    private method to limit the scope of the @SuppressWarning
    annotation. For this changeset, I didn't want to actually modify the
    contents or structure of any methods I so didn't undertake that kind
    of transformation.<br>
    <br>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">
      <br>
      2) Some significant fraction of all the warnings are for getPeer()
      :-
      <br>
      dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821:
      warning: [deprecation] getPeer() in Component has been deprecated
      <br>
    </blockquote>
    <br>
    Yes, I also noticed that a sizeable percentage of the warnings were
    for uses of that one method.<br>
    <br>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">
      <br>
      The issue here is that the deprecation javadoc tag is unable to
      distinguish deprecated for
      <br>
      external usage vs legitimate internal usage.</blockquote>
    <br>
    FYI, Stuart Mark / Dr. Deprecator gave an interesting talk at
    JavaOne this year covering the nuances of deprecation in the JDK:<br>
    <br>
       
<a class="moz-txt-link-freetext" href="https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377">https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377</a><br>
    <br>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">
      There is no problem with code inside the desktop module
      <br>
      calling getPeer() which is defined in this same module.  There may
      not be many other APIs that
      <br>
      have this similar issue, but if there are it might be better to
      find some way to make it clear
      <br>
      that we aren't suppressing warnings until we fix the code : rather
      we really should not be
      <br>
      receiving a warning here anyway since there is nothing to fix.</blockquote>
    <br>
    Well, the @SuppressWarnings annotation can be used to convey that
    information, perhaps supplemented by a comment or a wrapper method
    around getPeer; something like<br>
    <br>
    /**<br>
      * Package-access method somewhere in java.awt<br>
      */<br>
    @SuppressWarnings("deprecation")<br>
    static java.awt Component privilegeOfPeerage(java.awt Component c) 
    {<br>
        return c.getPeer();<br>
    }<br>
    <br>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">
      Perhaps "Component. getPeer()"
      <br>
      could acquire an annotation  like "module-nodeprecation" which
      automatically suppresses the
      <br>
      annotation processor  warnings for all such cases. If javac
      doesn't know about modules perhaps
      <br>
      we could utilise a javac flag that's used only by the JDK build to
      indicate that an annotation
      <br>
      like that should apply.
      <br>
    </blockquote>
    <br>
    At this point, I think that level of solution would be overkill
    (especially given the JDK's historical lack of discipline around
    deprecation warnings).<br>
    <br>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">
      <br>
      Regarding the show() case above I came across a puzzle.
      <br>
      show() is first defined on Component, as is its 'replacement'
      setVisible(boolean).
      <br>
      It turns out that what we have in Component is
      <br>
      <br>
      public void setVisible(boolean b) {
      <br>
         show(b);
      <br>
      }
      <br>
      <br>
      @Deprecated
      <br>
      public void show(boolean b) {
      <br>
         if (b) {
      <br>
            show();
      <br>
        } else {
      <br>
            hide();
      <br>
      }
      <br>
      <br>
      @Deprecated
      <br>
      public void show() {
      <br>
       ...
      <br>
      }
      <br>
      <br>
      So I am puzzled why those uses within Component aren't suppressed
      in your webrev ?
      <br>
      Is there some automatic suppression of the warnings within the
      class that does
      <br>
      the deprecation ? </blockquote>
    <br>
    Yes, quoting from the JLS:<br>
    <br>
    "A Java compiler must produce a deprecation warning when a type,
    method, field, or constructor whose declaration is annotated with <code
      class="literal">@Deprecated</code> is used (overridden, invoked,
    or referenced by name) in a construct which is explicitly or
    implicitly declared, unless: <br>
        * [...]<br>
        * The use and declaration are both within the same outermost
    class. "<br>
    <br>
<a class="moz-txt-link-freetext" href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6">http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6</a><br>
    <br>
    Thanks for the review,<br>
    <br>
    -Joe<br>
    <br>
    <blockquote cite="mid:548B5434.4020609@oracle.com" type="cite">If so
      then perhaps the module idea above can be considered
      <br>
      an extension of this. If that isn't what's happening, then what is
      ?
      <br>
      <br>
      -phil.
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      On 12/9/2014 4:41 PM, joe darcy wrote:
      <br>
      <blockquote type="cite">Hello,
        <br>
        <br>
        In support of JEP 212: Resolve Lint and Doclint Warnings
        (<a class="moz-txt-link-freetext" href="http://openjdk.java.net/jeps/212">http://openjdk.java.net/jeps/212</a>), which is targeted to JDK 9,
        please review the large but straightforward set of changes in
        the webrev:
        <br>
        <br>
            <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~darcy/8066621.0/">http://cr.openjdk.java.net/~darcy/8066621.0/</a>
        <br>
        <br>
        Some background of the approach being taken to address this part
        of JEP 212 was discussed on core-libs:
        <br>
        <br>
        <a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html">http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html</a>
        <br>
        <br>
        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.
        <br>
        <br>
        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.)
        <br>
        <br>
        Thanks,
        <br>
        <br>
        -Joe
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>