I think for a core profile even complete Servlet or CDI specs are an overkill. What is ths profile for? Should it contain really what 80% of developers use or it should rather cover 80% of their use cases? I think the
first, we already have Web Profile to do the second.
IMHO, if there should be a core profile, it should only contain relevant parts of Servlets and CDI.
For Servlets:
- ServletContext is valid and generous enough
- Security definitions are valid
- Session tracking is probably also valid
- On the other hand, Servlet, Filter and HTTP APIs are very cumbersome, and even a blocker for some technologies and approaches like reactive processing and NIO
For CDI:
- dependency injection and contexts are valid
- but things like events, stereotypes, decorators, portable extensions are not necessary and even very seldom used (even if crucial in certain usecases)
- new API for portable extensions introduced in CDI 2.0 could be in core but the old API is too much
To conclude, I would pick only necessary parts of some specs into a core profile otherwise there's no point in having it at all as it would already be too big to have a reasonable advantage over Web Profile.
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
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
Sent: 21 May 2018 16:15:33
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles
The Core should start out as small as possible providing APIs that are most commonly used as a foundation for most technology domains. Servlets serve this purpose well and should be included, but Servlets are more akin to infrastructure for component
models and processing than they are a component model in and of themselves. Yes you can program using the HTTP Servlet class (and even the more fundamental Servlet API) but in most cases their is a programming model (e.g. JSP, JSF, REST ) layered on top of
the Servlet infrastructure. It’s the fact that Servlets are foundational to many other programming models that they should be included.
My recommendation is to maintain the Servlet programming in the Core as well as the CDI model, because the CDI is so incredibly flexible and like the Servlet model provides a foundation for many other business components. So again, at a minimum,
the Core should consist of the following:
Servlet API
CDI
Interceptors
Annotations
Configuration
There are other technologies that might be considered such as JDBC which is the foundation of most JPA implementations and The Connector Archiecture, which provides a very pluggable interface for other types of systems, but the above list is
the bare minimum I would start with adding other technologies only as absolutely necessary.
This is indeed a valid argument. I would say I am OK with standardizing something like Netty or equivalent that is a level below Servlet. It may be a good idea to start that discussion with the Servlet EG. It's possible they might have an idea of how to
solve this. Maybe a Servlet Core can be evolved just like CDI now has a Core.
I am not too married to Servlet the API. My main point is to have something in the core that would be broadly (enough) accepted as core in the server side by the market. I think in the foreseeable future, that is something HTTP based (regardless of the
threading model, flow model, etc).
It is worth keeping in mind we have always had APIs that clearly belong mostly in Java EE but are not based on Servlet such as JPA or JMS (both ultimately likely TCP based). Again, it's not about raw technical merit but about market reality. To that end,
while I know what you are saying, perhaps it's a bit far fetched to think Servlet would become unimportant to Java developers soon. Before deciding that's the case I would certainly want to hear what the Servlet folks think. In general I have not been disappointed
in the decisions that the Servlet EG makes.
Lastly, of course the core profile itself can evolve as the market shifts (if it shifts). Even if we did start with Servlet, I think it's reasonable to add an alternative model to the core as needed and even deprecate Servlet if it becomes obvious that's
what should be done. Perhaps the one API to rule them all approach is also part of what we need to think differently about? Why not just acknowledge that while the core is minimal, that itself could be modular too.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 5/21/18 4:18 AM (GMT+01:00)
Subject: Re: [jakarta.ee-community] About Profiles
Are servlets really necessary in the core? Yes, they may have been central to Java EE for as long as Java EE has existed, but things are changing, systems can no longer be seen is a big static state store that can just be queried and updated with synchronous
communication, rather they are being build using streams, where the current state is in a constant state of converging, but never actually getting there, and communication is primarily asynchronous. Look at things like Kafka Streams and AWS Lambda and Azure
Event Grid - event based systems that are only concerned with asynchronous messaging are rising rapidly in popularity at the moment. And this isn't even that new, almost 10 years ago Heroku had both web dynos and worker dynos - worker dynos had no HTTP interface,
and you could argue that deploying something that started an HTTP server to a worker dyno was overkill. Now is a perfect opportunity to realign Jakarta EE with current industry trends.
And even for technologies that use synchronous communication, look at the rise of things like gRPC - this does use HTTP, but not on top of servlets. No one wants to deploy both a servlet HTTP server and a gRPC server, that's too heavyweight. Other things
like gRPC may well surface, do we want the servlet API to get in the way of people using these new technologies with Java EE?
As a counter point against requiring servlets, the MicroProfile messaging spec currently being developed will have no dependence on servlets, and I anticipate that there will be many use cases where you'll deploy services that use nothing but MicroProfile
messaging for communication, plus a database.
Perhaps as little as 2 years ago, I would have agreed, servlets are core. But I think there's a big shift at the moment, and a decision to make servlets core today could leave Jakarta EE behind.
You know I have a tremendous amount of respect for you, but as I suggested the truth is that none of this is about technical merit. Sometimes we really do need to just bow to where the market is driving us and not fight it. Once we have the technology
on firmer footing is the time to explain to the marker why we are right. That's not now.
The market demand from where I clearly have seen again and again is allowing people to start with Java EE with nothing more than Servlet and a la carte let them add whatever else on top. In addition there is a viable smaller market for one or two sensible
profiles. Right now people also want fat jars and hollow uber jars.
Giving people basically what we've been trying to push for years plus some ability to remove things or define things is yet another road to fighting another uphill battle that's honestly tiresome. The end result of where we are today should be telling
us loud and clear we need to be thinking about these things differently going forward.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 5/20/18 4:40 PM (GMT+01:00)
Subject: Re: [jakarta.ee-community] About Profiles
Hi,
_______________________________________________
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
--
James Roper
Senior Octonaut
_______________________________________________
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
--
|
