<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>The JCK rule "Java SE C3.1" (added since JCK8a) covers such
      options:<br>
      "...<span style="color: rgb(0, 0, 0); font-family: Tahoma, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Executable
        Output must always throw an exception that identifies a
        compilation error before reaching any part of the source code
        affected by that compilation error"</span></p>
    <p><span style="color: rgb(0, 0, 0); font-family: Tahoma, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Regards,<br>
        -leonid<br>
        The JCK team</span><br>
    </p>
    <div class="moz-cite-prefix">On 6/20/2024 8:40 AM, Jonathan Gibbons
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:3344b2bd-4190-41ac-ae36-ec1afb272c8d@oracle.com">
      
      <p>Any such change would have to be in accord with JLS and the TCK
        ...</p>
      <p>-- Jon<br>
      </p>
      <div class="moz-cite-prefix">On 6/18/24 7:26 AM, Mickael Istria
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:CAFr6BZSk7a22FWrZy6QakmJ0OA5-sOKaga6DYpEJRqSZL4rnSg@mail.gmail.com">
        <div dir="ltr">
          <div>Hi all,</div>
          <div><br>
          </div>
          <div>Our team, made of various Eclipse JDT contributors, is
            currently looking at allowing Eclipse JDT to directly use
            Javac instead of ECJ for Java code parsing and resolution
            and code generation. The goal is to keep the higher levels
            of Eclipse JDT and its ecosystem/plugins working, and allow
            to plug a Javac-based backend under the hood as an
            alternative.<br>
          </div>
          <div>We've already made significant progress on this topic,
            and despite various remaining glitches, a proof of concept
            is already kind of usable, with all typical IDE features
            (code analysis, error reporting, selection, completion,
            indexing...) provided by javac backend. We are then
            confident that this is a viable approach on the mid to long
            term.</div>
          <div>Ongoing work is happening at <a href="https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator</a></div>
          <div><br>
          </div>
          <div>While working on it, we've identified some interesting
            features of ECJ that are missing in Javac and that would be
            in our opinion extremely profitable to IDE integration, but
            also could be profitable to other integrations as they can
            shorten the feedback look tremendously in some cases.<br>
          </div>
          <div>The main feature we're missing from ECJ would be
            something equivalent to its `-proceedOnError` flag.
            Basically, it makes that the compiler, when it faces a
            compilation error, replaces the DOM/AST and the generated
            code with `throw new
            CompilationError(compilationErrorMessage)`. This is
            extremely convenient when debugging as it allows to hotswap
            some not-yet-complete-but-already-interesting-to-debug code
            into a running application.</div>
          <div>Do you think Javac could some day provide such a feature
            too? This is not (yet?) a request for enhancement, at this
            stage, we're just evaluating our hopes of getting our
            integration supporting this important enough case in the
            future. If there is no technical reason why not, then we may
            investigate contributing it (of course, if someone wants to
            implement it in the meantime, don't hesitate in coding it
            before us ;)</div>
          <div><br>
          </div>
          <div>Cheers,<br>
          </div>
          <div><span class="gmail_signature_prefix">-- </span><br>
            <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
              <div dir="ltr">
                <div>
                  <div dir="ltr">
                    <div>
                      <div dir="ltr">
                        <div>Mickael Istria<br>
                        </div>
                        <a href="https://www.eclipse.org/eclipseide" target="_blank" moz-do-not-send="true">Eclipse
                          IDE</a> developer, for <a href="https://developers.redhat.com/" target="_blank" moz-do-not-send="true">Red Hat</a></div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </blockquote>
    </blockquote>
  </body>
</html>