refactor(jdbc): migrate write path and metadata to TypeRegistry - #14061

The Javadoc comments here are misplaced. The Javadoc for toJavaClass(int) (/** Returns the default Java target class for a given JDBC type constant. */) has been left above toJdbcType, resulting in double Javadocs for toJdbcType and none for toJavaClass(int).

Additionally, we can introduce a non-lossy toJavaClass(StandardSQLTypeName) method to avoid converting StandardSQLTypeName to a JDBC int type first (which loses precision for types like GEOGRAPHY, JSON, INTERVAL, and RANGE that all map to Types.OTHER).

  /** Returns the JDBC Type constant for a given BigQuery type. */
  public static int toJdbcType(StandardSQLTypeName bqType) {
    if (bqType == null) return Types.OTHER;
    int ordinal = bqType.ordinal();
    if (ordinal >= DESCRIPTORS_BY_ORDINAL.length || DESCRIPTORS_BY_ORDINAL[ordinal] == null) {
      return Types.OTHER;
    }
    return DESCRIPTORS_BY_ORDINAL[ordinal].getJdbcType();
  }

  /** Returns the default Java target class for a given BigQuery type. */
  public static Class<?> toJavaClass(StandardSQLTypeName bqType) {
    if (bqType == null) return null;
    int ordinal = bqType.ordinal();
    if (ordinal >= DESCRIPTORS_BY_ORDINAL.length || DESCRIPTORS_BY_ORDINAL[ordinal] == null) {
      return null;
    }
    return DESCRIPTORS_BY_ORDINAL[ordinal].getJavaClass();
  }

  /** Returns the default Java target class for a given JDBC type constant. */
  public static Class<?> toJavaClass(int jdbcType) {

Using BigQueryTypeRegistry.toJavaClass(BigQueryTypeRegistry.toJdbcType(sqlType)) is lossy because multiple distinct BigQuery types (such as GEOGRAPHY, JSON, INTERVAL, and RANGE) all map to Types.OTHER. Converting them to a JDBC type first and then to a Java class loses the specific type information and can return null or incorrect classes.

Instead, use the direct toJavaClass(StandardSQLTypeName) method.

Similarly, using BigQueryTypeRegistry.toJavaClass(BigQueryTypeRegistry.toJdbcType(...)) is lossy and can lead to NullPointerException if toJavaClass returns null.

Instead, use the direct toJavaClass(StandardSQLTypeName) method and add a safe null check.

    Class<?> clazz = BigQueryTypeRegistry.toJavaClass(getStandardSQLTypeName(column));
    return clazz != null ? clazz.getName() : null;

Since BigQueryTypeRegistry.toJdbcType(sqlType) returns a primitive int, the local variable jdbcType (autoboxed to Integer) can never be null. The null check if (jdbcType != null) is dead code.

Furthermore, toJdbcType(null) already returns Types.OTHER by default, so we can simplify this entire block to a single return statement.

    return BigQueryTypeRegistry.toJdbcType(sqlType);

The JDBC_TO_JAVA_CLASS_MAP is missing several common JDBC type mappings, such as Types.DECIMAL (which should map to BigDecimal.class), Types.CHAR (which should map to String.class), and potentially Types.REAL or Types.CLOB. Without these mappings, calling methods like setNull or registerOutParameter with these standard JDBC types will throw a BigQueryJdbcSqlFeatureNotSupportedException at runtime, which could break compatibility with existing ORMs or database tools.

  private static final Map<Integer, Class<?>> JDBC_TO_JAVA_CLASS_MAP =
      ImmutableMap.<Integer, Class<?>>builder()
          .put(Types.BIGINT, Long.class)
          .put(Types.INTEGER, Integer.class)
          .put(Types.SMALLINT, Short.class)
          .put(Types.TINYINT, Byte.class)
          .put(Types.BOOLEAN, Boolean.class)
          .put(Types.DOUBLE, Double.class)
          .put(Types.FLOAT, Float.class)
          .put(Types.REAL, Float.class)
          .put(Types.NUMERIC, BigDecimal.class)
          .put(Types.DECIMAL, BigDecimal.class)
          .put(Types.CHAR, String.class)
          .put(Types.VARCHAR, String.class)
          .put(Types.LONGVARCHAR, String.class)
          .put(Types.NCHAR, String.class)
          .put(Types.NVARCHAR, String.class)
          .put(Types.LONGNVARCHAR, String.class)
          .put(Types.CLOB, String.class)
          .put(Types.TIMESTAMP, Timestamp.class)
          .put(Types.DATE, Date.class)
          .put(Types.TIME, Time.class)
          .put(Types.OTHER, String.class)
          .put(Types.BINARY, byte[].class)
          .put(Types.VARBINARY, byte[].class)
          .put(Types.LONGVARBINARY, byte[].class)
          .put(Types.STRUCT, Struct.class)
          .put(Types.BIT, Boolean.class)
          .put(Types.ARRAY, Array.class)
          .put(Types.NULL, String.class)
          .build();

Since BigQueryTypeRegistry.toJavaClass(int) throws a BigQueryJdbcSqlFeatureNotSupportedException when the JDBC type is unsupported instead of returning null, the variable javaType will never be null. The subsequent null check is dead code and can be safely removed.

Since BigQueryTypeRegistry.toJdbcType(sqlType) returns a primitive int (which can never be null), the Integer boxing and subsequent null check are redundant. We can simplify this by checking against Types.OTHER (the fallback value returned by toJdbcType when unmapped) to ensure the rest of the method remains reachable.

Since BigQueryTypeRegistry.toJavaClass(StandardSQLTypeName) always returns a non-null class (falling back to String.class if the type is unmapped or null), the null check if (clazz != null) is redundant and can be simplified.