refactor: migrate Xtend to Java - com.avaloq.tools.ddk.check.core#1452
Draft
joaodinissf wants to merge 3 commits into
Draft
refactor: migrate Xtend to Java - com.avaloq.tools.ddk.check.core#1452joaodinissf wants to merge 3 commits into
joaodinissf wants to merge 3 commits into
Conversation
0a18923 to
0f48915
Compare
Pure git mv of the 8 remaining .xtend sources to .java, content unchanged, so the rename edge has 100% similarity and git log --follow and git blame permanently traverse the migration boundary. This intermediate commit intentionally does not compile; the translation follows in the next commit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
In-place translation of the 8 renamed sources, faithful to the Xtend compiler's own xtend-gen output (fresh ground-truth build). The three byte-critical emitters (CheckGeneratorExtensions, CheckGenerator, CheckJvmModelInferrer) keep the exact StringConcatenation call sequences incl. two-arg append(value, indent) and newLineIfNotEmpty. Notable per-file points: - CheckJvmModelInferrer: Xtend's JvmTypesBuilder '+=' silently skips null elements; the plain Iterables.addAll translation let null JvmMembers reach the type resolver (IllegalArgumentException: element: null, reproduced by the CheckValidationTest severity-range stubs). The two affected call sites are wrapped in IterableExtensions.filterNull like every sibling site. - CheckGeneratorExtensions.getContents: two deliberate output-neutral hardenings (explicit UTF-8; IllegalStateException wrapping of checked exceptions), documented in the PR. - splitCamelCase uses .formatted() per repo convention (behavior-identical to the String.format xtend-gen emitted). - CheckGeneratorNaming/CheckGenerator: Javadoc completed with @param/@return where originals carried plain block comments (checkstyle JavadocMethod gate). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The module is fully off Xtend: remove the xtend-gen source folder from build.properties and .classpath, the xtextBuilder/xtextNature from .project, and the xtend-gen directory marker — matching the other fully migrated modules. No Require-Bundle change needed (the module declares no Xtend bundles; xtend2.lib/xbase.lib resolve transitively for the StringConcatenation-based generators). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0f48915 to
72b635e
Compare
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 last 8
.xtendfiles ofcom.avaloq.tools.ddk.check.core— the production Check framework — to Java 21, a two-step rename→translate structure plus a final commit dropping the module's Xtend build infrastructure:CheckGeneratorConfigCheckGeneratorNamingCheckTypeComputerCheckScopeProviderCheckFormatterCheckGeneratorExtensionsCheckGeneratorCheckJvmModelInferrerThe three byte-critical emitters keep the exact
StringConcatenationcall sequences of the Xtend compiler's own output (xtend-gen), including two-argappend(value, indent)andnewLineIfNotEmpty()semantics — generated artifacts are byte-identical.Infrastructure cleanup (module now fully off Xtend, matching the other migrated modules):
xtend-gen/removed frombuild.propertiesand.classpath,xtextBuilder/xtextNatureremoved from.project,xtend-gen/directory deleted. NoRequire-Bundlechange: the module declares no Xtend bundles;xtend2.lib/xbase.libresolve transitively for theStringConcatenation-based generators, which remain by design.Verification
xtend-genground-truth build: append-for-append comparison plus executable byte-equality harnesses (realStringConcatenation, batteries covering empty/single-/multi-line/quotes/%/unicode inputs) for all templates of the three emitters — all IDENTICAL (~150 harness cases).xtend-gen— identical for all dispatchers (incl. the 47-branchCheckFormatter.format).clean verify checkstyle:check pmd:check spotbugs:check(PMD 7.26.0) → BUILD SUCCESS, 0 violations, 357 tests, 0 failures, 0 errors — identical to the pre-migration baseline on the same tree (one pre-existing SWTBot flake,testBulkApplyingQuickfix, appeared in a later re-run and is unrelated).IssueCodeToLabelMapGenerationTest,IssueCodeValueTest) green; no drift in any committed generated artifact.Faithfulness notes
+=null-safety restored inCheckJvmModelInferrer: Xtend's+=silently skipsnull; the plainIterables.addAlltranslation let nullJvmMembers reach the type resolver (IllegalArgumentException: element: null, reproduced by theCheckValidationTestseverity-range stubs). The two affected call sites are wrapped inIterableExtensions.filterNull, like every sibling site.Deliberate deviations (output-neutral)
StandardCharsets.UTF_8inCheckGeneratorExtensions.getContentsinstead of the platform-default charset. Identical behavior on Java 18+ (JEP 400); the sole caller reads the service-registry file, which contains only ASCII fully-qualified class names, so emitted output is provably unchanged under any default charset.IllegalStateExceptionwrapping of checked exceptions there instead of Xtend's sneaky-throw. Differs only in the thrown type on I/O failure (the build fails either way); no effect on generated output..formatted()replaces theString.formatthe Xtend compiler emitted insplitCamelCase(repo convention; behavior-identical).@param/@return) onCheckGeneratorNaming/CheckGeneratormethods whose originals carried plain block comments — required by the checkstyleJavadocMethodgate once the comments became Javadoc.🤖 Generated with Claude Code