Oh and one more thing, re. "3. Bugs and compatibility issues with other libraries. I have first-hand experience with it and it's not pleasant." I suspect that https://github.com/apache/fineract/pull/607 may help with (some of?) those kinds of problems? It was a mistake to initially, when Mifos X 0> Fineract switched from Hibernate to OpenJPA during the move to the ASF use the openjpa-all "shaded fat JAR" - but that's relatively easy to fix, with https://github.com/apache/fineract/pull/607.
On Wed, Jul 10, 2019 at 12:14 AM Michael Vorburger <[email protected]> wrote: > 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* >>>> >>>
