I never said we'd only allow "just" the JDBC type code for specifying the SqlTypeDescriptor. However, that being said... at the end of the day the JDBC type is an unbounded int value - yes java.sql.Types defines some standard values but JDBC does not restrict the type code to just those defined on java.sql.Types. So, all that said, even limiting this to "just" the JDBC type code would still work because the user would use a unique custom code.

Keep in mind there are 2 aspects to this:

1. the keyed (by JDBC type code) entry in SqlTypeDescriptorRegistry
2. the indication on an attribute, etc as to which SqlTypeDescriptor should be used.

That said, a lot of effort has been put into finding more ways to deduce the SqlTypeDescriptor (and JavaTypeDescriptor) in any given BasicType scenario. E.g. I now am looking at AttributeConverter (based on its type param sig) and javax.persistence.TemporalType to help resolve these.

Not to mention if I have one or the other, I have also put in place a nice resolution to the other based on JDBC recommendations (java.lang.String implies VARCHAR, VARCHAR implies java.lang.String, etc). I really liked the way this piece turned out, and the beauty of it is that it is actually part of the SqlTypeDescriptor and JavaTypeDescriptor contracts themselves. So, e.g., if I have a JavaTypeDescriptor I can ask it JavaTypeDescriptor#getJdbcRecommendedSqlType; if I have a SqlTypeDescriptor, I can ask it SqlTypeDescriptor#getJdbcRecommendedJavaTypeMapping. This allows it to fit in nicely with extended type descriptors.

Plus I'd expected to still allow users to specify an actual BasicType to use.

I may keep UserType around. This is something we were going to discuss later in the process. That all depends on how BasicType ends up looking after the refactor. But keep in mind here as well 2 things:

1. There is a main reason that Types are being redesigned (namely position based reads) which requires changes to UserType as well if we keep it, meaning there is no case of "oh my pre-6.0 UserType can just work". There will have to be some change to these custom types regardless.
2. IMHO the redesign to BasicType makes composing a BasicType from the pieces much easier than even writing a custom BasicType/UserType.