Skip to content

Check contract member accessibility for referenced builders (#313) - #314

Merged
AndreasIgel merged 4 commits into
java-helpers:mainfrom
igel-devin-ai:devin/visible-builder-contract
Oct 1, 2026
Merged

AndreasIgel merged 4 commits into
java-helpers:mainfrom
igel-devin-ai:devin/visible-builder-contract

Conversation

@igel-devin-ai

Copy link
Copy Markdown
Collaborator

Issues: resolves #313 · sub-task of #301 · follow-up to #308 (#311)

Problem

resolveByBuilderContract verified the referenced builder's contract by presence only: a private or cross-package package-private ctor(T), no-arg B() or build() satisfied the contract, but generated consumer code calls these members — producing uncompilable code whenever they were not accessible from the generated builder's package.

Fix

The three contract helpers in JavaLangAnalyser (hasConstructorAccepting, hasEmptyConstructor, hasBuildMethodReturning) now filter member streams through ProcessingContext.isMemberAccessibleFromBuilderPackage before matching — the same accessibility rule already used for member collection elsewhere, so it behaves consistently for B(), ctor(T), build() and later #309 factory methods. hasEmptyConstructor is also consumed by JavaLangMapper, which emits new X() into generated code — the same rule applies there.

Cache fix

BuilderScopeResolver now tracks builderPackage alongside the cached configuration. Resolution results are cached per referenced type; with accessibility in the contract, the accessible-member set depends on the generated builder's package, which can differ between targets sharing a configuration.

Tests

  • resolverUsageScope_RejectsBuilderWithPrivateConstructor — private B() no longer satisfies the contract.
  • resolverUsageScope_PackagePrivateMembers_AccessibleOnlyFromSamePackage — package-private members qualify when the generated builder shares the package, and are rejected otherwise.

475 processor tests green.

Docs

Javadoc on resolve()/resolveByBuilderContract and both contract descriptions in docs/CONFIGURATION.md now state that members must be accessible from the generated builder's package.

…s#313)

The contract checks in resolveByBuilderContract verified member presence
only: a private or cross-package package-private ctor(T), B() or build()
passed the contract but produced uncompilable generated code. The three
JavaLangAnalyser helpers now filter members through
isMemberAccessibleFromBuilderPackage before matching, consistent with the
member checks used elsewhere.

The resolver's refresh now also tracks builderPackage, not just the
configuration: resolution results are cached per referenced type, and
the accessible-member set depends on the generated builder's package,
which may differ between targets sharing a configuration.

Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
@codecov

codecov Bot commented Oct 1, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

devin-ai-integration Bot and others added 3 commits October 1, 2026 19:53
Replace the two loosely related cache markers (cachedConfiguration,
cachedBuilderPackage) with a record compared as a unit, so the
invalidation condition reads as 'the inputs are unchanged'.

Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
The field holds the inputs the resolution cache was built under, so the
cached marker belongs in the name.

Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
@sonarqubecloud

sonarqubecloud Bot commented Oct 1, 2026

Copy link
Copy Markdown

@AndreasIgel
AndreasIgel merged commit b1dc35d into java-helpers:main Oct 1, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make referenced-builder contract checks visibility-aware

2 participants