<div dir="ltr"><div dir="ltr"><div>Hi Maurizio,</div><div><br></div><div>Thanks for your input.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, May 9, 2025 at 9:31 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">IMHO, this is a problem present with the addition of every new
      lint warning. It's not specific to this one. Of course, some new
      lint warning operate on brand new language features, so the
      potential to compromise existing compilaton units is low. But I'd
      expect that warnings such as "serial" would have ran into similar
      corner cases (e.g. previously ok code started to report new
      warnings, and to fail with Werror).<div>
    <p>So I think this seems ok, and not enough to cause a tweak to the
      treatment of lint:all.</p></div></blockquote><div>That sounds good to me, but Joe Darcy had some reservations (see CSR). So we would need to decide how to proceed.</div><div><br></div><div>Maybe the thing to do is just to ensure that it gets introduced early in the cycle so we can get some experience with it...?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>I'll add here that a more robust fix for Werror issues is to
      enable developers to be more specific in the warnings they'd like
      to promote to errors (as discussed in the past). I'll CC Kevin who
      has always been a fan of this feature ;-)<br></p></div></blockquote><div>Good news: that PR is already in place  :) <a href="https://github.com/openjdk/jdk/pull/23622">https://github.com/openjdk/jdk/pull/23622</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">
              <div dir="ltr">
                <div dir="ltr">
                  <div dir="ltr">
                    <div dir="ltr">
                      <div dir="ltr">
                        <div>Also complicating things, there are two
                          different ways to suppress warnings, <span style="font-family:monospace">@SuppressWarnings("foo")</span>
                          and <span style="font-family:monospace">-Xlint:-foo</span>
                          and for similar "corner case" reasons they
                          need to be configurable separately.</div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>IMHO, the main value of this new lint warning is to detect the
      use of `@SuppressWarnings` that are redundant. Sure there's the
      command-line flavor as well, but that renders any source code
      analysis dependent on the flags passed to javac. In other words,
      detecting redundant `@SuppressWarnings` has a more "timeless"
      nature that does not apply to detecting redundant command-line
      suppressions. The former tells you something about _your code_, in
      a way that is independent from which flags you use to compile it.
      Which is why I think we should only worry about that.</p></div></blockquote><div>I think that's a reasonable way to start - that is, we just add the category for <span style="font-family:monospace">"suppression"</span> now and worry later about possibly adding <span style="font-family:monospace">"supression-option"</span>.</div><div><br></div><div>Joe - any thoughts?</div><div><br></div></div><div>-Archie</div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>