-proceedOnError option (like ECJ) ?

Jonathan Gibbons jonathan.gibbons at oracle.com
Thu Jun 20 15:40:35 UTC 2024


Any such change would have to be in accord with JLS and the TCK ...

-- Jon

On 6/18/24 7:26 AM, Mickael Istria wrote:
> Hi all,
>
> 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.
> 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.
> Ongoing work is happening at 
> https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator
>
> 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.
> 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.
> 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 ;)
>
> Cheers,
> -- 
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red 
> Hat <https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240620/5c06ee31/attachment.htm>


More information about the compiler-dev mailing list