SONARJAVA-6897 Use the Spring profile expression parser in Spring context collection

[aurelien-coet-sonarsource]

---

Summary by Gitar

• Spring Profile Support:
  • Replaced raw profile strings with ProfileExpression in BeanDefinitionHolder and related collection logic
  • Integrated ProfileExpressionParser in SpringUtils to correctly parse logical operators and combine class/method profiles

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-6897

✅ All code review findings resolved.

_{Configure merge blocking}

[gitar-bot]

Code Review ✅ Approved 2 closed / 2 findings

🟡 Medium risk

Integrates ProfileExpressionParser into Spring context collection to correctly handle profile logical operators and combine class/method profiles. Resolves test compilation issue with Optional assertion and unknown profile expression handling.

✅ 2 closed

✅ Bug: Test file does not compile: Optional assertion left on a List

📄 java-frontend/src/test/java/org/sonar/java/model/springcontext/SpringContextCacheHelperTest.java:110-115 📄 java-frontend/src/test/java/org/sonar/java/model/springcontext/SpringContextCacheHelperTest.java:28 📄 java-frontend/src/test/java/org/sonar/java/model/springcontext/SpringContextCacheHelperTest.java:299-301
readBeans now returns List<BeanDefinitionHolder.InputFileData> instead of Optional<List<...>>, but a_profile_expression_that_cannot_be_parsed_is_restored_as_unknown was not migrated with the rest of the file and still calls hasValueSatisfying(...), which AssertJ only declares on AbstractOptionalAssert and not on ListAssert/AbstractIterableAssert. assertThat(List) therefore has no such method and the java-frontend test sources fail to compile, breaking the whole test run. Assert on the restored list directly (the leftover javax.annotation.Nullable import at line 28, orphaned by the removal of readContext, can be dropped in the same pass).

✅ Bug: Unknown profile expression drops bean from candidate set

📄 java-checks/src/main/java/org/sonar/java/checks/spring/AmbiguousDependencyCheck.java:100-102 📄 java-frontend/src/main/java/org/sonar/java/utils/SpringUtils.java:265-279
hasProfile now returns true for any expression that is not UNCONDITIONAL, which includes ProfileExpression.UNKNOWN (produced by SpringUtils.extractProfileExpression for any @Profile the parser rejects, e.g. @Profile("a & b | c")). Such a candidate is therefore removed by excludeCandidatesWithProfile, shrinking the effective candidate set and suppressing an ambiguity issue that Spring would actually hit — the opposite of the contract stated for the new type, whose javadoc says an expression we do not understand is never taken to make a bean inactive and that callers treat UNKNOWN as possibly active (ProfileExpression.java:60,199-206, ProfileExpressionParser.java:42-45). Excluding only genuinely conditional beans keeps the parser's strictness free of behavioural cost.

Review coverage

Functional validation 1 of 1 objectives covered

Rules No rules evaluated

Auto-approval Not enabled · Set up

Implementation Status ✅ 1 of 1 objectives covered

✅ SONARJAVA-6897 - 1 of 1 objectives covered

This PR covers the objective to add support for '!', '&', and '|' operators in the @Profile annotation during Spring context collection.

✅ 1 covered here

• ✅ Add support for '!', '&', '|' operators in @Profile annotation during Spring context collection

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
2 Dependency risks
97.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube