While working on spring-cloud/spring-cloud-gateway#4129 I needed to clear the context path
of a request through mutate(). My first try was contextPath(null) but NullAway fails
the build with:
passing @Nullable parameter 'null' where @NonNull is required
The package is @NullMarked and the builder method dosen't have @Nullable on the
parameter, so null is not allowed. I ended up using contextPath("") as a workarround.
In the review it was asked if null could work here instead, discussion is here:
spring-cloud/spring-cloud-gateway#4129 (comment)
The confusing part is that everything below the builder method already accepts null:
DefaultServerHttpRequestBuilder stores it in a @Nullable String contextPath field
MutatedServerHttpRequest constructor also takes @Nullable String contextPath
DefaultRequestPath.initContextPath() handles null and treats it same as empty string
So only the public builder method forbids null. Is this intentional or an oversight from
the JSpecify migration? If its an oversight, can the parameter be marked @Nullable?
Checked on 7.0.8 and also on current main, same behaviour in both.
While working on spring-cloud/spring-cloud-gateway#4129 I needed to clear the context path
of a request through
mutate(). My first try wascontextPath(null)but NullAway failsthe build with:
passing @Nullable parameter 'null' where @NonNull is requiredThe package is
@NullMarkedand the builder method dosen't have@Nullableon theparameter, so null is not allowed. I ended up using
contextPath("")as a workarround.In the review it was asked if null could work here instead, discussion is here:
spring-cloud/spring-cloud-gateway#4129 (comment)
The confusing part is that everything below the builder method already accepts null:
DefaultServerHttpRequestBuilderstores it in a@Nullable String contextPathfieldMutatedServerHttpRequestconstructor also takes@Nullable String contextPathDefaultRequestPath.initContextPath()handles null and treats it same as empty stringSo only the public builder method forbids null. Is this intentional or an oversight from
the JSpecify migration? If its an oversight, can the parameter be marked
@Nullable?Checked on 7.0.8 and also on current main, same behaviour in both.