Hibernate 5.2 changes - AbstractUserTypeHibernateIntegrator no longer working about jadira HOT 15 CLOSED

I'm not connected with jadira team in any way, but I issued a pull request for changes that fixed it for us in one of our apps. I hope that helps. Let me know if there's anything missing.

from jadira.

The changes in Jadira to support Hibernate 5.2 are going to be pushed shortly. I haven't applied the PR (hub had problems merging it initially) but in the main they address the same concerns.

from jadira.

ping

from jadira.

FWIW we are looking to add Moneta support directly into Hibernate: https://hibernate.atlassian.net/browse/HHH-9674

from jadira.

@sebersole That's probably a better bet (Moneta api and having it directly in HIbernate 6) - although a bit far away.

from jadira.

We may decide to do it for 5.x. I just set it to 6.0 for now to not lose sight of it.

Also, development for 6.0 is already well underway.

from jadira.

This is probably the best place to ask...

In what JDK does the javax.money package get introduced? It was bumped from Java 8, and I have seen no specific mention of it in relation to Java 9. Until that time should we instead support org.javamoney.moneta?

from jadira.

It was scheduled for JDK9 but apparently that's not gonna happen:
http://www.mscharhag.com/java/java-jsr-354-money-and-currency-api
https://dzone.com/articles/looking-java-9-money-and

But it's two sides of the same thing javamoney implements the API (JSR) which will [hopefully] go into the JDK at some time - but the JSR lives happily outside the JDK for the time being.

from jadira.

Jadira has always aimed to support as a wide a range of Hibernate revisions as possible, but with 5.2 this will have to change. This is because 5.2 doesn't only introduce new methods, or types, or even change the return of methods - all of these things can be worked around - neither does it just alter datatypes that don't form part of the end user API that Jadira uses. Instead it introduces a new type and narrows its use on the UserType interface which is a core API the use of which we have to expose to the user. There's been lots of internal refactoring of Hibernate over the years, but the last time we faced this degree of change was I think in the transition from 3.6 to 4.x. Coupled with the API change, Hibernate has also moved to producing Java 8 binaries (class version 52)

from jadira.

After mulling over this, I've decided to drop support for versions of Java prior to 8 for Jadira as a whole. It is time to embrace Java 8 fully. The considerations that previously impacted such a move are less strong as a large majority of architectures are now moving away from the JavaEE model, giving more flexibility in choosing Java versions and over the dependency tree than users would have had in the past. The upshot of this is, Java prior to 8, and Hibernate prior to 5.2 will only be supported in the case of a branch or fork for maintenance of that old version. We'll look ahead and see if that is to be needed. Usertype-extended module is also no longer required, and the types in that module will now be found in Usertype-core.

from jadira.

Looking ahead, whilst we will aim to maintain compatibility will as broad a number of Hibernate releases as possible, it will no longer be prioritised to the same extent, and our focus will be on interoperability with new/current releases (essentially due to the factors enumerated previously). Looking ahead, I do hope the hibernate APIs will become less changeable once the key changes have been made, especially key public APIs such as its Type APIs.

from jadira.

@sebersole JSR 354 makes possible the creation of alternative implementations (e.g. for ME environments) but for ease of use consumers of the API tend to benefit from some visibility of the data types being worked with - for example, you can get a realise a MonetaryAmount object using Money.of() or more indirectly Monetary.getAmountFactory(foo).[configureit().]create() but the getAmountFactory is parameterized with the MonetaryAmountType you want to work with. Alternatively, you can ignore (to some extent) how MonetaryAmount is implemented using Monetary.getDefaultAmountFactory(). In the case that a number of implementations of JSR 354 emerge this latter approach is probably the way to go, but in practice only Moneta is 'out there', I would have supportted that as a baseline today. Indeed I can't imagine the SE JDK shipping the API without a reference implementation. In Jadira we use the Moneta value types factory methods directly (Money.of()), this seems the most natural way to work and I'll only change that when/if other Java SE implementations emerge. Were we to build in a more indirect implementation, I'd presumably need to allow overriding of which factory to be used via property either on the Session or on specific column mappings.

from jadira.

All this sounds very reasonable - I see the release got done - did you go into sonatype's repo and release it to central too?

from jadira.

Yes, that's synced to Maven Central now.

from jadira.

Thanks!

from jadira.