Support type-use @Nullable annotation in annotated service

[sh-cho]

Motivation:

In annotated service, type-use @Nullable annotation (ex. jspecify) is not respected.

Modifications:

• Add jspecify dependency
  • (Migration in progress. See Migrate to JSpecify annotations #6456)
• In AnnotatedValueResolver#isAnnotatedNullable, add checks for type-use nullable annotation

Result:

• Resolves @Nullable TYPE_USE annotation is not respected in annotated service #6454

[github-actions]

🔍 Build Scan® (commit: c016834)

Job name	Status	Build Scan®
build-ubicloud-standard-16-jdk-8	✅	https://ge.armeria.dev/s/o436upauxk6w4
build-ubicloud-standard-16-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/cgp7ze5gs7p2g
build-ubicloud-standard-16-jdk-17-min-java-17-coverage	✅	https://ge.armeria.dev/s/anwfdlx4gwrak
build-ubicloud-standard-16-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/xzopef6afqmjs
build-ubicloud-standard-16-jdk-17-leak	✅	https://ge.armeria.dev/s/3lphdl5nkcd64
build-ubicloud-standard-16-jdk-11	✅	https://ge.armeria.dev/s/y2ncumep426ty
build-macos-latest-jdk-21	✅	https://ge.armeria.dev/s/v4dgugy6sl2de

[codecov]

Codecov Report

❌ Patch coverage is 81.25000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.11%. Comparing base (8150425) to head (c016834).
⚠️ Report is 229 commits behind head on main.

Files with missing lines	Patch %	Lines
...rnal/server/annotation/AnnotatedValueResolver.java	81.25%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6457      +/-   ##
============================================
- Coverage     74.46%   74.11%   -0.35%     
- Complexity    22234    23005     +771     
============================================
  Files          1963     2062      +99     
  Lines         82437    86144    +3707     
  Branches      10764    11314     +550     
============================================
+ Hits          61385    63846    +2461     
- Misses        15918    16883     +965     
- Partials       5134     5415     +281     

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[minwoox]

Left small suggestions. Thanks, @sh-cho!

[minwoox]

Could you add examples so that readers can distinguish them easily? e.g.

@Nullable // declaration annotation
public String declarationAnnotatedMethod() {
    return null;
}

// type-use annotation
public @Nullable String typeUseAnnotatedMethod() {
    return null;
}

[sh-cho]

Ok, I added comment
ca1e429 (#6457)

[minwoox]

Could you also add a test with this?

public @Nullable String typeUseAnnotatedMethod() {
    return null;
}

[ikhoon]

We may use @RequestObject to test it.

[sh-cho]

Added test for nullable response
8d850d9 (#6457)

Also I tried to test with @RequestObject like below, but looks like @Nullable doesn't affect 👀 (empty body is rejected even if there's @Nullable)

@Post("/foo")
@ProducesJson
public Map<String, Object> foo(@RequestObject Map<String, Object> map) {
    return map;
}

@Post("/bar")
@ProducesJson
public Map<String, Object> bar(@RequestObject @Nullable Map<String, Object> map) {
    if (map == null) {
        return Map.of("this is", "null");
    }
    return map;
}

[minwoox]

empty body is rejected even if there's @nullable

I think it shouldn't throw an exception if it's annotated with the @Nullable.
What do you think of it? @line/dx

[jrhee17]

I agree the behavior sounds reasonable - I'm not sure whether this is enforceable for all cases though. I have no objection if for Jackson's case where a literal null body is received, a null value is passed as the request object.

Having said this, I'm fine with going ahead with merging this PR and handling this separately as they seem to be separate issues

[minwoox]

I'm fine with going ahead with merging this PR and handling this separately as they seem to be separate issues

I agree. We don't have to deal with this in this PR. Let me merge this. 😉

[minwoox]

Thanks a lot, @sh-cho! 😄