refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.scope

[joaodinissf]

Summary

Migrates the three remaining legacy Xtend sources of com.avaloq.tools.ddk.xtext.scope to Java 21:

• generator/ScopeProviderX — scope/rule/injection/extension collection helpers and the isEqual dispatch family
• generator/ScopeNameProviderGenerator — name-function bodies
• generator/ScopeProviderGenerator — scope-provider method bodies, global caches, rule blocks

With this, the last 2017-era Xtend in the repository is gone; the remaining .xtend files are the Xbase inferrer layer in jvmmodel/, so the Xtend build infrastructure (xtend-gen, .classpath, build.properties) is untouched.

Stacked on the xtext.export migration.

Public API is unchanged. The consumers are ScopeJvmModelInferrer.xtend (configure(...), the doGet*Body/doGlobalCache*Body/scopeMethodBody/internalGetNameFunctionsBody template methods, scopeMethodName) and ScopeExpressionTranslator.xtend (allExtensions). They compile unchanged against the Java.

Faithfulness notes

• All 15 templates keep the compiler's exact StringConcatenation call sequence. Eleven cannot be rebuilt on StringBuilder/text blocks under the migration skill's §4.8 (two-arg append(value, indent) of multi-line values, appendImmediate separator loops, whitespace-retracting newLineIfNotEmpty after indent-only lines); the other four are kept on the same idiom because sibling templates two-arg-append their output. The full append sequence was diffed mechanically against the compiler output: 407 operations, identical order and literals. StringConcatenation lives in org.eclipse.xtext.xbase.lib and needs no Xtend compiler.
• Dispatchers keep the compiler's branch order and terminal behaviour: the 8-way isEqual(EObject, EObject) including its Void-typed null routing; scopeType, nameFunction, scopeExpression, factoryArgument, scopeExpressionPart, scopeExpressionNaming, isEmptyList with their IllegalArgumentException("Unhandled parameter types: …") terminals.
• Collection ordering preserved (toSet → LinkedHashSet, stable sortBy, insertion-ordered filterUniqueRules): these sets drive the emitted case labels and method bodies.
• The non-@Inject extension GenModelUtilX fields become plain private fields assigned in configure(...); signatures unchanged. org.eclipse.xtext.xbase.lib.Pair is kept where ScopeExpressionTranslator.newCompilationContext demands it.
• error(...) and the single-global-rule guard still throw raw RuntimeException (PMD-suppressed with // NOPMD, as at the existing production sites) rather than a narrower type, to keep the thrown type identical.
• CPD reports four intra-file duplications in the two template generators (the parallel by-reference/by-type and global-cache bodies, the FeatureCall/OperationCall name functions); they mirror the Xtend structure and are baselined with file-scoped CPD-OFF markers, as for the migrated ANTLR generators.
• Documented, output-neutral deviations: an unreachable if (d == null) branch on a filter result dropped; nine private helpers factor out model filtering the compiler inlined; Guava/xbase.lib helper calls replaced by stdlib equivalents with the same order; type.cast instead of an unchecked cast; explicit StringBuilder capacity; configure parameters renamed for Checkstyle HiddenField; parameters documented as @param it keep that name.

Known deltas

• The Xtend compiler stamped @XbaseGenerated on the generated dispatchers; the migrated Java does not. The annotation is runtime-retained on public methods in an exported package, so it is a reflectively observable delta — but nothing in the target platform reads it (only JvmModelGenerator emits it), and re-applying a "machine-generated" marker to hand-written code would be false.

Verification

• Ground truth: fresh xtend-gen from a clean build of the base commit.
• Two independent translations were produced and reconciled against the compiler output. One fidelity-relevant discrepancy surfaced and was resolved in favour of the compiler output: the other translation had narrowed the two raw RuntimeException throws to IllegalStateException, which the bytecode comparison caught. All other differences were style.
• Bytecode comparison against the compiler's classes: public/protected API identical across all three classes; per-method string constants identical; StringConcatenation append/newLine sequences identical; dispatcher branch order identical.
• Gates: -amd compile ✅; pmd:check checkstyle:check spotbugs:check ✅; full reactor clean verify with the CI static-analysis goals ✅ (354 tests, 0 failures, 2 skipped). No version bump needed: the bundle is already at 17.3.3, ahead of the baseline.

🤖 Generated with Claude Code