Context: Not a hibernate expert, working with postgres 9.4+ jsonb fields. When doing parameterized update with plain jdbc I can simply create a org.postgresql.util.PGobject and pass it as a parameter to PreparedStatement.setObject. It might be not reasonable to expect similar behavior from Hibernate, but the current behavior leaves me puzzled:

When a AttributeConverter<Map, Object> is used to build a similar PGobject, the following exception is raised by the postgres jdbc driver:



and the source of this type value can be traced to the following method of the JdbcTypeJavaClassMappings:



My question is: why to take the hashcode of the class of the attribute and use it as an "unknown" java.sql.Types value? Is there a good explanation for this seemingly random choice? If so, wouldn't it be nice to add it as a comment line, or better yet as a test?

If the "special code" is changed say to java.sql.Types#OTHER, then no test of the hibernate-orm project fails and my mapping via org.postgresql.util.PGobject to jsonb starts to work. I would have expected this or some other constant to be used instead of random hash code that can (theoretrically) clash with other predefined values.

Reproduced: Hibernate 5.2.6.Final and 5.2.7.Final, jdbc driver org.postgresql:postgresql:9.4.1212.jre7, PostgreSQL 9.5.5 via docker

A small demo is available at https://github.com/mgurov/pghibernatejsonb

Please let me know if I can provide more info on the matter

Using JSON via AttributeConverter is not very suitable. You should use Generic Types as explained in this article so you can better control the JDBC Type and also be able to map to a String or a Binary PostgreSQL JSON column type.

The goal of that hashCode specialCode is an attempt to guess the underlying JDBC Type when the javaClassToJdbcTypeCodeMap does not return a proper int code for the incoming String-based one.
That's why I said that using AttributeConverter for exotic types is not recommended.

@vlad, thank you very much for the explanation.

Sad that such a heavy-weight machinery is needed to utilize very useful database types like the jsonb of postgres, but I guess there is no easy way to simplify this in a way generic enough.

I should admit that I still do not see how exactly the use of Class.hashCode() helps with guessing the underlying JDBC type, but i leave this to your judgement whether this approach is reasonable or not.