I don't think that setting a hard baseline solves any problem. The real problem is lack of integration among APIs and often reinventing the wheel and duplication.
MicroProfile adopted CDI-first approach (different from CDI-only). It doesn't mean that the API is only usable in a CDI container. It means that any new functionality should be covered by a CDI-friendly API first
and then a Java SE API is added as an alternative to match most or all features of the CDI-friendly API. CDI is completely optional but without it some functionality may not be covered with plain Java SE API and not the other way around as it's now in Java
EE.
I believe this is the way to go for Jakarta EE. If we define a baseline (CDI, Servlets, anything), it shouldn't be treated as a mandatory dependency. Rather, as a set of APIs that other specs integrate best with. Plain
Java SE should be supported but not in the first place. Spring does the same thing, focusing on DI but supporting plain Java SE where it makes sense.
Another issue is that specs often used to define a cross-concern functionality (e.g. CDI, validation, security) when there wasn't a spec that already covered it. This is for reasons how JCP worked. Within Eclipse and
Jakarta EE I hope there will be much smaller barrier to create new specs and also to split big specs like Servlets, CDI, EJB into smaller ones.
In short, we should: modularize existing specs, improve how they integrate when used together and deprecate duplicate functionality. Only after that we should make them work with plain Java SE and integrate with
Spring and other frameworks.
Cheers,
Ondrej Mihályi
Senior Payara Service Engineer
Payara Server – Robust. Reliable. Supported.
E:
ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
----------------------------------------------------------------------------------------------------------------------
Payara Services Limited, Registered office:
Unit
11, Malvern Hills Science Park,
Geraldine Road,
Malvern,
WR14 3SZ
Registered in England and Wales: 09998946 |
www.payara.fish |
info@xxxxxxxxxxx | @Payara_Fish
I honestly don't want to drag this on too much and prefer other people chime in with what they think.
Imagine for a moment that someone wants to use Java EE MVC with Spring or Guice for DI, etc. That would be a lot easier if you can just do the bootstrap through a Servlet Filter or Listener - that's what Spring, Guice, etc mostly rely on to do Java EE bootstrap/integration.
Now you'll need to do that some other way - probably CDI/JAX-RS. You can basically make the same argument for any Java EE API that mostly runs in a web environment. That's why it's best to just treat Java SE and Servlet as the baseline the best you can and
try to stick to AtInject the best you can.
Of course none of this is black and white. It is though a matter of accepting a practical reality that in order for Jakarta EE to go anywhere now we have to acknowledge that we are basically second-class citizens "in our own ecosystem". In a parallel reality
where we do not have the tragic history that Java EE does, maybe we would have the luxury to behave otherwise. Will it really do us favors if we live in that parallel reality? Or is it better if we hedge our bets, make sure we retain some mind share in an
ecosystem we no longer control and still serve a narrower but slowly growing population that does have real loyalty to the platform as opposed to merely utilizing parts they think they can't do without?
It's not easy, but that's the challenge if we are to really make it. It has been for a dozen+ years now. Our altruism is no accident I believe. There is a good chance we would have ceased to exist otherwise.
On 5/3/2018 3:48 PM, Werner Keil wrote:
Not sure if Spring MVC relies on Servlet, it probably does, but the "Jakarta EE" MVC standard does not, so a pure RESTful Microservice or Self-Contained System (which also may include a Web UI) can do with CDI, JAX-RS, JSON(P/B) and where the
UI is required something like "Ozark" (or whatever it shall be called under Eclipse) MVC.
I can't see a mandatory Servlet requirement in the MVC RI, so why force it onto a profile if that may not use it?
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community