Hi Devs, *Glancing over > https://github.com/spring-projects/spring-framework/issues/20584 > <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?*
With Regards to support in Spring, I reached out to *Juergen Hoeller* and he confirmed that they do not intend to bring back OpenJPA support into Spring Framework itself or into Spring Boot. This is because *they expect OpenJPA to ship an OpenJpaVendorAdapter for Spring support *beyond standard JPA. Spring has now limited itself to providing out-of-the-box support for provider-specific features to Hibernate and EclipseLink. Moreover, this is the trend major projects are taking. eg: IBM's WebSphere Liberty and RedHat's WebSphere both dropped support for OpenJPA. Spring dropping support is "not entirely a big deal" but coupled with the minor issues sums up to something significant. In my opinion, with a number of projects focusing more on Hibernate and EclipseLink, the latter will become more mainstream hence both will benefit from the ripple effect of being part of the "mainstream libraries" (eg: more audience, more books/tutorials will cover both, better Stackoverflow and search engine results, familiarity with new developers in the long run etc). For example, Baeldung now has a tutorial (written in Nov 2018) explaining EclipseLink integration with Spring and a sample project on Github https://www.baeldung.com/spring-eclipselink. In contrast, OpenJPA and the others have none. Eventually, EclipseLink will gain the same stability and audience as Hibernate whiles the others lag I will share my experience on some of the issues I encountered when I started Migrating to OpenJPA. The initial issue was with the build time enhancement back in May ( details in this thread https://lists.apache.org/thread.html/88d61ac6f7aee55aeae85bd995b73c94fb0f8dc684fac027e30c814e@%3Cdev.fineract.apache.or g%3E), During my search for a solution on the OpenJPA dev list , Francesco, a PMC member at both OpenJPA and Apache Syncope, gave support and explained how they are using OpenJPA in the Syncope more on this here. https://lists.apache.org/thread.html/dc8be4a8bf62a4d044cea759395a0aa406e4e9cf52ac5d4cdd016bde@%3Cdev.openjpa.apache.org%3E . For some reason, Syncope uses H2 as the database during enhancement https://github.com/apache/syncope/blob/2_1_X/core/persistence-jpa/pom.xml#L143-L174 . The fact is OpenJPA is very efficient and works well when paired with H2 and so it makes sense for Syncope's to use it in their context. I don't know how things pan out when paired with other databases in production. EclipseLink, on the other hand, outperforms OpenJPA and even Hibernate when paired with PostgreSQL with no know issues unlike OpenJPA-PostgreSQL ( http://www.jpab.org/OpenJPA/PostgreSQL/server.html). Even better, we have some level of guarantee that we will get a similar JPA performance in both development and production. Hence, my affinity with EclipseLink Again, compatibility issues only occurred with OpenJPA 2.4 (all issues get resolved when working with v3.1.0 when I tried it). The issue I noticed involved the annotation processor and SLF4J shipped with openjpa. Whenever I integrated v2.4 into spring boot 1.4 and Spring 4.3, SLF4J in OpenJPA interfered with its counterpart in the microservices - introducing a Marker parameter in certain statements. Excluding the logger from OpenJPA affected the Logging channels in OpenJPA) and vice versa. This made it difficult to debug eventually resulting in a lot of commented out log statements as a workaround. Sticking with OpenJPA 2.4 will require a proper solution. Another problem is that Syncope uses a maven plugin which simplifies their enhancement process. During my test with OpenJPA 3.1.0, I had to provide a third party plugin to perform entity class enhancements I started with this https://github.com/schmutterer/gradle-openjpa. However, this introduced an interesting behaviour where entities will be picked up in certain builds but return null another time. Full disclosure, I didn't put a lot of effort in finding the cause or a possible solution given that I had already started testing out EclipseLink as at that time. During these tests, it was difficult to debug and trust in the results given that I was combining libraries which haven't undergone integration tests. The last thing we want is a JPA Layer which plays hide and seek during production. In another attempt, I temporarily upgraded the Gradle version to try https://github.com/radcortez/openjpa-gradle-plugin but dropped it given that we would have to upgrade Fineract CN's Gradle version just to use this. Talking from experience, we can make OpenJPA work in Fineract CN but is it worth the effort and possible risks ( http://www.jpab.org/OpenJPA/PostgreSQL/server.html couldn't find out if these issues have been resolved). However, given that its counterpart is already enjoying out-of-box support plus better efficiency on top of that... looks like a good option. I already have a working configuration with EclipseLink here https://github.com/ebenezergraham/fineract-cn-postgresql/blob/FINCN-2/src/main/java/org/apache/fineract/cn/postgresql/config/EclipseLinkJpaConfiguration.java https://github.com/ebenezergraham/fineract-cn-postgresql/blob/FINCN-2/build.gradle and currently wrapping up work on the Minimal Services. More on this in another thread. *FYI I recently looked into this kind of topic > in https://issues.apache.org/jira/browse/LEGAL-462 > <https://issues.apache.org/jira/browse/LEGAL-462>, which you may find > interesting to glance at in this context. There are, numerous, similar > other JIRA issues if you search for "LGPL" > on https://issues.apache.org/jira <https://issues.apache.org/jira>.* I just looked at the discussions around whitelisting LGPL. It looks interesting but it has been around for almost a decade now, Aside from the back and forth on this topic, I doubt it will be resolved anytime soon given the number of times issues raised on this topic has petered. All the same, we can't wait for this we need a compliant ORM ASAP Cheer On Wed, 10 Jul 2019 at 02:14, 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 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 >
