Stop adding web UI frameworks like JSR-371 to the Java EE spec
Java EE's Servlet and JSP API provide a fine foundation for handling a web-based request-response cycle. Adding UI frameworks like JSR-371 to the spec only causes problems.
Somebody really needs to shake the good members of the Java Community Process and get them to stop including web UI frameworks as part of the Java EE specification.
This is nothing against JavaServer Faces (JSF), or the soon-to-be-added Model-View-Controller (MVC) framework, JSR-371. (MVC becomes part of the standard when Java EE 8 is released.) As far as component-based or action-based web frameworks go, these two APIs are pretty amazing. But as amazing as they are, they shouldn't be part of Java EE spec.
Java EE has always provided a foundation for creating web-based applications. From Day One, the Servlet and JSP API have been there for those looking to develop web-based applications. On Day Two (Java 2 Platform, Enterprise Edition, or J2EE, 1.3 release), they added JSP Standard Tag Library, and on Day Three (Java EE 6), the expression language API brought JSP syntax in line with many competing web development architectures. Together, these APIs created a solid foundation upon which various web development frameworks could be built. From Vaadin to Spring MVC, many powerful Java-based web UI frameworks were developed leveraging these Java EE standards.
Web UI frameworks vs. lightweight APIs
But for some strange reason, back in 2003, JSF was made part of J2EE 1.4. While every other element of the specification was primarily an API, owing to the fact that it is was more of a full-fledged framework as opposed to being a simple API, JSF has always been an outlier. The distinction between a simple API and a full-fledged framework is a difficult one to fully articulate, but most Java aficionados will acquiesce to the fact that JSF has always felt distinctively different than any of the other JSRs the Java Community Process makes part of Java EE.
Why should web UI frameworks not be included as part of the Java EE specification? Quite simply, because they don't need to be.
Moreover, organizations should be allowed to pick their web UI framework of choice, and not have that choice subtly dictated to them by JCP members. The UI technology an organization chooses to build their applications with is a highly individual decision. I have never in my life heard an organization question whether they wanted to use their application server's Java Transaction API implementation for managing transactions. On the other hand, more organizations choose not to use JSF than organizations that do. JSF is not a necessity like the Servlet and JSP API are, nor is it fundamental to the functioning of a middle-tier application server in the same way all of the other Java EE APIs are. Why should web UI frameworks not be included as part of the Java EE specification? Quite simply, because they don't need to be.
But beyond the fact that web UI frameworks don't need to be part of the Java EE spec is the frustrating reality that they actually cause unnecessary problems when included.
Promoting outdated web UI software
There is typically a two- or three-year gap between Java EE releases. You can add an additional year or two onto that before application servers supporting the latest Java EE specification become widely available in a production setting. So, for many organizations, there can easily be a three- or four-year gap between the JSF library that is packaged in the lib directory of their recently upgraded application server and the latest, most up-to-date JavaServer Faces release.
This discrepancy between the old version packaged with the application server and the latest version available on today's market creates a serious problem, because the UI is the part of the application that end users actually see, and software developers want to be able to use the best technology available when developing front ends. Updating to the latest version of JSF, for example, often means replacing various JAR files that are packaged with the application server, editing low level configuration files, and worrying that, because you've messed around with the default configuration, you have somehow voided the support contracts on the software for which your company has doled out millions of dollars.
There are also ClassLoaders that need to be reconfigured, and every Java developer knows that messing around with an application's ClassLoaders has the potential to cause unpredictable problems at any time in the development process. It sounds completely counterintuitive, but the fact is packaging the web UI framework JSF as part of a Java EE compliant application server has actually made it harder for software developers to use their JSF version of choice.
Using a modern JSF framework means configuring shared libraries and custom ClassLoaders on the application server.
Java EE hindering JSF adoption
I'd actually postulate that packaging a very basic JSF implementation as part of the Java EE specification has stifled the growth of the best part of the JSF ecosystem, namely the various UI projects that have been built on top of JavaServer Faces.
Using JSF as it is bundled as part of Java EE is nuts. The framework itself provides a great foundation for doing web development, but that's all it is: a foundation. If you're not using a component-based web UI framework that builds on top of JSF -- such as ICEfaces, OmniFaces, PrimeFaces, RichFaces or ZK -- then you're genuinely wasting your time. Unfortunately, far too often, the decision-makers don't understand the relationship between the skeleton-like JSF implementation packaged with an application server and the various meaty web UI frameworks built on top of it. Regrettably, the decision often gets made just to use the JSF implementation the people at Oracle, Red Hat or IBM have packaged with their product, which is a mistake. Sticking with the JSF implementation packaged with the application server's web container is a safe bet, but it's also the wrong bet that has hindered adoption and innovation in the world of world of custom JSF implementations.
JSF should never have been included as part of the Java EE specification. That's not a slight against JSF. In fact, it would have been much more successful for Java EE users if stagnant versions of the framework weren't packaged as part of an application server. And this is also not a slight against JSF. This argument applies to all web UI frameworks, not just JSF. It was a mistake to add JSF to the J2EE specification way back in 2003. Sadly, the JCP is making that same mistake again by making JSR-371, the MVC web UI framework, a permanent part of Java EE 8.
