Add Jakarta MVC to Jakarta EE Web Profile 10?

[ivargrimstad]

Creating this issue to track the decision of whether MVC should be added to the Web Profile.

[kwsutter]

How are we going to determine whether to add MVC to Web Profile? Do we have enough interest and usage of MVC in the Web Profile community to warrant this addition? Maybe we need some polling and/or data to support this inclusion? I can see some benefit of including it, but we don't want to bloat the Web Profile if it's not a desirable Specification. Similar to what we've done with MicroProfile -- we can let new specifications "bake" for a bit as Standalone Specifications before attempting to include it in a profile or platform.

[erdlet]

My view as Committer:
I really think we should add MVC to the WebProfile, as this enables developers to implement modern server side rendered applications very easy. Also we keep pace on other widely used frameworks like Spring, Rails, Grails, ... which provide MVC frontends per default.

Regarding the community, I think we should also think of people which aren't using Jakarta EE at the moment. I know a lot devs not thinking about using Jakarta EE for their applications, because they only know JSP and JSF as possible frontend technologies which they aren't willing to use. With an easy access to Jakarta MVC via the Web Profile and the possibility to use modern web development approaches by this, I'm sure we'll get more users (back) to Jakarta EE and provide some useful features to the existing community.

My personal view:
For my personal and employers applications I use MVC everytime I need a frontend, because I like to use the possibility to design my frontend APIs like I design e.g. JSON APIs. But also I find it a bit frustrating that I need to add the MVC implementations all the time, whereas all other APIs like JPA etc. are provided by the Platform. So having Jakarta MVC in the Platform would save me a lot of time and my applications would be easily portable again (which they aren't at the moment because I'm bound on the explicit implementation). So from this view I'd also really love it when Jakarta MVC would be part of the Web Profile.

[gtudan]

+1 @erdlet

Another perspective I would like to add: I totally see that the web-profile should be a lean and lightweight specification. From a developer perspective, adding MVC to it helps to achieve that. MVC is (compared to JSF) a tiny specification with just a handful of annotations on top of already existing ones.

Today, if you want to start developing a web app in Java WebProfile, your go-to solution is JSF. JSF is a huge spec with a concept that is quiet different from many of the frameworks out there (Rails, Spring...) and even the other popular specs in Jakarta (like JAX-RS). Adding MVC will lower the entry barriers especially for new developers coming to Jakarta, and thereby help the Webprofile live up to it's mission to be the lightweight version of Jakarta EE.

[pgutierrezn2]

+1

We've been watching the development of the MVC spec since it missed the opportunity to be part of javaEE and are willing ,since then, that it becomes an integral part of JakartaEE. I have two reasons to offer:

1. From a legacy perspective. I still see too many struts 1 (yes 1) out there, lots of them. Most are tiny applications that work without problems but that will have to be migrated soon. I consider that MVC might provide a candidate migration path for them.
2. From the point of view of newcomers to JakartaEE, I believe these people might find MVC as a light an easy way to start using it and have the opportunity to understand JakartaEE better.

[keilw]

I'd be a little more cautious about stuffing too much into the Web Profile.
At this point "optionality" if the term is even appreciated only applies to features or specs that are to be removed soon, but there is no choice or optionality when it comes to supporting all the specs that are in a profile.
So implementors of Jakarta EE Web Profile would need to fully implement all of:

• Servlets
• Server Pages
• Faces
• MVC
  Now, plus a few related ones like Standard Tag Libraries only among Web UI frameworks to be compatible.

Struts was mentioned, that is not even a Java/Jakarta EE spec by itself and never was. It is based at least on Servlets and most likely JSP at least optionally.
To stick only to the content of Web Profile, if a majority of users and providers or other platform participants feels, that both Pages and Faces are somewhat legacy and could become optional soon, then adding MVC while marking at least one or both as optional soon seems reasonable.
Given MVC can be used independently, also together with the Core Profile (for "Self Contained Systems") it is questionable, if making it a mandatory part of anything beside the Full Profile adds more value or burden to both implementors and maintainers of the platform, e.g. via TCKs, etc.

