Comments (15)
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.
Related Issues (20)
- Switch to using MetadataContributor or TypeContributor for contributing types HOT 1
- DateTime Column with @Version attribute HOT 3
- Persisting FastMoney in JPA truncates amount
- Migrate from Jadira 7.0.0.CR1 to Java 17 HOT 3
- Cannot resolve method 'withZone' in 'OffsetDateTime'
- weld-core-parent dependency reference invalid xml
- TimeColumnLocalTimeMapper incorrectly uses "getNano()" HOT 1
- Jadira Usertypes with Java 10 throws java.lang.ArrayIndexOutOfBoundsException on initialisation HOT 7
- Where are lastest versions of Jadira published? HOT 2
- Update Indriya version to 1.2
- Document which version of usertypes is compatible with which version of Hibernate HOT 3
- Incompatible handling of timezones in 7.0.0.CR1 HOT 1
- Hibernate 5.3.7 compatibility HOT 2
- Joda Money 1.0 removes deprecated methods that Jadira uses
- PersistentDateTime mishandles dates that fall in DST HOT 1
- AbstractHeuristicUserType tries to instantiate deprecated TypeResolver with wrong parameters HOT 1
- StringColumnDateTimeMapper throws an Exception when Joda Datetime contains zone offset in hours, not Zone ID
- Conversion from mysql decimal column to curreny YEN fails. HOT 2
- Problem between sql Date and joda LocalDate conversion
- Status of jadira ? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jadira.