X

An Oracle blog about Java Technology

Why Another MVC Framework in Java EE 8?

Guest Author

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.

Join the discussion

Comments ( 6 )
  • Vince P. Tuesday, October 21, 2014

    The distinction between Component Oriented vs. Action Oriented frameworks is patently obvious now, but I've been of this mindset for some time and I'm starting to believe that developers long accustomed to one or the other will have problems switching between them; even if they stay in the same base language (e.g. C# or Java).

    The difference between them seems to be as immense as the difference between C and Java. Either you want to do everything yourself and maintain a very tight grip on control (action oriented framework) or you want the framework to provide reasonable defaults and let you concentrate on features (component oriented). I've also developed a bias around when each type of framework should be used: action-oriented frameworks for external sites that normally have leaner feature sets and component oriented for internal sites that have rich feature sets. I've helped applications using component oriented feature sets (primary ASP.NET, Ext.NET, SmartGWT, and some JSF) that would be a nightmare to create with an action oriented framework and I was involved with at least one *internal* application for which an action oriented framework was selected (JSP with boostrap). It was actually a nightmare for the developer team to get right. Conversely, I've seen many trivial internal sites propped up using technologies like Web Forms with all the features turned on, that every user in the company MUST use, and then they wonder why it's dog-slow.

    The main issue with these styles of frameworks isn't the technologies; it's the adherents to each. Communities of JSF/GWT/ASP.NET Web Forms developers will turn their noses up at the communities of jQuery/boostrap/MVC.NET/MVC developers as being "unproductive" and the MVC developers will turn around and call the others "wasteful".

    For my part, I just hope future application architects learn to use the right tool for the job. Just because you're most familiar with ASP.NET Web Forms (for example), doesn't mean it's the right tool for every job. You need to leave some space in your toolbox for MVC solution frameworks. Standardize on one API for each if you must, but have an open mind around when which would be most appropriate. There's never a good "always rule"; except this one.


  • Reza Rahman Tuesday, October 21, 2014

    Thanks for your excellent comments. May I take the liberty to suggest writing a blog entry on it to share your perspectives with a broader audience?


  • Andy Bailey Wednesday, October 22, 2014

    @Vince P.: an amen to common sense, my thoughts exactly. I have always been a proponent of "best tools for the job" and MVC 1.0 will provide an additional tool in the Java EE stack that will be a better fit for a lot of web apps than JSF is. In an ideal world there shouldn't be ideologues dominating discussions about which tech stack should be used to accomplish the goals. Now at least the ideologues can be appropriately marginalised where their influence can cause the more appropriate tech stack to be ditched to support their favourite "UI Paradigm".


  • Stefan Horochovec Wednesday, October 22, 2014

    Today I feel very comfortable in choosing to work in the Action Oriented model where the front-end development (aka, HTML / JS / CSS) has the actual control of the view layer, and Java concerning about security, and the back-end application.

    The world of HTML development is evolving in incredible way in recent years, with several specialized tools, even with professionals dedicating themselves only interface layer, which in my opinion, no longer a "simple" view layer.

    With the creation of the concept of WebComponents ( http://www.webcomponents.org/ ), the first time the Web environment will be able to have components in HTML as we have today in JSF for example, in a declarative way and included in the project through importing some dependence ( http://www.polymer-project.org/ ). What will greatly facilitate the development and enable the creation of projects like Primefaces for HTML Development, mentioned in the article.

    To our beloved Java, your responsibility becomes of all the back-end and integration with front-end via APIs (REST?). Honestly, it seems to me a very interesting environment to work :)


  • Vince P. Wednesday, October 22, 2014

    @Stefan H: Thank you for the observations on webcomponents.org and Polymer. The latter especially seems like a very nice framework.

    I did a little poking around in Polymer demo apps (e.g. https://www.polymer-project.org/apps/topeka/) and found what is essentially a component-oriented framework running client side. The only thing action oriented about using it would likely be the interface to the various servers that would probably front their services with various MVC style controllers.

    From my point of view, this is the preferred approach. I have a definite bias towards component-oriented frameworks myself because I tend to work mainly on internal applications and because they tend to reduce the complexity involved in delivering rich feature sets. I really hope this grows into a rich standards-based component ecosystem over time. Thanks again!


  • guest Sunday, October 26, 2014

    A big problem with JSF is it includes bunch of JS in the rendered page and this cannot be controlled by the developer.

    Again common use cases such as cross field validation are still a pain (But thanks to Omnifaces that helps JSF developers a lot).


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.