<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>We'll need Joe "Mr Annotation Processing" Darcy to chime in here,
      but the Filer is supposed to detect clashes, and prevent
      overwriting/overriding symbols. That's definitely supposed to
      happen for normal classes/interfaces; I could believe that
      package-info has been overlooked, but I would expect it to follow
      the same guidelines.</p>
    <p>-- Jon<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 12/5/17 6:24 PM, Liam Miller-Cushon
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com">
      <div dir="ltr">Is overriding package-infos different or worse than
        overriding other symbols? I've seen a number of examples where
        the same source file was compiled multiple times and the earlier
        results ended up on the class path of the later compilations, so
        a processor-generated class was both on the class path and
        generated during the compilation. Making that an error would be
        a somewhat invasive breaking change. I agree that it should be
        discouraged, but I'm not sure it's worth making an error?
        (Unless there's something special about package-infos that I'm
        missing.)</div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Dec 5, 2017 at 6:09 PM,
          Jonathan Gibbons <span dir="ltr"><<a
              href="mailto:jonathan.gibbons@oracle.com" target="_blank"
              moz-do-not-send="true">jonathan.gibbons@oracle.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000"> Generally, annotation
              processing is supposed to only create information where
              there was no information previously,  so if a package had
              a package-info with annotations, it seems like it should
              be an error to override it with another package-info, with
              or without annotations.<br>
              <br>
              -- Jon
              <div>
                <div class="h5"><br>
                  <br>
                  <div class="m_6854548390215522736moz-cite-prefix">On
                    12/05/2017 05:39 PM, Liam Miller-Cushon wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">Thanks! If an annotated package-info
                      is loaded from the class path, and then a
                      processor generates a package-info that contains
                      no annotations, the reset is necessary. (The reset
                      isn't necessary if the new package-info is
                      annotated, since the old annotations get
                      overwritten even if they weren't reset between
                      rounds.)</div>
                    <div class="gmail_extra"><br>
                      <div class="gmail_quote">On Tue, Dec 5, 2017 at
                        4:46 PM, Jonathan Gibbons <span dir="ltr"><<a
                            href="mailto:jonathan.gibbons@oracle.com"
                            target="_blank" moz-do-not-send="true">jonathan.gibbons@oracle.com</a>></span>
                        wrote:<br>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">Liam,<br>
                          <br>
                          What about the case where an annotation
                          processor generates the package-info.java
                          file? Is that a case where it is important to
                          reinit the packge symbol correctly, so that
                          the newly generated code is read?<br>
                          <br>
                          -- Jon
                          <div class="m_6854548390215522736HOEnZb">
                            <div class="m_6854548390215522736h5"><br>
                              <br>
                              On 12/05/2017 03:39 PM, Liam Miller-Cushon
                              wrote:<br>
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex"> I have a
                                question about the logic in
                                JavacProcessingEnvironment's treeCleaner
                                that resets package-info state between
                                annotation processing rounds [1].<br>
                                <br>
                                JDK-8193037 describes an issue where
                                package-infos loaded from the classpath
                                are reset by treeCleaner. Those symbols
                                doesn't get reinitialized correctly, and
                                package annotations are not visible
                                during subsequent annotation processing
                                rounds.<br>
                                <br>
                                I wondered if the logic was only meant
                                to apply to package-infos being compiled
                                from source in the current compilation
                                (similar to how module-infos are handle
                                by treeCleaner), but I'm having trouble
                                understanding when that logic is
                                necessary. Commenting out
                                `node.packge.package_info.rese<wbr>t();`
                                and `node.packge.reset();` in
                                treeCleaner doesn't break any jtreg
                                tests. Does anyone have examples where
                                that code is needed? I'd like to add a
                                regression test to ensure the fix for
                                JDK-8193037 doesn't interfere with the
                                original purpose of that code.<br>
                                <br>
                                Thanks,<br>
                                <br>
                                [1] <a
href="http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518"
                                  rel="noreferrer" target="_blank"
                                  moz-do-not-send="true">http://hg.openjdk.java.net/jdk<wbr>/jdk/file/a358ebcfacfb/src/jdk<wbr>.compiler/share/classes/com/su<wbr>n/tools/javac/processing/Javac<wbr>ProcessingEnvironment.java#l15<wbr>18</a><br>
                              </blockquote>
                              <br>
                            </div>
                          </div>
                        </blockquote>
                      </div>
                      <br>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>