<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <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>
  </body>
</html>