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

Le jeu. 13 juil. 2023 à 19:10, Werner Keil via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :

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.

Not really, you miss the key there: you will almost never bypass the vendor anyway - out of my head only redis is a case you can do it but pretty sure most of the spec impl wil lrely on the 2 main pools out there.
So you are *not* vendor neutral there so question is does the API brings something valued enough or not and there it means you let the vendor features surface in the API which breaks the portability and abstraction point so IMHO abstracting too much NoSQL is a lost track from start.

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.

CompletionStage is a good start for a lot of the API and Flow.* is sufficient for the rest to interact with all of them today, including a streaming to HttpClient - but you can say EE does not integrate with Java but with JAXRS as a counter point probably.

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)

Well you are independent of SQL and NoSQL not sure what you are but still, what do you bring to the industry, which case do you ease or enable?
Dont know if you recall but I was reall for Deltaspike data creation and pushed a lot for advanced features but out of the architect role you realize it is often overkill and slows down more than it helps in real life so, at a moment where becoming lighter is finally a thing it can be good for jakarta to think less rather than cumulating stacks as before which exploded with Java 6 and led to the creation of profiles which is not a so great thing for end users because there is no more platform at a thing but several things so using hypothesis in a lib or a shared code in the company is harder.

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.

Yes but it is where data fails, you want to abstract anything with a single API? It already failed several times for the mentionned reasons and as you can see it already leads to defining a new QL language to be portable which is almost impossible accross backends - take the samples of the spec and run them accross all targeted backend, just fails.
It is a major pitfall of JPA and one of the reasons it makes it fat - you can even check in OpenJPA which is the lightest impl IIRC, so not sure Jakarta should do it again.
So overall data is persistence aware - and not agnostic as its goals part states so from a design perspective it failed. Even the pagination part, it is not usable with some backend (several KV for ex).

So maybe let's see if there is an adoption and it actually brings anything and let it be used as a lib - like microprofile - and rediscuss the inclusion in some time, but as of today it has too much cons and people against to be a sane choice for the platform IMHO.



On 13.07.2023 16:12, Romain Manni-Bucau via jakartaee-platform-dev wrote:

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 legacy
3. 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 microservices
4. 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).

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book

Le jeu. 13 juil. 2023 à 15:54, Nathan Rauh via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :


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:  - 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.  - 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.



From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Oliver Drotbohm via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Date: Thursday, July 13, 2023 at 8:40 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Oliver Drotbohm <odrotbohm@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] [DISCUSS] Include Jakarta Data in EE 11


> On 13. Jul 2023, at 13:47, Werner Keil via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
> You keep speaking "for Micronaut" and Graeme, …

I don't. I was referring to tickets in which he expressed the same concerns as we did (links included in the original message). That certainly doesn't mean the Micronaut team can't come to a different conclusion.

I am not even arguing technical direction (anymore). All I was trying to do is clarify on the assumption that Spring Data would plan to implement the specification. And I thought I'd share a few details why that is.

> Why don't you try the same?

What exactly? Take part in the discussion? That's what we do / did, as is apparent from the tickets I linked.


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

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