Skip blank annotation processor names in javac and eclipse - #513
Skip blank annotation processor names in javac and eclipse#513slachiewicz wants to merge 3 commits into
Conversation
JavacCompiler guarded the -processor flag on a null check alone, so a zero-length array produced -processor followed by an empty argument and javac failed to resolve the empty name. EclipseJavaCompiler already guards on length as well; this aligns the two. Fixes #512
Both compilers decided whether to pass -processor from the array's length alone, so an array of blank names produced -processor with an empty or comma-only argument. Filtering blanks covers the zero-length case too, and matches how maven-compiler-plugin normalizes the same field caller-side. Fixes #512
|
Widened after review: the length guard alone did not cover
Filtering rather than all-or-nothing matches how maven-compiler-plugin normalizes the same field caller-side in apache/maven-compiler-plugin#1077, now merged. Verified: This comment was created with AI assistance. |
slachiewicz
changed the title
Both compilers had their own copy of the blank-filtering loop. Two guards that agree today are how these two came to disagree in the first place, so route both through joinAnnotationProcessors on AbstractCompiler.
|
LGTM. |
2 participants
JavacCompilerandEclipseJavaCompilerboth decided whether to pass-processorfrom the array's length alone, so an array of blank names produced-processorfollowed by an empty or comma-only argument. Fixes #512.Both now route the field through one
joinAnnotationProcessorshelper onAbstractCompilerand emit the option only when a name survives. A single shared rule is the point: two hand-rolled guards that agree today drift apart tomorrow, which is how the two compilers came to disagree in the first place.Filtering rather than length-checking is deliberate.
{"", ""}has length 2, so a length guard still emits-processor ,. It also mirrors the semantic that apache/maven-compiler-plugin#1077 just merged caller-side, so behaviour is the same whether or not a user's plugin version carries that fix.Compatibility
Every input whose behaviour changes —
{""},{"", ""},{"", "X"}— previously made javac fail on an unresolvable processor name, so no working configuration depended on the old output.One semantic worth stating:
-processorsuppresses javac's defaultServiceLoaderdiscovery, so omitting the option for an all-blank list restores discovery. That is the intended reading, since an empty element means "unspecified" rather than "none" —<proc>none</proc>remains the way to ask for no annotation processing, and it is an independent flag.If reviewers would rather blanks were not dropped silently, a warn-level log line when the filter removes something would be a small follow-up.
Verified:
mvn -pl plexus-compilers/plexus-compiler-javac,plexus-compilers/plexus-compiler-eclipse -am test→ 129 and 17 tests, no failures. The{"", ""}case fails on master and passes here.This change was created with AI assistance.