[
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
|
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 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).
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.
Hi,
> 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.
Cheers,
Ollie
_______________________________________________
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