[ivargrimstad]

I'm kind of biased here since I have been involved in MVC from the beginning, but I will way in here nevertheless.

• MVC is filling a gap by providing action-based MVC to the platform
• With server-side rendering making its way back in the industry, providing a lightweight alternative such as MVC in Jakarta EE gives a competitive advantage.
• Core profile is not enough to run MVC on top of since it relies on several specifications that are not currently planned to be a part of Core Profile (e.g. Bean Validation, Server Pages, Expression Language). An MVC application would also typically use Security and Persistence, which both are part of Web Profile.

[ivargrimstad]

How are we going to determine whether to add MVC to Web Profile? Do we have enough interest and usage of MVC in the Web Profile community to warrant this addition? Maybe we need some polling and/or data to support this inclusion?

I suggest a simple poll to gather input from the wider community. I'll set that up.
Then it will be up to the Platform team to decide if it is added to the plan or not. If necessary, we can run a discussion and vote on the mailing list. The plan will have to be approved by the specification committee.

[starksm64]

My feeling is that this needs bake time as a released standalone spec to see vendor adoption. I have asked our Wildfly team to comment on whether they are ready to start supporting this as part of a web profile release.

[bstansberry]

I have not seen user demand for inclusion of MVC in WildFly, so adding a subsystem for it is not on our current roadmap. I've pinged the community for their interest in this; if there is we can look at it, perhaps initially as an extension feature pack hosted at https://github.com/wildfly-extras.

Server vendors are free to include MVC in their servers if there is demand from their users for it. If there is demand I expect multiple vendors would support it as a standalone spec and then there will be portability amongst those vendors. During that process the spec and impl will get bake and cross-vendor collaboration, and ideally there would be multiple impls. When that happens that seems like a better time to include the spec in a profile and thus require all vendors to support it.

[pnicolucci]

My personal view here is that I also have not seen a great demand for MVC. Adding the MVC specification to the WebProfile forces each vendor who implements WebProfile to either integrate the existing implementation into their runtime or create their own.

The amount of investment to include MVC into a runtime would need to be justified by user demand which I have not seen.

I have to agree with bstansberry when he says:

"During that process, the spec and impl will get bake and cross-vendor collaboration, and ideally there would be multiple impls. When that happens that seems like a better time to include the spec in a profile and thus require all vendors to support it."

[chkal]

I have not seen user demand for inclusion of MVC in WildFly, so adding a subsystem for it is not on our current roadmap. I've pinged the community for their interest in this; if there is we can look at it, perhaps initially as an extension feature pack hosted at https://github.com/wildfly-extras.

Some time ago @gtudan created a Jakarta MVC module for Wildfly (see here). It definitely needs to be updated, but it may be a good starting point for such an extension feature pack.

[bstansberry]

Thanks, @chkal (and @gtudan!)

[kwsutter]

Really appreciate the developer viewpoints provided by @erdlet, @gtudan, and @pgutierrezn2! Thank you.

The MVC team is already producing Specifications, APIs, and TCKs. And, at least one implementation exists with Krazo. So, if an application server decides to support Web Profile and MVC, doesn't that provide the environment that is desired? Or, are you indicating that MVC needs to be part of Web Profile to help promote it's use across application servers? Kind of like a "build it and they will come" mentality?

I appreciate the input from the Wildfly and Open Liberty teams. But, if we wait for customer demand, then are we too late and these prospective customers have already looked elsewhere for their solution? Just playing devil's advocate...

[starksm64]

The Krazo team has instructions for how to integrate the MVC implementation in various servers. This is going to have to be the mechanism by which MVC gets exposure. Vendors can only commit to supporting a technology when there is sufficient demand due to the long support cycles associated with the production releases.

[ivargrimstad]

Will not be included in Jakarta EE 10 as decided in the July 27 Platform Call and discussion in this issue.