Skip to content

Fix for explicitly-typed lambda parameters in JDK 24+#1452

Merged
msridhar merged 2 commits intomasterfrom
issue-1448
Jan 27, 2026
Merged

Fix for explicitly-typed lambda parameters in JDK 24+#1452
msridhar merged 2 commits intomasterfrom
issue-1448

Conversation

@msridhar
Copy link
Copy Markdown
Collaborator

@msridhar msridhar commented Jan 27, 2026

This case worked before JDK 24 since somehow our code that looked at the owner of a symbol found the annotation; for some reason it stopped working. Looking at annotations on the type field of the symbol seems to find what we need.

Fixes #1448

Summary by CodeRabbit

Bug Fixes

  • Enhanced nullability annotation detection to recognize type-use annotations on symbol types, improving coverage for explicitly-annotated lambda parameters that were previously undetected.

Tests

  • Added test coverage for enhanced annotation detection in generic lambda scenarios.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jan 27, 2026

Walkthrough

The pull request extends annotation matching logic in NullabilityUtil's hasAnyAnnotationMatching method to inspect type-use annotations via symbol.type.getAnnotationMirrors() in addition to direct symbol annotations. This supplements existing annotation checking to capture type annotations on symbols like explicitly-annotated lambda parameters. A new test case is added to GenericLambdaTests to validate the behavior of nullable lambda parameters in generic functional interface field initializers.

Possibly related PRs

  • PR #1362: Modifies hasAnyAnnotationMatching to add or optimize annotation-matching logic for type-use annotations on symbols.
  • PR #1378: Extends nullability checks to inspect a symbol's type annotations in addition to symbol annotations for nested/type-use annotation preservation.
  • PR #1245: Updates tests and configuration flags (such as -XDaddTypeAnnotationsToSymbol=true) to ensure type annotations on symbols are properly exposed and accessible.

Suggested labels

jspecify

Suggested reviewers

  • yuxincs
  • lazaroclapp
🚥 Pre-merge checks | ✅ 4 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title accurately describes the main change: fixing explicitly-typed lambda parameters in JDK 24+, which is directly supported by the code changes and PR objectives.
Linked Issues check ✅ Passed The code changes directly address issue #1448 by extending annotation matching to cover type-use annotations, which fixes the false positive for explicitly-typed lambda parameters in field initializers.
Out of Scope Changes check ✅ Passed All changes are within scope: NullabilityUtil.java enhancement to detect type annotations and a test case verifying the fix for issue #1448; no unrelated modifications detected.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@codecov
Copy link
Copy Markdown

codecov Bot commented Jan 27, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.41%. Comparing base (1167221) to head (df04902).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1452      +/-   ##
============================================
- Coverage     88.41%   88.41%   -0.01%     
- Complexity     2714     2715       +1     
============================================
  Files            99       99              
  Lines          9015     9019       +4     
  Branches       1801     1803       +2     
============================================
+ Hits           7971     7974       +3     
  Misses          517      517              
- Partials        527      528       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@github-actions
Copy link
Copy Markdown

Main Branch:

Benchmark                          Mode  Cnt   Score   Error  Units
AutodisposeBenchmark.compile      thrpt   25  10.424 ± 0.019  ops/s
CaffeineBenchmark.compile         thrpt   25   1.982 ± 0.009  ops/s
DFlowMicroBenchmark.compile       thrpt   25  40.882 ± 0.242  ops/s
NullawayReleaseBenchmark.compile  thrpt   25   1.648 ± 0.012  ops/s

With This PR:

Benchmark                          Mode  Cnt   Score   Error  Units
AutodisposeBenchmark.compile      thrpt   25  10.424 ± 0.046  ops/s
CaffeineBenchmark.compile         thrpt   25   1.989 ± 0.012  ops/s
DFlowMicroBenchmark.compile       thrpt   25  40.552 ± 0.426  ops/s
NullawayReleaseBenchmark.compile  thrpt   25   1.658 ± 0.019  ops/s

@msridhar msridhar merged commit f3b9181 into master Jan 27, 2026
12 of 13 checks passed
@msridhar msridhar deleted the issue-1448 branch January 27, 2026 18:15
msridhar added a commit that referenced this pull request Jan 29, 2026
In #1452 we added a comment implying that change was needed due to a
`javac` bug but that was incorrect; it was our bug that was being masked
before. This PR fixes the comments (no behavior change).
This was referenced Apr 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Typed lambda parameter nullability not respected in field initializers for generic functional interfaces

2 participants