The first candidate build of Jadira Usertype 3.0.0 is now being synchronised to Maven Central. This is quite a big release and represents a large number of significant enhancements for the library.
Change of Naming for Maven Archives
The most immediately visible change is in the names of the Maven archives. Users of 'usertype.jodatime' should now change their dependency to:
Similarly the name of the 'jsr310' archive has changed to 'usertype.extended'. Usertype core contains most usertype functionaliy, whilst extended only contains library code that has dependencies that do not exist in Maven Central. Most users will want to use 'usertype.core'. Today you only need to use 'usertype.extended' if you want to use the JSR 310 usertype mappings. The reason for these changes is to accommodate new features within the usertype library.
Support for Joda Money
The most significant new feature is the inclusion of mappings for Joda Money. This library is a precursor for the eventual implementation of JSR 354, so Joda Money users will benefit from a future migration path as they adopt the JSR, just as Joda Time users can fairly readily switch usertype implementations as they adopt JSR 310. The mappings include mappings for both Money and BigMoney types, and support mapping to decimal or integer columns (for integer columns either the major amount (e.g. Dollars) or minor amount (e.g. cents) can be mapped. Single-column mappings allow a currency to be set either for the particular column (using the 'currencyCode' parameter on the column mapping) or SessionFactory wide (using the JPA or Hibernate property 'jadira.usertype.currencyCode'), whilst multicolumn mappings map the amount and currency each to their own columns.
Updates to Joda Time Support
Joda Time support has been upgraded to 2.0 release of the library. With the upgrade support for two new Joda Time datatypes - MonthDay and YearMonth has been added.
Globalised Configuration Options
The Joda Time and JSR 310 mapping have seen the introduction of system wide configuration options. This is particularly useful because you can set the database timezone and JVM default timezone once using a hibernate or JPA property. The two properties that can be used are 'jadira.usertype.javaZone' and 'jadira.usertype.databaseZone'.
A fourth supported property is 'jadira.usertype.seed'. This can be used to indicate which default implementation of Seed will be used for that SessionFactory.
Autoregistration of User Types in Hibernate 4
A final key new feature is the autoregistration of type mappings in Hibernate 4. This feature (which is not enabled by default) coupled with the use of globalised configuration, will allow you to avoid explicitly including type mappings for many of the commonly supported types.
The types that are autoregistered are:
To enable this feature, you need to set the JPA or Hibernate property 'jadira.usertype.autoRegisterUserTypes' to 'true'.
Upgrading from Usertype 2.0 should be relatively straightforward - as most new features are not enabled until the relevant property is set. Remember that Usertype 2.0 and later only support Hibernate 4 and onwards.
I am looking at a number of future areas for new functionality in Jadira Usertype. These include the previously mentioned addition of support for JAXB Bindings for the existing mapped types. Further planned changes include a refactor of the support for the JDK Date and Calendar classes and the development of some new domain types - and associated mappings - for types for which no standardised types currently exists. At the top of the list of these types just now are PhoneNumber (which will probably make use of Google's excellent libphonenumber) and Address.
You can find more information on the Usertype project at the project website.