I thought I knew everything about UDTs and JDBC until someone on SO pointed out some details of the Javadoc of java.sql.SQLInput and java.sql.SQLData JavaDoc to me. The essence of that hint was (from SQLInput):

An input stream that contains a stream of values representing an instance of an SQL structured type or an SQL distinct type. This interface, used only for custom mapping, is used by the driver behind the scenes, and a programmer never directly invokes SQLInput methods.

This is quite the opposite of what I am used to do (which is also used and stable in productive systems, when used with the Oracle JDBC driver): Implement SQLData and provide this implementation in a custom mapping to

ResultSet.getObject(int index, Map mapping)

The JDBC driver will then call-back on my custom type using the

SQLData.readSQL(SQLInput stream, String typeName)

method. I implement this method and read each field from the SQLInput stream. In the end, getObject() will return a correctly initialised instance of my SQLData implementation holding all data from the UDT.

To me, this seems like the perfect way to implement such a custom mapping. Good reasons for going this way:

• I can use the standard API, instead of using vendor-specific classes such as oracle.sql.STRUCT, etc.
• I can generate source code from my UDTs, with appropriate getters/setters and other properties

My questions:

• What do you think about my approach, implementing SQLData? Is it viable, even if the Javadoc states otherwise?
• What other ways of reading UDT's in Java do you know of? E.g. what does Spring do? what does Hibernate do? What does JPA do? What do you do?

Addendum:

UDT support and integration with stored procedures is one of the major features of jOOQ. jOOQ aims at hiding the more complex "JDBC facts" from client code, without hiding the underlying database architecture. If you have similar questions like the above, jOOQ might provide an answer to you.