Why Another MVC Framework in Java EE 8?

Some of you may be aware that MVC 1.0 was launched as JSR 371. Targeted for Java EE 8 the goal of the JSR is to provide a standards based action-oriented web framework for Java EE. 'Why' and 'why now' are two perfectly reasonable questions to explore carefully with regards to this JSR. After all JSF has long been included in Java EE as a standards based MVC web framework. In addition although JSF is a component-oriented web framework there are myriad Java web frameworks that are action-oriented including ones that are very Java EE/CDI friendly such as VRaptor (indeed we had a session on VRaptor at JavaOne 2014).

There's little doubt the web framework space in Java has long been hyper-competitive. There are myriad camps each of which insist their way is the "right" way. Nonetheless in most reliable analysis two schools of thought have consistently come out on top for a number of years - component-oriented frameworks (led largely by JSF) and action-oriented frameworks (lately led by Spring MVC but long dominated by Struts). As a result it has been an open question whether Java EE should support both models much in the same way that .NET has done with ASP.NET and ASP.NET MVC. To put this question to rest we included it in the Java EE 8 survey. Despite all the factors above it turned out that the core Java EE community does in fact see the need to include a standard action-oriented web framework in Java EE, which brings us where we are with MVC 1.0. To answer some of the questions that should naturally arise none other than JSF specification lead Ed Burns put together a very nice analysis piece on OTN that's well worth a read. Red Hat's MVC 1.0 expert group representative Joshua Wilson has done the same as well.

It's obviously not  possible to construct an entirely unbiased pro/con analysis matrix for choosing between these two perhaps equally valid major approaches to Java server-side web frameworks. That being said I've tried to encapsulate some of the salient concerns in the graphic below.

I have years of real world development experience with both approaches in case you are wondering; I also favor JSF personally in case you were wondering but see both perspectives. In my view, component frameworks like JSF do extremely well in offering the closest approximation to Smalltalk's original MVC concept, reduce boilerplate to the bare minimum by almost entirely automating controllers/navigation/state handling/event dispatch and truly enable writing re-usable web components. These characteristics shine particularly bright with purpose-built component libraries like PrimeFaces that do a lot of the HTML, JavaScript, CSS heavy lifting for you. However because JSF is a higher level framework that cleverly abstracts away a lot of the underlying HTTP life-cycle there is an initial learning curve. In my view this leaning curve is fairly minimal with JSF 2+ and is only a serious problem with relatively inexperienced developers from a web-development heavy background and no desktop UI development experience.

Action-oriented frameworks try to accomplish far less in comparison. They provide a thinner MVC-like facade that leaves a lot of the work of writing controllers, HTTP handling, navigation, state maintenance, HTML/JavaScript/CSS authoring to the developer. There is really no concept of components beyond relatively elementary templating. As a result these frameworks do not generally have component or plug-in ecosystems. These characteristics make learning the framework easier for beginners that perhaps have a background in vanilla web development, PHP, JSP, ASP classic and the like. Because the framework does not alter the HTTP life-cycle or HTML rendering much it is easier to integrate arbitrary HTML, JavaScript and CSS tools.

To apply a very broad generalization the way I have seen this play out is that heavily form/workflow driven applications where Java developers do a lot of the UI work tends to be written in JSF. There are exceptions (such as eBay - they presented on their JSF usage at JavaOne 2014) but these applications usually reside behind corporate firewalls. More public facing web applications often dominated by web developers tend to be written using action-oriented frameworks.

I hope this helps answer some of the questions you may have had. JSF is here to stay and continues to have a strong community behind it. JSF 2.3 was launched as JSR 372 and is also targeted for Java EE 8. MVC 1.0 will join JSF as a first class peer in Java EE for folks that prefer an action-oriented web framework.

If either of these technologies strongly interest you and you have the time to spare, now is the time to apply to join the respective expert group. Note that you can always participate in a JSR without officially being part of the expert group by simply subscribing to the JSR user alias. Also remember that you can contribute on an even more lightweight format through Adopt-a-JSR.

Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company.