refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.test.core (Tag)

[joaodinissf]

What

Converts Tag — the last .xtend file in com.avaloq.tools.ddk.xtext.test.core — from Xtend to Java, keeping @Active(TagCompilationParticipant.class) + @Retention(RUNTIME) and the org.eclipse.xtend.lib MANIFEST dependency, and removes the module's Xtend build infrastructure (.classpath / .project / build.properties / xtend-gen). Also bumps the bundle to 17.3.2 (MANIFEST + pom), since its content changes relative to the published 19.0.0 baseline and the revived compare-version-with-baselines gate would otherwise reject it.

Why this was parked, and why it is unblocked now

Tag is an Xtend active annotation: TagCompilationParticipant runs at Xtend-compile time and auto-assigns each @Tag field a unique int (from COUNTER_BASE = 10000). DDK declares no @Tag fields itself — the consumers are closed-source downstream repos — so this CI could not directly prove the macro still fires once Tag is a Java @interface. The PR was therefore held as a blocked draft.

That question has now been answered by a dedicated multi-agent validation (2026-08-25):

1. Byte-identity. The hand-written Tag.java from this PR, compiled with plain javac 21 against org.eclipse.xtend.lib.macro 2.43.0, produces a Tag.class byte-for-byte identical (SHA-256 1a9b1ec375fc5a9348112ae478eb3eb8e1ff62876f557d6622c30ff4be04c71c) to the Xtend-pipeline-compiled Tag.class shipped in the released bundle com.avaloq.tools.ddk.xtext.test.core_17.3.1.v20260713-0816.jar (whose Xtend provenance is proven by its source jar containing Tag.xtend, the xtend-gen Tag.java, and the ._trace file). A downstream Xtend compiler consuming the bundle jar receives literally the same bytes — provenance is indistinguishable for any Xtend version. The only source-level delta is the Xtend-emitted @SuppressWarnings("all"), which has SOURCE retention and leaves no bytecode trace.
2. Live behavioral proof (run twice, independently). XtendBatchCompiler 2.43.0 compiled a consumer .xtend declaring @Tag fields with only the javac-compiled Tag/TagCompilationParticipant on the classpath: the active annotation fired and injected 10000/10001/10002 exactly as before.
3. Mechanism (compiler source). Xtend's active-annotation detection (XAnnotationExtensions.isActiveAnnotation / getProcessorType) operates purely on JvmAnnotationType — the JVM type model, populated identically from Xtend source, Java source, or classpath bytecode. This is the same mechanism by which org.eclipse.xtend.lib's own @Data/@Accessors work: that jar ships only .class files.
4. Failure mode is loud, not silent. With the processor class unloadable, the batch compiler errors out ("Problem while loading annotation processor…") rather than silently leaving fields at 0.

Note on known-pitfalls.md

.agents/skills/xtend-to-java/workflow/known-pitfalls.md (line 38) advises against converting Tag/TagCompilationParticipant as a routine leaf because downstream consumers can't be validated by local CI. This PR deviates from that guidance deliberately, on the strength of the evidence above: for every consumer of the shipped bundle binary, the conversion is provably a no-op.

Residual risk (stated honestly)

• A downstream build that recompiles Tag from source (rather than consuming the p2/OSGi binary) was not exercised; the source declarations are semantically identical, but not byte-proven.
• Downstream Xtend versions are unknown; the byte-identity argument is version-independent for binary consumers, and JvmAnnotationType-based detection is long-standing behavior, but a pathologically old Xtend can't be ruled out from here.
• A cheap, decisive closer if a downstream build channel exists: compile one existing @Tag-using Xtend class against a bundle built from this PR and assert initializers 10000+ appear in its xtend-gen output.

Status

Held in draft pending the author's final call (optionally after the downstream smoke test above); the technical blocker itself is resolved.

🤖 Generated with Claude Code

[rubenporras]

I think we can do this if we want to finally get rid of Xtend. Alternatively, if we accept that downstream projects can also migrate away from xtend, they should use com.avaloq.tools.ddk.xtext.test.TagExtension, which I introduced for that purpose. Because this will likely take same time I think this PR makes sense.