| Re: [jakartaee-platform-dev] [DISCUSS] Include Jakarta Data in EE 11 |
I already replied regarding 1 which is the most compelling argument for a vendor neutral spec rather than a vendor-lock-in to a particular API or library that is not compatible even with other systems of the same type.
As for 2 and 3, there is a point, but there is still no clear decision or dominant solution between RxJava, Project Reactor and maybe a few others, which is why we decided to keep Reactive out of the Spec and up to implementors for now.
As for 4, this discussion is not about NoSQL. Jakarta Data is independent of JPA or NoSQL, similar to a small portion of Spring Data Core (which is not a "Spec" so API and implementations are combined, a part of why it isn't always easy for Spring to implement actual standards) or one or two modules of Micronaut Data (where the most basic elements like CrudRepository are generally better structured into smaller modules than Spring Data, so it might be much easier for it to implement a spec like Jakarta Data)
Jakarta NoSQL has indeed challenges like abstractions for different DB types and why users of a document-based system should have to bother with column-based or key-value databases and vice versa, but that is for a different thread and no concern of Jakarta Data.
_______________________________________________Regards,
Werner
On 13.07.2023 16:12, Romain Manni-Bucau via jakartaee-platform-dev wrote:
Hi,
From an user perspective it is not clear what the spec brings:
1. Abstracting NoSQL and vendor solution is rarely relevant since you will never plug something else behind (if you picked some NoSQL it is for specific features otherwise you go with SQL abstraction in most of the cases so abstraction is not a real thing). Spring had a very good momentum but our ecosystem changed a bit I think so it can be less relevant today.2. Java connection related API tends to move to functional style of API and these API are less annotation driven these days - until you have a legacy, in particular with the pop up of virtual thread where lambda helps to propagate a context without using thread local or scoped values, so the spec does not seem to fit well modern coding and already look legacy3. Api is designed to be blocking but virtual thread adoption is not yet a thing and most drivers are NIO friendly so will be a blocker for a lot of microservices4. Due to most NoSQL vendor driver stacks it is quite clear it is not desired to have it provided by default in the server (so runtime) due to security management so ideally NoSQL should more be designed as a lib like spring data is and be importable but not provided by default until vendors reimplement the drivers (while it can be easy for redis some as cassandra are more challenging to be done properly).
So while it can fit the "put it all" profile (full one and yes it means this profile is boilerplate but it was created for that so not a big deal IMHO) I don't think it should be shipped anytime soon with any other profile (in particular the web one which is already fat enough for end users).
Le jeu. 13 juil. 2023 à 15:54, Nathan Rauh via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :
_______________________________________________Oliver,
I hope the following comment that you posted is just a misunderstanding of what has actually gone into the spec vs. what was under discussion but not actually included,
> 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.
Regarding the instances you cited of exceeding what vendors currently do:
https://github.com/jakartaee/data/issues/109 - It’s true this would have been a major addition that exceeds what vendors do. It was discussed a lot. It was very contentious with a lot of disagreement over it. Consequently, it never went into the spec. This should not in any way be blocking Spring from implementing Jakarta Data because this proposal isn’t part of Jakarta Data.
https://github.com/jakartaee/data/issues/94 - This one confuses me because it’s just an extra annotation that does exactly the same thing that the OrderBy keyword already does, and I can’t see how something so trivial could cause trouble to Spring Data. Hopefully the real reason was the mistaken belief that 109 had gone into the spec, not this change. There was certainly disagreement on whether this annotation should be taken out of the spec that went on for some time, I thought we had ultimately resolved it on one of the Jakarta Data calls, which included both Graeme and Otavio (apparently no one from Spring must have been on that particular call). If this truly does somehow block Spring from implementing Jakarta Data, or if Spring just feels so strongly about it that you would forgo implementing Jakarta Data over it, then we’ll just take it out of the spec for you. Please follow up with me on that (either one this email chain or separately) and we’ll get it taken care of.
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev