refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.generator (parser group) by joaodinissf · Pull Request #1429 · dsldevkit/dsl-devkit

joaodinissf · 2026-06-16T23:56:33Z

Migrates the parser group of com.avaloq.tools.ddk.xtext.generator (parser/antlr + parser/common, 6 files) from Xtend to hand-written Java:
AbstractAnnotationAwareAntlrGrammarGenerator, AnnotationAwareAntlrContentAssistGrammarGenerator, AnnotationAwareAntlrGrammarGenerator, AnnotationAwareXtextAntlrGeneratorFragment2, GrammarRuleAnnotations, PredicatesNaming.

Notes

The ANTLR StringConcatenation code-generation templates were byte-verified against the xtend-gen ground truth.
Local gate green: clean verify checkstyle:check pmd:check pmd:cpd-check spotbugs:check (0 violations).
Split module: this is one half of xtext.generator; the per-module Xtend build infra (xtend-gen wiring, MANIFEST, build.properties/.classpath/.project) is intentionally left untouched — it will be cleaned once both the parser and the builder PRs merge (12 sibling .xtend remain).

Blind adversarial review verdict: SHIP (only 2 invented-Javadoc nits).

…r (parser group) Migrate parser group (6 files) to hand-written Java; ANTLR StringConcatenation templates byte-verified vs xtend-gen; local gate green. Split of com.avaloq.tools.ddk.xtext.generator: per-module Xtend infra cleanup deferred until both parser+builder PRs merge. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…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>

rubenporras

Note: I have seen that Claude constantly forgets that he should try to use multi-line strings for readability. I use to interject it as steering once the skill has been kicked in, and that has worked fine so far.

rubenporras · 2026-06-18T05:58:03Z

+
+  protected CharSequence compileLexerMembers(final Grammar it, final AntlrOptions options) {
+    final StringConcatenation builder = new StringConcatenation();
+    builder.append("@members {");


this is clearly a multi line string.

rubenporras · 2026-06-18T06:02:55Z

+  protected CharSequence compileLexer(final Grammar it, final AntlrOptions options) {
+    final StringConcatenation builder = new StringConcatenation();
+    builder.append(codeConfig.getFileHeader());
+    builder.newLineIfNotEmpty();


I think a builder is justified for this case, but it would be better to remove the usage of org.eclipse.xtend2.lib.StringConcatenation, do you agree?

did you see this comment?

rubenporras · 2026-06-18T06:03:19Z

+
+  @Override
+  protected String compileParserImports(final Grammar it, final AntlrOptions options) {
+    final StringConcatenation builder = new StringConcatenation();


this is clearly a multi line string.

rubenporras · 2026-06-18T06:03:41Z

+
+  protected CharSequence compileParserSetTokenStreamMethod() {
+    final StringConcatenation builder = new StringConcatenation();
+    builder.append("/**");


this is clearly a multi line string, and so on, I did not continue the review.

Address review feedback (dsldevkit#1429): convert the static and single-statement interpolated grammar-fragment templates to Java text blocks with .formatted() - compileLexerMembers, compileParserImports, compileParserMemberDeclarations, compileParserSetTokenStreamMethod, compileRuleCatch. Builders that compose sub-results via newLineIfNotEmpty (compileLexer), use the two-argument append(value, indent) re-indentation, or contain FOR/IF control flow are left as StringConcatenation, per the skill's "StringBuilder for control flow only" rule - so the org.eclipse.xtend2.lib.StringConcatenation import stays. Separate commit on top of the migration; output proven byte-identical to the prior code for every converted method (verified against the real StringConcatenation runtime). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…textAntlrGeneratorFragment2 Replace the single-line StringConcatenation in the keyword-condition map lambda with String.formatted(); the result is byte-identical. The multi-line condBuilder (which relies on newLine/newLineIfNotEmpty) is left unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

rubenporras · 2026-06-23T07:09:52Z

+  protected CharSequence compileLexer(final Grammar it, final AntlrOptions options) {
+    final StringConcatenation builder = new StringConcatenation();
+    builder.append(codeConfig.getFileHeader());
+    builder.newLineIfNotEmpty();


did you see this comment?

rubenporras · 2026-06-23T07:11:40Z

+    builder.append(_grammarAccessExtensions.gaElementIdentifier(AntlrGrammarGenUtil.getOriginalElement(it)));
+    builder.append("__Impl");
+    builder.newLineIfNotEmpty();
+    builder.append("  ");


this for example, I think it would truly benefit from a multi-line string

rubenporras · 2026-06-23T07:12:03Z

+    builder.append(this._grammarAccessExtensions.getGrammarAccess(it).getSimpleName(), "    ");
+    builder.append(" grammarAccess, ParserContext parserContext, ");
+    builder.append(this.predicatesNaming.getSemanticPredicatesSimpleName(it), "    ");
+    builder.append(" predicates) {");


@members

…eAntlrGrammarGenerator Collapse the pure-static append runs (parser imports block, the @members comment, the constructor body, and the getFirstRuleName/getGrammarAccess methods) into Java text blocks. Single-line two-arg appends (rule name, grammar-access simple name) fold to %s as the re-indent is a no-op for single-line values. Each run proven byte-identical via the StringConcatenation-vs-text-block harness; loops/appendImmediate/dynamic parts are left intact. Generated grammar unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…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 #1429); per-module Xtend infrastructure cleanup is deferred until both halves merge. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

joaodinissf mentioned this pull request Jun 17, 2026

refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.generator (builder group) #1430

Merged

joaodinissf marked this pull request as ready for review June 17, 2026 16:25

joaodinissf requested a review from rubenporras June 17, 2026 16:25

rubenporras requested changes Jun 18, 2026

View reviewed changes

joaodinissf requested a review from rubenporras June 22, 2026 15:19

rubenporras requested changes Jun 23, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.generator (parser group)#1429

refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.generator (parser group)#1429
joaodinissf wants to merge 4 commits into
dsldevkit:masterfrom
joaodinissf:migrate/xtend-to-java/xtext-generator-parser

joaodinissf commented Jun 16, 2026

Uh oh!

rubenporras left a comment

Uh oh!

rubenporras Jun 18, 2026

Uh oh!

rubenporras Jun 18, 2026

Uh oh!

rubenporras Jun 23, 2026

Uh oh!

rubenporras Jun 18, 2026

Uh oh!

rubenporras Jun 18, 2026

Uh oh!

rubenporras Jun 23, 2026

Uh oh!

rubenporras Jun 23, 2026

Uh oh!

rubenporras Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

joaodinissf commented Jun 16, 2026

Notes

Uh oh!

rubenporras left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants