Jakarta Faces
| Industry | Software development |
|---|---|
| Predecessor | JavaServer Faces |
| Founded | 2001 |
| Headquarters | United States |
| Products | Java web framework for component-oriented user interfaces |
Jakarta Faces, previously known as Jakarta Server Faces and JavaServer Faces (JSF), is a Java standard designed for developing component-oriented user interfaces within web applications. It was formalized through the Java Community Process as a segment of the Java Platform, Enterprise Edition. Functioning as an MVC web framework, JSF facilitates the creation of server-side user interfaces by leveraging reusable components.[1]
The default templating mechanism for JSF 2.x is Facelets, whereas JSF 1.x relies on JavaServer Pages (JSP). Additionally, developers have the option to construct views using either XUL or pure Java.[2]
History
The initial proposal for what evolved into JavaServer Faces appeared in 2001 with the first Java Specification Request (JSR), suggesting the package javax.servlet.ui.[3] That June, Amy Fowler and her team at Sun Microsystems developed the JavaServer Faces API, codenamed "Moonwalk," which served as a framework for building web-based user interfaces compatible with standard HTML across various browsers.[4]
Developments
Facelets, created specifically for JavaServer Faces, became the official view technology starting with JSF 2.0, addressing lifecycle conflicts inherent in JSP that previously required developers to implement workarounds.
Enhancements in JSF introduced extensive support for Java annotations such as @ManagedBean, @ManagedProperty, and @FacesComponent, which reduced reliance on faces-config.xml files except when extending the framework. Navigational processes were simplified, enabling page transitions by directly specifying the target View or Facelet name.
Standardized AJAX support incorporated Partial State Saving along with updates to the DOM.
JSF 2.0 also brought integrated resource management for assets like images, CSS, and JavaScript. This allowed resources to be bundled within component libraries, JAR files, or placed at consistent locations within web applications, supporting logical naming conventions and version control.
Other notable features added in JSF 2.0 include event handling capabilities, distinct development/staging/production modes comparable to RAILS_ENV in Ruby on Rails, and a considerably broadened set of standard UI components.
Update history
- JSF 4.0 (2022-05-15) – Deprecated features such as native managed beans and native EL references were removed; extended view support disabled by default; introduced ClientWindowScoped.
- JSF 3.0.0 (2020-10-28) – Transitioned package namespace from Javax to Jakarta.
- JSF 2.3 (2019-09-10) – Debuted Jakarta Server Pages API for Jakarta EE; no changes to API or behavior.
- JSF 2.3 (2017-03-28) – Added search expressions, extensionless URLs, bean validation on classes, push communication via WebSocket, and improved CDI integration.
- JSF 2.2 (2013-05-21) – Introduced stateless views, page flow management, and portable resource contracts.
- JSF 2.1 (2010-11-22) – Maintenance update featuring minor specification refinements.
- JSF 2.0 (2009-07-01) – Major upgrade enhancing usability, features, and performance; aligned with Java EE 6.
- JSF 1.2 (2006-05-11) – Strengthened core architecture and API; incorporated into Java EE 5.
- JSF 1.1 (2004-05-27) – Bug-fix update without modifying specifications.
- JSF 1.0 (2004-03-11) – Initial formal release of the specification.
Operation
JavaServer Faces (JSF) utilizes a component-centric approach for building user interfaces, relying on XML view templates or Facelets for defining views. Incoming requests are managed by the FacesServlet, which loads the designated view, constructs a tree of components, processes events, and generates the output—usually in HTML format. After each interaction, UI component states along with scoped objects are preserved through stateSaving (with transient set to true) and restored when the view is reconstructed. This state preservation can occur either on the client side or the server side.
JSF Integration with AJAX
JSF frequently incorporates AJAX to deliver sophisticated user interfaces via dynamic web technologies. Early JSF reference implementations such as Mojarra and Apache MyFaces initially supported only HTML rendering, requiring additional JavaScript to enable AJAX capabilities.
The release of JSF 2.0 introduced built-in AJAX support, standardizing the AJAX request process and offering simplified APIs for handling AJAX-triggered events. This mechanism allows client-side events to be validated, converted, and invoke backend methods prior to updating the browser’s display through XML DOM manipulation. Moreover, JSF 2 ensures graceful degradation when JavaScript is disabled, enhancing accessibility and robustness in enterprise environments.
AJAX-Enabled Frameworks and Component Libraries
Several prominent organizations and projects provide AJAX-capable JSF frameworks or component suites, including:
- Apache MyFaces – The Apache Foundation’s JSF implementation featuring AJAX components
- Backbase Enterprise AJAX – JSF Edition – An AJAX framework tailored for JSF
- BootsFaces – An open-source JSF framework built upon Bootstrap
- IBM Notes – XPages
- ICEfaces – An open-source Java JSF extension offering rich AJAX components without requiring JavaScript coding
- JBoss RichFaces (which succeeded AJAX4jsf) – Provided AJAX-enabled JSF components for layouts, file uploads, forms, and inputs; discontinued as of June 2016
- OmniFaces – A community-driven open-source utility library for JSF
- OpenFaces – An AJAX framework supplying JSF components
- Oracle ADF Faces Rich Client – A segment of Oracle’s Application Development Framework
- PrimeFaces – A comprehensive AJAX framework with extensive JSF component offerings
- Sun Java BluePrints AJAX components
- ZK – An AJAX-based framework integrating with JSF components
ThoughtWorks Report, 2014
In its January 2014 edition of Technology Radar, ThoughtWorks advised against adopting JSF, criticizing its flawed abstraction over HTML, CSS, and HTTP protocols. The report argued that JSF’s endeavor to impose statefulness on the inherently stateless HTTP leads to challenges in managing server-side state. It recommended opting for simpler frameworks that more naturally align with web standards.
Counterargument
Responding in February 2014, Çağatay Çivici, PrimeFaces Lead Developer, defended JSF by highlighting recent enhancements that facilitate seamless integration of custom JavaScript, HTML, and CSS. He underscored that JSF’s stateful design simplifies application development and pointed out improvements in versions 2.0 and later—such as stateless mode operation and partial state saving—that bolster scalability and performance.
DZone, 2014
In November 2014, DZone featured an article authored by Jens Schauder entitled "Why You Should Avoid JSF," which underscored significant deficiencies within JSF's Facelets framework. Schauder condemned the blending of HTML markup with UI update logic in Facelets, arguing that it breaches the fundamental separation of concerns principle. Additionally, he highlighted erratic server-side lifecycle modifications caused by the immediate attribute, which increase complexity in both development and upkeep.
TheServerSide, 2016
In February 2016, TheServerSide issued a caution against employing JSF in enterprise environments, identifying five primary limitations:
- Difficulty executing straightforward operations;
- Restricted adaptability;
- A challenging learning process;
- Lack of compatibility with core Java technologies; and
- Minimal AJAX capabilities.
These factors were noted as potential risks to product quality and development productivity.
- ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
- ↑ NoVDL: Write your JSF views in pure Java
- ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
- ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).