[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-community] About Profiles
|
James,
I think you have missed something in the Servlet programming model. While its primarily used for HTTP requests its not bound to that model or even synchronous request/response messaging. Reactive Streams could work well within the Servlet model or form another programming model. If I’m wrong than Serlvets have changed more than I thought since I used them for pure TCP/IP processing back in 1998.
I’m an advocate of Reactive Streams as a new programming/processing/messaging model, but it would be premature to toss out HTTP processing and Servlets in order to embrace Reactive Streams as the “one true” model. Having been around for a long time I can tell you that today’s silver bullet often becomes tomorrows legacy nightmare. I’ve lived through that transition at least a dozen times. There is no “one true” model. There is only those options that most useful now.
I don’t believe that is the fate of Reactive Streams to become legacy, but at this point its not a widely adopted programming model and I think we need to serve the needs of the mass majority of developers who use HTTP and Servlets IN ADDITION TO introducing and supporting new methods like Reactive Streams.
I would not make Reactive Streams a required part of the Core at this point, but as Reza pointed out the Core can evolve over time just as well as any profile. If Reactive Streams is introduced as a Specification and wrapped into a Profile on top of the Core, it could remain very lightweight while providing a powerful programming model for those interested in that paradigm.
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
--