All versions: 3.11 | Development versions: 3.12

The SPI methods handling these events are unnecessaryWasNullCall()

This problem appears only when using the JDBC API directly, as both jOOQ and most ORMs abstract over this JDBC legacy correctly. In JDBC, when fetching a primitive types (and some types are available only in their primitive form), a subsequent call to ResultSet.wasNull() is required, to see if the previous primitive type was really a NULL value, not a 0 or false value.

Why is it bad?

There are two misuses that can arise in this area:

  • The call to wasNull() wasn't made when it should have been (nullable type, fetched as a primitive type), possibly resulting in wrong results in the client.
  • The call to wasNull() was made too often, or when it did not need to have been made (non-nullable type, or types fetched as reference types), possibly resulting in a very slight performance overhead, depending on the driver.

An example is given here:

// A custom DiagnosticsListener SPI implementation
class WasNull extends DefaultDiagnosticsListener {
    @Override
    public void tooManyRowsFetched(DiagnosticsContext ctx) {
        System.out.println("Unnecessary wasNull() call: " + ctx.resultSetUnnecessaryWasNullCall());
        System.out.println("Missing wasNull() call: " + ctx.resultSetMissingWasNullCall());
    }
}

// Configuration is configured with the target DataSource, SQLDialect, etc. for instance Oracle.
try (Connection c = DSL.using(configuration.derive(new WasNull()))
                       .diagnosticsConnection();
     Statement s = c.createStatement()) {
     
    try (ResultSet rs = s.executeQuery("SELECT year_of_birth FROM author")) {
    
        // The YEAR_OF_BIRTH column is nullable, so a 0 int could really mean null
        while (rs.next())
            System.out.println("Year of birth: " + rs.getInt(1));
    }
}
The jOOQ Logo