Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Optional parts of a Spec or a "Bridge"



I just wanted to register a Java / Jakarta EE user’s point of view on that comparison to Spring in terms of abstraction and APIs:


Does Spring ever try to be agnostic of itself, or does every Spring API depend on Spring Beans and whatever else it needs from Spring, without any shame?


I’d like to point out, as a current user of both Java EE and Spring, but someone who used Java EE for long before Spring, I felt that the API/implementation separation was a relative strength of Java EE’s.  It’s been a good thing for us that Java EE specs allow you to code against an API module that is mostly or all Java interfaces, forcing a conscious separation of implementation into other modules needed at runtime.  I’ve always struggled with Spring Framework’s organization as one big library that contains lots of concrete classes that make it unclear – how much is my application supposed to use and depend on and how much is internal Spring implementation detail that would be foolish to write code against?  However, I do think what Spring Framework has done a great job of, is making sure it’s a foundational project, where you’re able to use Spring Framework in an application without necessarily depending on tons of other libraries.  The Spring Framework modules do have a lot of cross-module dependencies.  But as a project, it at least can be used self-contained for the most part.





From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Arjan Tijms via jakartaee-platform-dev
Sent: Friday, September 1, 2023 9:11 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Optional parts of a Spec or a "Bridge"


**Warning! This email originated from outside the organization. Do not open attachments unless you recognize the sender. If you suspect this email is malicious, use the "Report Phish" button.
Replies to this email will go to jakartaee-platform-dev-bounces@xxxxxxxxxxx .**



I want to warn, again, about designing anything overly abstract. It always sounds so good and nice to be agnostic of everything, so that this proverbial guy deep in the jungle of japan can use our Java spec with Python and some Python based framework even.


But in practice this causes a lot of hurt, and makes things quite difficult to use.


Jakarta Security is, IMHO, infinitely easier to use since it just targets Servlet and CDI. Jakarta Authentication is according to many (it seems) horrible to use, precisely because it's agnostic to everything. It was designed to work with every possible representation of a request for instance, but in practice it has only ever been used with HttpServletRequest (okay, and SOAP, but it made little sense there).


We may want to compare this with the most popular framework out there; Spring. Does Spring ever try to be agnostic of itself, or does every Spring API depend on Spring Beans and whatever else it needs from Spring, without any shame?


Kind regards,

Arjan Tijms





On Fri, 1 Sept 2023 at 13:13, Werner Keil via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:


After Jakarta Data was just successfully accepted to the Full and Web Profile, it is equally important for users of the Core Profile who want to use repositories and other features with the database of their choice, either NoSQL or SQL/JDBC/JPA based.

However, there is desire by some in the Persistence camp, to force Jakarta Persistence as a mandatory dependency onto Jakarta Data, see


Which is where I also made this remark:

There are 3 options where these "implementations" or specializations could happen:

* In actual implementation modules, much like spring-data-jpa or micronaut-data-jpa do now
* In Jakarta Persistence as a downstream spec
* In a "Bridge" spec between Data and Persistence, a bit like the Portlet Faces Bridges defined by the JCP or the bridging efforts between Jakarta Security and Microprofile

A 4th option is currently not realistic, it would require optional sub-modules that depend on Jakarta Persistence/JPA etc. but Jakarta EE right now only knows "optional" for features to be phased out soon.

Although the Core Profile under 2.2. Optional Components already defined some specs that are optional for that profile, so the question is, would it be possible to do this on a detail spec level, or does such a spec need a "bridge" or another separate spec like "jakarta-data-persistence"?

Frameworks like Spring Data or Micronaut Data use JPA only in sub-modules that are more an implementation than spec/API, but of course they are no specs to begin with, so it is easier for them.

I believe, the adoption of Jakarta Data will suffer if JPA is forced down the throat of every Jakarta Data use case, whether it's NoSQL or other non-relational usage of the spec.

And let's not forget those who complained here earlier, that certifying for Data was too hard, what if they need to certify against Persistence as well, even if they don't use relational databases.

Take Apache Johnzon: which while still calling it "JavaEE 10" hopes to pass the TCKs of Jakarta JSON Processing and Binding. Another project could also decide to implement just JSON Processing, it is not forced to implement or support both.



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

Back to the top