HSQLDB incorrectly reports java.lang.Integer as the Java class for both TINYINT and SMALLINT columns through ResultSetMetaData.getColumnClassName(int).
The JDBC type reported by ResultSetMetaData.getColumnType(int) is correct in both cases, but the corresponding Java class name is incorrectly reported as java.lang.Integer instead of the Java wrapper type corresponding to the JDBC type.
CREATE TABLE test_table (
tinyint_col TINYINT,
smallint_col SMALLINT
);
Then inspect the column metadata:
ResultSetMetaData metadata = resultSet.getMetaData();
for (int i = 1; i <= metadata.getColumnCount(); i++) {
System.out.println(
"name=" + metadata.getColumnName(i) +
", typeName=" + metadata.getColumnTypeName(i) +
", type=" + metadata.getColumnType(i) +
", className=" + metadata.getColumnClassName(i)
);
}
name=TINYINT, typeName=TINYINT, type=-6, className=java.lang.Integer
name=SMALLINT, typeName=SMALLINT, type=5, className=java.lang.Integer
name=TINYINT, typeName=TINYINT, type=-6, className=java.lang.Byte
name=SMALLINT, typeName=SMALLINT, type=5, className=java.lang.Short
The return type of Integer is correct for the two narrower types. This is listed in "JDBC 4.3 Specification • July 2017".
Well, yes, Table B-3 clearly specifies TINYINT and SMALLINT -> Integer. However, given that the ranges of these SQL types fit within Java's byte and short ranges, respectively, wouldn't returning the more precise Java class names (Byte and Short) be a reasonable improvement rather than a deviation from the specification?
I understand that the specification defines Integer as the default mapping, but does that necessarily mean a driver should not expose a more precise class through ResultSetMetaData.getColumnClassName().
It returns an Integer, therefore the Java class name is "Integer".