Folks, I'm not entirely convinced yet that we have strong enough reasons to justify the effort switching from OpenJPA to e.g. EclipseLink.
Glancing over https://github.com/spring-projects/spring-framework/issues/20584, I'm unclear if it concludes that Spring Framework actually formally completely dropped support for OpenJPA, or if with OpenJPA 3.0.0 they refrained? There's also a discussion about "Spring core" vs "shipping OpenJpaVendorAdapter with OpenJPA 3.0 itself", and https://github.com/spring-projects/spring-framework/issues/18997 says, quote: "OpenJPA 3.0 should work fine with standard JPA 2.1 integration in Spring, i.e. simply without a JpaVendorAdapter, just like DataNucleus does as well (which we never shipped an adapter for). If anything does not work out of the box there, please raise it in a separate ticket; we'll sort it out ASAP." and "Everything seems to work," Has someone actually tested and hit any specific real problems with OpenJPA and current Spring versions? FYI via https://github.com/apache/fineract/pull/608 I seem to be able to run OpenJPA even on Java 11 (ASM upgraded). Best, M. PS: Just for "full disclosure" - I was one of the very first users of OpenJPA back when it was SolarMetric Kodo JDO - anyone here old enough to remember those days? ;-) Many moons ago I contributed https://openjpa.apache.org/openjpaeclipseenhancementbuilder.html. Also FYI http://www.vorburger.ch/corejdo/ or http://blog1.vorburger.ch/2008/08/testing-openjpa-sql-statements-using.html - oh the good ol' days. On Tue, Jul 9, 2019 at 12:24 PM Marta Jankovics <[email protected]> wrote: > Hi All, > > I have experience with Hibernate, EclipseLink and OpenJPA. Hibernate is > not an option, as you wrote in the chain below, although it is the default > JPA implementation. > > Comparing EclipseLink and OpenJPA I vote for EclipseLink because of its > better performance, transaction handling and no computability issues. > > I read some articles now about DataNucleus and as a conclusion I would > exclude it: > > https://s3-eu-west-1.amazonaws.com/presentations2012/50_presentation.pdf > (2012)) > > > https://www.researchgate.net/publication/313263324_Review_on_ORM_based_JPA_implementations > (2016) > > > https://pdfs.semanticscholar.org/5db6/f9d267a361debc5ddf7daf61cce82d7cdd5d.pdf > (2017) > > "Very smart policies for collections." > > "However, in terms of performance prospect DataNucleus is a dominant JPA > implementation but due to the *high complexity* and *lack of audience*, > it is *not a preferred API*. Another notable problem with DataNucleus was > the *lack** of* proper *documentation* support." > > "With DataNucleus JPA we observed a significant, and unexpected, *degradation > of performance* and outofmemory exceptions, particularly with heavy > workloads. > *Memory leaks* with DataNucleusJPA" > > Thanks, > > Márti > On 2019. 07. 05. 18:10, Ed Cable wrote: > > [To: Marta] Are you able to add your thoughts on this discussion? > > Ed > > On Mon, Jul 1, 2019 at 8:48 AM Awasum Yannick <[email protected]> wrote: > Hi Graham, > > +1 EclipseLink as its supported by spring 4.x and latest spring versions > and compatible with Apache license. Our upgrade to Spring 5.x or 6.x will > be easier. > > We dont want to build and maintain our own integration of OpenJPA with > Spring 5 or 6 in the future. > > On Mon, Jul 1, 2019 at 7:40 AM Juhan Aasaru <[email protected]> wrote: > >> Hi! >> >> Good job starting the discussion. >> Based on your arguments I also see EclipseLink as the best solution. >> I also found one more argument for using EclipseLink - it supports >> multi-tenancy: >> >> https://www.eclipse.org/eclipselink/documentation/2.7/solutions/multitenancy.htm#CHDBJCJA >> >> Juhan >> >> Kontakt Ebenezer Graham (<[email protected]>) kirjutas >> kuupäeval E, 1. juuli 2019 kell 07:09: >> >>> Hello Devs, >>> >>> I have started this thread to discuss the JPA implementation to adopt as >>> we work towards making Fineract CN Apache compliant as well as to ensure >>> that we are all aligned as a community. >>> >>> I am currently working on the migration to OpenJPA as my GSoC project. >>> However, a number of red flags as well and requests from other community >>> members has made it critical to start this thread. >>> >>> As most of you know, we can't use Hibernate as it's not compliant >>> therefore, it's essential that we migrate to an equally good ORM. >>> >>> *Our options:* >>> 1. EclipseLink - EPL 1.0 & BSD >>> 2. OpenJPA - Apache 2.0 >>> 3. DataNucleus - Apache 2.0 >>> >>> Not recommended >>> 4. iBatic - Apache 2.0 (still functional but retired >>> https://ibatis.apache.org/) >>> 5. TopLink - CDDL (category B license, and simply extend EclipseLink) >>> >>> I used the following criteria in the following order of priority. >>> 1. License >>> 2. Implementation's performance with respect to PostgreSQL >>> 3. Support in Spring as well as ORM Documentation >>> 4. Project Maturity >>> >>> Right off the bat, I suggest the adoption of EclipseLink >>> <https://wiki.eclipse.org/EclipseLink> based on new insights >>> discovered, re-evaluation of our options, and compatibility issues >>> discovered whiles migrating to OpenJPA. >>> >>> *Why EclipseLink? * >>> According to JPA Performance benchmark - >>> http://www.jpab.org/All/All/All.html EclipseLink is the Most Efficient >>> ORM (amongst our valid options) when persisting to PostgreSQL and even >>> outperforming Hibernate. >>> >>> Performance Summary (with respect to Postgres) >>> EclipseLink - 10.5 >>> Hibernate - 9.1 >>> OpenJPA - 6.5 >>> DataNucleus - 6.0 >>> >>> *Issues with OpenJPA.* >>> 1. Spring dropped support back in 2017 and requests to resume support >>> was declined earlier this year >>> https://github.com/spring-projects/spring-framework/issues/20584. There >>> is no guarantee when it will be back in newer versions of Spring. Spring 5 >>> for instance no longer includes the OpenJpaVendorAdaptor. Therefore, future >>> upgrade of Fineract CN will become an issue. >>> >>> 2. OpenJPA has been lagging behind - the stable version for spring >>> supports up to JDK 1.6 (although v3.0.0+ is working to resolve this issue). >>> >>> 3. Bugs and compatibility issues with other libraries. I have first-hand >>> experience with it and it's not pleasant. >>> >>> *Why not DataNucleus?* >>> It is not supported in Spring 4.x and its implementation will require us >>> to completely heavily refactor the JPA Layer in Fineract CN on top of that, >>> it's the slowest. >>> >>> Looking forward to your recommendations and your own evaluations. >>> -- >>> >>> *Regards* >>> >>
