Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [DISCUSS] Include Jakarta Data in EE 11

Hibernate was also dominant in the Relational DB access, Persistence and OR-Mapping, yet JPA was established and Hibernate eventually implemented it.

Can't speak for DeltaSpike, because Apache does not specify things, it implemented several Jakarta Specs in the past, JSP (Tomcat) or JSON Processing, it even implemented JPA, but OpenJPA did not seem active after 2021 anymore, ironically missed the Jakarta EE train for some reason.

For many there is a sandbox, it's called MicroProfile. There were also ideas to get Data started there, but at least the whole evolution and journey of Jakarta Config (starting largely influenced by DeltaSpike, then via a brief intermezzo at Apache Tamaya went into MP Config, then JSR 382 before becoming Jakarta Config) made that seem more hindering than improving.

DeltaSpike is as dead as OpenJPA, the last update to its main entry page was 2021, most other pages even stopped changing in 2016, referring to Java SE and EE 6.

There are newer frameworks now like the mentioned Quarkus, Micronaut or Helidon.



On 13.07.2023 12:09, hantsy bai via jakartaee-platform-dev wrote:
As stated before, I hope Jakarta starts a sandbox project or so called Jakarta umbrella project(as a sister project of the spec projects) to hand over Jakarta Data, Apache DeltaSpike, etc to ease the Jakarta EE development.

* Personally I do not think the Repository pattern can be defined as spec, Spring Data, Micronaut Data, Quakrus has its own way to cook Repository, but it is good as a tooling project to extend existing Jakarta EE spec.
* A lot of Apache Deltaspike features are useful, but they are not updated,  local transaction, type safe config, type safe resource boudle(for Faces, Validator, etc.), message CDI event bridge ...



Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker




On Thu, Jul 13, 2023 at 5:27 PM Oliver Drotbohm via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Hi all,

> On 13. Jul 2023, at 05:09, Edward Burns via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
> Nathan Rauh wrote: … Over-generalized statements that the specification lacks maturity are not particularly helpful and are somewhat confusing given that the established products (Spring Data and Micronaut) are expected to become implementations of Jakarta Data. It would be much more helpful to know exactly what from Spring Data and Micronaut that the Jakarta Data spec hasn't already standardized that you would like to see included.

the expectation of Spring Data ending up implementing the standard is unfounded. we (the Spring Data team) and also Graeme of Micronaut have repeatedly expressed concerns [0, 1] regarding the spec going far beyond what's currently established introducing new features that have no basis in real-world user needs or are at least not validated in an implementation.

In other words: the problem we see is not the lack of features but the scope already exceeding what's been established in the industry. This would add more complexity to our projects with no apparent benefits. Given the current state of affairs there are no plans for Spring Data to implement the specification.


jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top