fix(java): M:N resolvers resolve FQN exactly (ADR-0041 follow-up)#175
Merged
Conversation
…ollision fixture Follow-up to PR #173. A code review found the Java M:N runtime/derivation resolvers still carried the exact bare-tail FQN mis-bind bug ADR-0041 closes (the same class as the confirmed bug, in the M:N path, Java-only — TS/Kotlin/C#/ Python M:N were already FQN-safe): - metadata M2MFields (the cross-port FK-derivation SSOT): findObject stripped an FQN to its bare tail and matched getShortName(); isSelfJoin / findRefToEntity compared stripped bare tails — so a cross-package hetero M:N with a same-named entity mis-classified as a self-join / bound the wrong junction reference. - omdb runtime M2MResolver.mustGetEntity: same stripPackage-then-short-name match on the FQN @objectRef/@through at runtime traversal. Fix (mirrors the SpringM2mSupport fix from #173): resolve the @objectRef/@through to an object FQN-exact (an FQN matches getName() exactly, never a bare-tail fallback), and classify self-join / match junction references by RESOLVED object identity, never a stripped tail. Bare-name/same-package behavior unchanged (the broader bare-collision same-package preference stays #174). Gated: new conformance fixture xpkg-m2n-collision (a cross-package M:N where the target + junction share a bare name with entities in other packages, referenced by FQN) — a bare-tail match would bind the wrong package. Expected generated from the TS oracle. Green in all metamodel-conformance ports: TS 422, Java 422, Python 324, C# 712 (Kotlin rides the shared Java loader). ADR-0041 Consequences corrected to name the files actually changed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ew1XfYSbEAezxjs9opynAe
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
1 participant
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.
Follow-up to #173. A cross-port code review found the Java M:N runtime/derivation resolvers still carried the exact bare-tail FQN mis-bind bug ADR-0041 closes — the same class as the confirmed bug, in the M:N path, Java-only (TS/Kotlin/C#/Python M:N were already FQN-safe).
M2MFields(the cross-port FK-derivation SSOT):findObjectstripped an FQN to its bare tail;isSelfJoin/findRefToEntitycompared stripped tails → a cross-package hetero M:N with a same-named entity mis-classified as a self-join / bound the wrong junction reference.omdbruntimeM2MResolver.mustGetEntity: samestripPackage-then-short-name match on the FQN@objectRef/@through.Fix (mirrors the
SpringM2mSupportfix from #173): resolve to an object FQN-exact, classify self-join / match junction references by resolved object identity, never a stripped tail. Bare/same-package behavior unchanged (broader bare-collision same-package preference stays #174).Gated: new
xpkg-m2n-collisionconformance fixture (loads + round-trips the cross-package same-named M:N cross-port — TS 422 / Java 422 / Python 324 / C# 712) plus Java unit tests inM2MSlimVocabularyTest(16/0) that assertM2MFields.derivebinds the correct package — because the canonical serializer doesn't surface derive's result, the unit tests are the actual derive gate. ADR-0041 Consequences corrected.🤖 Generated with Claude Code