Repository navigation
refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.expression - #1517
Merged
Merged
Conversation
…on (1/2: rename sources) Pure `git mv` of the three generator sources from .xtend to .java with their content unchanged, so Git's rename detection permanently links the Java history to its Xtend past (git log --follow, git blame). This commit intentionally does not compile: the renamed files still hold Xtend syntax. The following commit rewrites them in place to Java 21. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…on (2/2: translate to Java 21) In-place translation of the three renamed generator sources, faithful to the Xtend compiler's own xtend-gen output (fresh ground-truth build off the base commit, byte-identical to the reference). The module keeps ExpressionJvmModelInferrer.xtend, so the Xtend build infrastructure stays and there is no infrastructure commit. Public API is unchanged: the export and scope jvmmodel inferrers bind by dispatcher name (literalIdentifier(ENamedElement), instanceClassName(EClassifier)), by extension syntax (javaContributorComment, location, canContain, toJavaPackage) and by the Xtend property write `genModelUtil.resource = ...` (setResource(Resource)), all of which compile green with -amd. Notable per-file points: - GenModelUtilX: the dispatch cases keep their `_` prefix, their protected visibility, the Void overload as the null case and the reference's branch order (EClass, EStructuralFeature/EDataType, supertype, null). The dispatchers are Java 21 pattern switches; like xtend-gen they have no terminal IllegalArgumentException because the Void case makes them total. - GenModelUtilX: the ThreadLocal<Resource> context field stays a ThreadLocal, and the `_literalIdentifier(EStructuralFeature)` literals branch keeps calling the public dispatcher (not the _ case) for the containing EClass, exactly as xtend-gen does. - GenModelUtilX: two private helpers replace xbase.lib calls with their exact semantics rather than the lossy idiomatic form - firstInterface() reproduces IterableExtensions.head returning null on an empty interface array (so an EPackage subclass declaring no interface still fails with an NPE, not an out-of-bounds), and toFirstUpper() reproduces StringExtensions.toFirstUpper including its null, empty and already-upper-case pass-throughs. - GenModelUtilX: Xtend `==`/`!=` on objects is translated to Objects.equals as xtend-gen did; the identity `!==` comparisons stay reference comparisons. The lazy IterableExtensions.filter feeding the Xcore candidate loop becomes a guard inside that loop, which iterates the same elements in the same order. - Naming / GeneratorUtilX: plain `+` concatenation preserved (no templates in these files); the Avaloq banner header is applied to all three files per the migration skill, replacing the two files' missing header. - One comment deviation: the vestigial `/*cached*/` markers the Xtend source carried on fifteen `def`s (remnants of former Xtend `create` methods, carrying no behaviour and already absent from xtend-gen) are dropped. Every other comment and Javadoc is preserved verbatim, and no Javadoc is invented - the only new Javadoc documents the two new private helpers. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…(content changed vs baseline) The compare-version-with-baselines gate rejects the migrated bundle and the runtime feature that includes it: their content differs from the 19.1.0 baseline while the versions were unchanged. Micro bumps per OSGi conventions; the public API is identical. com.avaloq.tools.ddk.feature is already at 19.1.1 on master. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
rubenporras
approved these changes
Sep 7, 2026
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
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.
Summary
Migrates the three remaining legacy Xtend sources of
com.avaloq.tools.ddk.xtext.expressionto Java 21:generator/GenModelUtilX— GenModel/EMF-registry lookups, theliteralIdentifierandinstanceClassNamedispatch families, the per-thread resource contextgenerator/GeneratorUtilX— contributor-comment and grammar helpersgenerator/Naming— qualified-name helpersThe module keeps
jvmmodel/ExpressionJvmModelInferrer.xtend, so the Xtend build infrastructure (xtend-gen,.classpath,build.properties) is untouched. For the Tycho baseline gate, the bundle is micro-bumped to 17.3.3 and the runtime feature that includes it to 19.1.1 (content changed, API identical).Public API is unchanged. These classes are consumed only by the Xtend inferrers in
xtext.exportandxtext.scope, which bind by dispatcher name (literalIdentifier(ENamedElement),instanceClassName(EClassifier)), by extension syntax (javaContributorComment,location,canContain,toJavaPackage) and by the property writegenModelUtil.resource = …→setResource(Resource). All of them compile unchanged against the Java.Faithfulness notes
protected _name(Type)cases including theVoidoverload as the null case, and a public dispatcher with the compiler's branch order (EClass→EStructuralFeature/EDataType→ supertype → null). As in the compiler output there is no terminalIllegalArgumentException: theVoidcase makes both dispatchers total.ThreadLocal<Resource>context andsetResource/getContextare unchanged.firstInterface()reproducesIterableExtensions.headreturningnullon an empty interface array (so the failure mode on an interface-lessEPackagesubclass is unchanged), andtoFirstUpper()reproducesStringExtensions.toFirstUpperincluding itsnull/empty/already-upper pass-throughs. Xtend==/!=on objects →Objects.equals; identity!==stays!=. The lazyfilterfeeding the Xcore candidate loop became a guard inside the loop (same elements, same order)./*cached*/markers on fifteendefs (remnants of formercreatemethods, no behaviour, already absent from the compiler output). Every other comment and Javadoc is preserved verbatim; the only new Javadoc documents the two private helpers.DOES_NOT_EXIST,DOT) for Checkstyle; values unchanged. Parameters nameditrenamed per the migration skill.Known deltas
@XbaseGeneratedon 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 (onlyJvmModelGeneratoremits it), and re-applying a "machine-generated" marker to hand-written code would be false.ResourceSetthe.genmodelindex is empty, sogenPackage()always returns null and the registry/heuristic fallbacks are taken. TheisLiteralsInterface()branches of_literalIdentifierandqualifiedSwitchClassName, andgenClass/genDataType/genModel, are therefore exercised only in a workspace build, not by the differential above.Verification
xtend-genfrom a clean build of the Xtend sources as they stood at the point the branch was cut. The branch has since been rebased onto a Checkstyle version bump, which cannot affect the Xtend compiler's output, so the reference still holds; the gates below were re-run after the rebase.if-chain vs patternswitch, constant extraction, one Guava-vs-local-helper choice). No fidelity-relevant discrepancy.-amdcompile (rebuilds the export/scope Xtend callers) ✅;pmd:check checkstyle:check spotbugs:check✅; full reactorclean verifywith the CI static-analysis goals ✅ (354 tests, 0 failures, 2 skipped).🤖 Generated with Claude Code