openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wiles <>
Subject JPA 2.1 Progress
Date Wed, 11 Oct 2017 08:32:20 GMT
Hi All

As you know Spring 5 requires JEE7 as a minimum requirement.

I am keen to upgrade to Spring 5 as I want to upgrade to Elastic search 5
and do do that we need Spring Data 2 for that and for that we need Spring 5.

Let me say that I can only recommend openjpa.

I say this because in my endeavours to upgrade to Spring 5 I switched to
using Hibernate and cursed hibernate because it required that every getter
had a corresponding setter (even if those methods had nothing to do with
persistence) unless the existing method is annotated with @Transient. This
rather ludicrous requirement disqualified hibernate in my eyes.

Then I tried to eclipselink and again my app did not start because the
Spring Data meta model generating failed. Something to do with having
Spring data repositories on composite keys (I have a lot of these) -
notwithstanding the fact that I had to build my own version of eclipselink
because I got a stackoverflow because I use an annotation that was
annotated with itself (and they support meta annotations).

What is interesting is that I used the 3.0.0-SNAPSHOT branch of Openjpa in
my code and was able to run some of my integration tests successfully on
Spring 5.

So given all the above, I am unwilling to migrate to hiberate or
eclipselink - this I do not want to do.

I'm sorry to ask such a blunt question: When will a JPA 2.1 compliant
version of openjpa be ready? I guess I would like some indication about
whether it will weeks, months or years?

In this regard, what can I do to help? I do not want to switch to hibernate
or eclipselink so I would be willing to help where I can... I'm not sure
I'd be able to do some of the more hard core stuff - although I do get up
close and personal with the low level code from time to time - but I could
help with testing and/or documentation... I do have a fairly robust
application which does use a lot of the jpa specification.

Thank you - and thanks again for what I think is the best JPA
implementation around.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message