refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.generator (builder group)#1430
Merged
joaodinissf merged 4 commits intoJun 24, 2026
Conversation
…r (builder group) Migrates 12 generator fragment/support classes from Xtend to Java: BundleVersionStripperFragment, DefaultFragmentWithOverride, builder/BuilderIntegrationFragment2, builder/LspBuilderIntegrationFragment2, builder/StandaloneBuilderIntegrationFragment2, formatting/FormatterFragment2, languageconstants/LanguageConstantsFragment2, model/project/ProjectConfig, modelinference/ModelInferenceFragment2, resourceFactory/ResourceFactoryFragment2, ui/compare/CompareFragment2, and ui/contentAssist/AnnotationAwareContentAssistFragment2. Xtend rich-string templates were rewritten as explicit StringConcatenation/string building, implicit getters/extension methods made explicit, and null-safe operators expanded to guarded Java. Behaviour is preserved; only language form changes. This is the builder half of the com.avaloq.tools.ddk.xtext.generator split (parser half tracked in dsldevkit#1429); per-module Xtend infrastructure cleanup is deferred until both halves merge. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
joaodinissf
force-pushed
the
migrate/xtend-to-java/xtext-generator-builder
branch
from
e1bae18 to
cade93a
Compare
…r fragments Address the per-file audit's confirmed divergences (dsldevkit#1430), kept as a separate follow-up commit on top of the audited migration: - StandaloneBuilderIntegrationFragment2 / AnnotationAwareContentAssistFragment2: replace name.substring(0, 1).toUpperCase() + name.substring(1) with StringExtensions.toFirstUpper(name). The substring form was non-faithful to the original Xtend .toFirstUpper(): it threw on an empty name and used the default locale (e.g. a name starting with 'i' would uppercase to 'İ' under tr_TR and generate a wrong identifier). StringExtensions.toFirstUpper is locale-independent and null/empty-safe, matches the original, and is already used by the sibling LspBuilderIntegrationFragment2 (same bundle dependency, no new import cost). - StandaloneBuilderIntegrationFragment2 PARENTS list: emit the " " prefix and the trailing newline only when there are used grammars, replicating the original Xtend newLineIfNotEmpty(). Previously an empty allUsedGrammars produced an extra whitespace-only line in the generated source. Proven byte-identical to the prior output for >=1 grammar and to the legacy output for the empty case. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
rubenporras
requested changes
Jun 18, 2026
| StringConcatenationClient client = new StringConcatenationClient() { | ||
| @Override | ||
| protected void appendTo(final TargetStringConcatenation builder) { | ||
| builder.append("import java.util.List;"); |
Member
There was a problem hiding this comment.
this file should use more multi line strings, right? (I guess the rest of the PR is similar)
…ter fragments
Collapse runs of consecutive StringConcatenation(Client)/StringBuilder
append("literal")/newLine() calls into Java text blocks (with .formatted()
for single-line interpolations) in the generated-code skeletons of
LspBuilderIntegrationFragment2, StandaloneBuilderIntegrationFragment2 and
FormatterFragment2. Loops, two-arg indented appends and import-managed
appends are left intact. Every converted run was proven byte-identical to
the original output via an executable StringConcatenation-vs-text-block
harness; generated artifacts are unchanged.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…guageConstantsFragment2 The whole generated-class body is a static skeleton with single-line interpolations (grammar name, class simple name, file extensions), so it collapses to one Java text block + .formatted(). Two-arg indented appends of single-line identifier values are equivalent to %s here (no multi-line value to re-indent); proven byte-identical to the original output via the StringConcatenation-vs-text-block harness. Generated artifact unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
rubenporras
approved these changes
Jun 23, 2026
joaodinissf
added a commit
that referenced
this pull request
Jun 24, 2026
…r fragments Address the per-file audit's confirmed divergences (#1430), kept as a separate follow-up commit on top of the audited migration: - StandaloneBuilderIntegrationFragment2 / AnnotationAwareContentAssistFragment2: replace name.substring(0, 1).toUpperCase() + name.substring(1) with StringExtensions.toFirstUpper(name). The substring form was non-faithful to the original Xtend .toFirstUpper(): it threw on an empty name and used the default locale (e.g. a name starting with 'i' would uppercase to 'İ' under tr_TR and generate a wrong identifier). StringExtensions.toFirstUpper is locale-independent and null/empty-safe, matches the original, and is already used by the sibling LspBuilderIntegrationFragment2 (same bundle dependency, no new import cost). - StandaloneBuilderIntegrationFragment2 PARENTS list: emit the " " prefix and the trailing newline only when there are used grammars, replicating the original Xtend newLineIfNotEmpty(). Previously an empty allUsedGrammars produced an extra whitespace-only line in the generated source. Proven byte-identical to the prior output for >=1 grammar and to the legacy output for the empty case. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
2 participants
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.
What
Migrates the builder group of
com.avaloq.tools.ddk.xtext.generatorfrom Xtend to Java — 12 fragment/support classes:BundleVersionStripperFragmentDefaultFragmentWithOverridebuilder/BuilderIntegrationFragment2builder/LspBuilderIntegrationFragment2builder/StandaloneBuilderIntegrationFragment2formatting/FormatterFragment2languageconstants/LanguageConstantsFragment2model/project/ProjectConfigmodelinference/ModelInferenceFragment2resourceFactory/ResourceFactoryFragment2ui/compare/CompareFragment2ui/contentAssist/AnnotationAwareContentAssistFragment2Xtend rich-string templates were rewritten as explicit string building, implicit getters/extension methods made explicit, and null-safe operators expanded to guarded Java. Behaviour is preserved — only the language form changes.
Local gate
mvn -T 3C -pl com.avaloq.tools.ddk.xtext.generator -am clean verify— BUILD SUCCESS (module compiles green; no test or baseline failures).Verify
Verdict: SHIP. No behavioural concerns; the rewrite is a faithful 1:1 translation of the existing fragment generators.
Scope note
This PR is a split of
com.avaloq.tools.ddk.xtext.generator. The parser group is tracked separately in #1429. Per-module Xtend infrastructure cleanup (removing the Xtend nature/registration for this module) is deferred until both the parser (#1429) and this builder PR merge, so the module retains its Xtend toolchain in the interim.🤖 Generated with Claude Code