Issue #68: use JSR-199 to call Eclipse compiler #69
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of invoking BatchCompiler with an option to write diagnostics to a temporary XML file and then parsing that call ECJ via the standard JSR-199 interfaces and use a DiagnosticListener. Besides not needing a temporary file this also ensures that all diagnostics are reported correctly. ECJ's BatchCompiler reports diagnostics from APT processors differently than other diagnostics (they're "extra_problems" in the XML), and the XML parser just ignores these extra_problems. Even if it did parse them, ECJ up to at least 3.20.0 neglects to give the source file for such extra_problems in the XML (that's a bug in ECJ), and thus the output would be not exactly helpful. Using JSR-199 to call ECJ, it reports all diagnostics including these "extra_problems" (with source file!) to the DiagnosticListener, and thus no messages are lost. A minor quirk is that when no source level is specified, BatchCompiler compiles with source level 1.3, while the ECJ JSR-199 implementation uses the latest source level it supports (Java 12 for ECJ 3.20.0). To maintain backwards compatibility, set source level 1.3 explicitly in that case. In normal maven usage, <source> is typically set anyway, either explicitly in the user projects' POMs or via property maven.compiler.source. If no JSR-199 interface for ECJ can be found keep using the legacy mechanism using BatchCompiler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of invoking BatchCompiler with an option to write diagnostics
to a temporary XML file and then parsing that call ECJ via the standard
JSR-199 interfaces and use a DiagnosticListener.
Besides not needing a temporary file this also ensures that all
diagnostics are reported correctly. ECJ's BatchCompiler reports
diagnostics from APT processors differently than other diagnostics
(they're "extra_problems" in the XML), and the XML parser just ignores
these extra_problems. Even if it did parse them, ECJ up to at least
3.20.0 neglects to give the source file for such extra_problems in the
XML (that's a bug in ECJ), and thus the output would be not exactly
helpful.
Using JSR-199 to call ECJ, it reports all diagnostics including these
"extra_problems" (with source file!) to the DiagnosticListener, and
thus no messages are lost.
A minor quirk is that when no source level is specified, BatchCompiler
compiles with source level 1.3, while the ECJ JSR-199 implementation
uses the latest source level it supports (Java 12 for ECJ 3.20.0). To
maintain backwards compatibility, set source level 1.3 explicitly in
that case. In normal maven usage, <source> is typically set anyway,
either explicitly in the user projects' POMs or via property
maven.compiler.source.
If no JSR-199 interface for ECJ can be found keep using the legacy
mechanism using BatchCompiler.