Why? Why not JSF? Why another MVC framework?
The Java community was polled about what new features they wanted to see in Java EE 8. While 61% of respondents answered "Yes" to the question as to whether we should provide MVC support alongside JSF, only 26% felt that they could identify an existing technology here. Most requesters want a formal Java MVC API that can compare to Spring MVC. The third phase of the poll looked at all the technologies that received 60% or more votes. In that poll there were 13 areas and the MVC JSR ranked 5th.
This JSR is in no way meant to take anything away from JSF. (In fact in the new JSF proposal they are planning on supporting the MVC JSR.) It is instead intended to provide an alternative implementation to the MVC pattern. JSF is a component based MVC framework, while this JSR is a request (action) based MVC framework. The main difference is that JSF allows very little fine-grained control over the generated HTML/CSS/JS, whereas this JSR will provide that detailed control. Both framework styles have their place and value but one is not the other.
The MVC JSR proposal was just announced on the JAX-RS mailing list and will be led by Santiago Pericas-Geertsen and Manfred Riem from Oracle.
I have been thinking about MVC for a while now. I had actually considered submitting my own proposal until I found out that Oracle already had one in the works. After comparing notes with Santiago and Manfred, we realized we could work together on it. One of the biggest reasons that I wanted to work on the MVC spec is that I have spent years working with Spring and Spring MVC. In fact, my current role at Red Hat is the Spring lead for JBoss. I make sure that Spring works on JBoss/WildFly. Additionally I have worked with server-side frameworks like Struts and VRaptor and client-side frameworks like Backbone.js and Angular.js. That is why it felt like a perfect fit for me.
What is MVC, if you are still wondering? For those of you that are unfamiliar with this design pattern, here is a bit of an overview and some insight into what I hope we build.
The Model View Controller (MVC) design consists of three kinds of objects. The Model is the application or data object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before the use of the MVC pattern, user interface designs tended to lump these objects together. For example, JSPs sometimes merge database code, page design code, and control flow code. In practice, we find that unless these concerns are separated, larger applications become difficult to maintain. MVC decouples these concerns to increase flexibility and reuse.
Frequently application developers implement the MVC pattern in applications themselves which is expensive and error prone. This specification aims to help developers create web applications that utilize the MVC architecture without reinventing the wheel. This shortens the development time of applications using the MVC pattern.
The decoupling of the View and the Model is done by establishing a notify protocol. A View must ensure that its appearance reflects the state of the Model. Whenever the Model’s data changes, the Model notifies Views that depend on it. In response, each View gets an opportunity to update itself. This approach lets multiple Views be attached to a Model to provide different presentations. New Views for a Model can be created without rewriting it.
Depending on context, users want to see the same basic Model information in different ways. Separating out the View from the Model and the Controller allows the development of multiple Views from the same Model. Most noticeably this could be providing the same Model to a rich client, a Web browser, a remote API, and a command-line interface. Even within a single Web interface you might have different customer pages at different points in an application.
After working with both server-side and client-side MVC frameworks; I have a simple goal. Make MVC easy to adopt and powerful enough to use. Many frameworks are cumbersome to learn, while others are too light weight to be of any real value. I am aiming at striking a balance between those two.
Additionally, I will be able to make sure the MVC API is implemented on Red Hat JBoss (WildFly) in a timely fashion.