Skip to content

Codegen/runtime same-package-preference for bare colliding object-refs (ADR-0041 follow-up) #174

Description

@dmealing

Follow-up to ADR-0041 / PR #173, which landed the cross-package reference-resolution contract at the loader level (FQN-exact + ERR_AMBIGUOUS_REF on bare cross-package ambiguity), conformance-gated across all 5 ports.

Residual: several codegen + runtime resolvers still bare-name first-match (no same-package preference) on a same-name-across-packages collision. FQN-exact is fixed everywhere the confirmed bug lived; a bare ambiguous ref is caught loudly at load (ERR_AMBIGUOUS_REF) before it reaches these — but a bare ref that resolves at load (own-package or unique) could still bind the wrong package in codegen/runtime if a collision exists.

Sites (per port), to thread the referrer package through:

  • TS: codegen-ts relation-resolver.ts / import-path.ts (bare-keyed packageOf).
  • JVM: codegen-spring SpringPayloadGenerator/SpringM2mSupport (bare arm), codegen-kotlin KotlinGenUtil.resolveObjectByShortOrFqn; runtime omdb/M2MResolver.java (stripPackage); metadata M2MFields.java (stripPackage in self-join detection + findRefToEntity) — the last can mis-detect a cross-package same-named M:N as a self-join.
  • C#/Python: the equivalent codegen resolvers.

Also add a same-named-cross-package M:N collision conformance/codegen fixture (none today).

Not urgent: the loader contract + ERR_AMBIGUOUS_REF guard the dangerous cases; this is correctness hardening for the narrow bare-collision-that-resolves case.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions