Adopt jspecify + NullAway null-checking on fdb-relational-jdbc - #4533
Conversation
Companion change to the fdb-relational-grpc null-checking adoption, stacked on that branch. Same treatment: jspecify + NullAway wired via net.ltgt.errorprone, scoped to this module only; the com.apple.foundationdb.relational.jdbc package is marked @NullMarked; javax.annotation.Nonnull/Nullable usages replaced with jspecify's @nullable. Compiling with NullAway surfaced several previously undocumented nullable fields/returns (JDBCRelationalConnection's serverConnection/ closeable/schema, JDBCRelationalStatement's currentResultSet, StatefulServerConnection's requestSender) and one latent bug: schema being null (no schema set yet) was passed straight into a protobuf StatementRequest/InsertRequest builder that expects a String, which would have NPE'd inside protobuf rather than failing clearly at the call site; now coerced to "" explicitly at all four call sites. executeGet/executeScan keep their existing (pre-jspecify) @SpotBugsSuppressWarnings("NP_NONNULL_RETURN_VIOLATION") — they genuinely violate the @nonnull contract of RelationalDirectAccessStatement today, "temporary until implemented"; adding jspecify @nullable there would conflict with the @nonnull declared on the interface they override, so NullAway is suppressed at the same two sites with the same justification instead.
arnaud-lacurie
left a comment
There was a problem hiding this comment.
Inline notes for the jspecify + NullAway findings mentioned in the PR description.
| .setSql(sql) | ||
| .setDatabase(getDatabase()) // TODO: for transactional execution these are not required | ||
| .setSchema(getSchema()) | ||
| .setSchema(Objects.requireNonNullElse(getSchema(), "")) |
There was a problem hiding this comment.
Latent bug caught by NullAway: schema is null before one is set, but was being passed straight into a protobuf builder's setSchema(String), which NPEs on null input. Coerced to "" here and at the other three call sites (below, and in JDBCRelationalStatement) rather than deep inside generated protobuf code.
| .setDataResultSet(TypeConversion.toResultSetProtobuf(data)) | ||
| .setDatabase(getDatabase()) | ||
| .setSchema(getSchema()) | ||
| .setSchema(Objects.requireNonNullElse(getSchema(), "")) |
There was a problem hiding this comment.
Same null-schema-into-protobuf-setter fix as above.
| .setKeySet(TypeConversion.toProtobuf(keySet)) | ||
| .setDatabase(this.connection.getDatabase()) | ||
| .setSchema(this.connection.getSchema()) | ||
| .setSchema(Objects.requireNonNullElse(this.connection.getSchema(), "")) |
There was a problem hiding this comment.
Same null-schema-into-protobuf-setter fix as in JDBCRelationalConnection.
| .setKeySet(TypeConversion.toProtobuf(keySet)) | ||
| .setDatabase(this.connection.getDatabase()) | ||
| .setSchema(this.connection.getSchema()) | ||
| .setSchema(Objects.requireNonNullElse(this.connection.getSchema(), "")) |
There was a problem hiding this comment.
Same null-schema-into-protobuf-setter fix, fourth and last call site.
Second of a two-PR stack adopting jspecify + NullAway null-checking — stacked on #4532 (
fdb-relational-grpc). Same treatment applied tofdb-relational-jdbc. See inline comments for specific findings.