Regression when using plain SQL H2 array types

[lalithsuresh]

Expected behavior

The following piece of code works with H2 1.4.200 and JOOQ 3.13.1

    @Test
    public void testcase() {
        // create database
        final DSLContext conn = DSL.using("jdbc:h2:mem:");

        conn.execute("CREATE TABLE t1 (" +
                "c1 integer NOT NULL, " +
                "c2 array NOT NULL" +
                ")"
        );

        // insert data
        conn.execute("insert into t1 values (1, ARRAY[100])");
        final Result<Record> fetch1 = conn.fetch("select * from t1");
        System.out.println(Arrays.toString(fetch1.get(0).get(1, Object[].class)));
    }

It prints:

[100]

Actual behavior

With JOOQ 3.14.8 however, I get:

org.jooq.exception.DataTypeException: No Converter found for types java.lang.Object and [Ljava.lang.Object;

	at org.jooq.impl.Tools.converterOrFail(Tools.java:1149)
	at org.jooq.impl.Tools.converterOrFail(Tools.java:1165)
	at org.jooq.impl.AbstractRecord.get(AbstractRecord.java:285)

Any guidelines on what changed and if there is a Record.get(index, class) overload that would still work (and retrieve the underlying Object[])?

Steps to reproduce the problem

See testcase above.

Versions

• jOOQ: 3.14.8
• Java: OpenJDK 12.0.1
• Database (include vendor): H2 1.4.200
• OS: Mac OS Big Sur 11.2.3
• JDBC Driver (include name if inofficial driver):

[lukaseder]

Thanks a lot for your report. I can reproduce this problem. The regression seems to have been introduced with #10071 and related work around the new ConverterProvider SPI, which only takes the Class<T> and Class<U> references into consideration, not the actual T type. This is problematic for Object.class, which stands for unknown types. There's a DEBUG level log message hinting at the underlying problem here:

DEBUG [org.jooq.impl.MetaDataFieldProvider               ] - Not supported by dialect : Type ARRAY is not supported in dialect H2

This message was already present in jOOQ 3.13, so in a way, this has worked "by accident".

Due to #10071 and the improvements that have been implemented at the time, we can no longer rely on the T type, because we might not know it in advance when we need the converter already. However, we can continue supporting these cases by adding a new branch to the DefaultConverterProvider that attempts to downcast T to U, whenever Class<T> is Object.class, or more formally, whenever tType.isAssignableFrom(uType), we can safely upcast (T) u when writing to the DB and attempt to downcast (U) t when reading from the DB, possibly failing at runtime.

[lukaseder]

Fixed in jOOQ 3.15.0 and 3.14.9 (#11764). Thanks again for your report!