Developer: J2EE

DOWNLOAD Oracle JDeveloper 10g

TAGS java, ajax, jsf, jdeveloper, All

Swing or JavaServer Faces: Which to Choose?

By Frank Nimphius and Duncan Mills

Are AJAX and JSF the only future for UI development, or will Swing survive the Rich Internet Application hype?

Published March 2006

In a very short time, J2EE Web technologies have evolved from a static content serving environment to a reliable platform for dynamic business applications that run on the intranet and the internet. The promise of the Web is that in the future the browser is the only client you need, no matter what your business requirements are. On the back of this trend, a new hype has recently spun off around highly interactive Web interfaces, based on a set of technologies known as AJAX. AJAX in combination with the new J2EE standard JavaServer Faces (JSF) is poised to deliver better end user experience and acceptance when working with Web applications.

AJAX, which is an acronym for Asynchronous Javascript+XML, describes the usage pattern for a set of already existing technologies, like JavaScript, XML and the Document Object Model (DOM). It is undeniable that AJAX and JavaServer Faces have a momentum and that soon they will get into the way of Swing, which has been the standard way of building rich user interfaces in Java since 1998. Will the future be browser based, or can Swing survive the Rich Internet Application hype?

This article is an introduction, positioning, and comparison of Swing and JavaServer Faces. It helps developers to decide which technology to use for a specific job and also explains how the Oracle Application Development Framework (ADF) helps to simplify application development with both technologies.

From Java to Swing to JavaServer Faces

Many programming languages have come and gone in the history of application development. Back in 1991 James Gosling invented Java as “Oak.” Failing to sell Oak, Sun announced Java in 1995 as a programming language for the Web and soon thereafter, Java Applets became the dominant technology in this "stone age" of Web application development.

The Java Swing platform was released in 1998 for the development of lightweight Java Web GUIs and client desktop applications. A year later, Sun announced the availability of the Java 2 Enterprise Edition (J2EE) platform, into which 6 years later JavaServer Faces is introduced.

Swing itself is a lightweight component set that is built on top of the Abstract Window Toolkit (AWT) and the Java Foundation Classes (JFC). Having been with us for over seven years, the Swing package is a very mature Java library in J2SE that is widely adopted for building enterprise class business applications.

The reputation of Swing is one of a flexible and powerful development environment that puts a lot of control into the hands of the application developer. It is not exaggerated to say that if you can think it in Java, you can build it with Swing. The price for this flexibility in Swing is complexity and a learning curve to master. Java IDEs like Oracle JDeveloper, NetBeans, and IntelliJ provide visual and 4GL editing for Swing that helps developers to get started quickly and also to get quite far without having to learn Swing in depth.

Finalized in March 2004, JavaServer Faces, also referred to as JSF or simply “Faces”, is a component-based framework for building Web applications, which incorporates the JavaBean event model for propagating information to other components. As an evolution in J2EE Web technology, JavaServer Faces combines template based and programmatic Web development plus the option for 4GL type of development.

J2SE Swing Architecture

Though an official part of the Java Standard Edition (Java SE), Swing is not a member of the core Java language but considered a standard extension. This is also reflected in the Swing package naming that starts with javax.swing instead of java.swing. Applications developed with Swing execute in the Java Runtime Environment (JRE), which can be installed on the local desktop client or integrated in Java Web Start or Web browsers.

All Swing UI components are JavaBeans and implement the Model-View-Controller architecture to decouple the presentation of data from the operation on it. The model doesn’t contain any UI specific code and vice versa. All information exchange between the model and the UI is performed through JavaBean events and listeners. This separation of responsibility enables experienced Swing developers to customize the component UI without changing the components behavior. The component controller and the view in Swing are referred to as the UI Delegate. The controller dispatches user interactions to the model, which holds the state of the component.

Figure 1 Swing architecture

UI components in Swing are controlled programmatically through property methods at runtime or visual editors at designtime. Not all components in Swing are bound to data and some, like buttons, only need to handle GUI state.

Events on UI components are detected through registered JavaBean listeners like MouseListener, FocusListener or ChangeListener.

ADF and Swing

A persistent difficulty in Swing is one of how to bind components to dynamic data. In the past, this challenge has been solved many times by different frameworks in a non-standard ways.

ADF, an early adaptor of JSR-227— a proposed standard for addressing this data binding challenge — and ADF Swing bind Swing applications to all business services like Enterprise JavaBeans, TopLink, Web Services, ADF Business Components and URLs in a standard way.

ADF Swing is a small Java layer that binds the Swing domain model to the Oracle ADF binding. The ADF Swing developer declaratively sets the component model to a named reference in the ADF binding. Data controls in ADF expose a consistent client development API to different business services for Swing developers to work with. Data controls implement standard methods for creating, removing and inserting data, as well as controls to navigate through data sets. The ADF binding exposes a smaller subset of data accessible from the data control to the Swing application panel or frame.

Swing developers don’t need to know about the business service the application is build upon because they no longer work against specific model APIs. Likewise they have no responsibility for resource lookup or similar tasks. This is all handled by the JSR-227 implementation, which provides an effective inversion of control mechanism.

Because the development of ADF Swing applications is mostly a declarative task with ADF, it shortens the application development cycle for beginners and Java experts alike. For example, UI first binding makes rapid prototyping easy for project teams. An unbound version of the UI can be created as a proof of concept, and then later retrospectively bound to a service.

Figure 2 ADF Swing architecture

JavaServer Faces

JavaServer Faces is a milestone in Web application development that will become available as part of the core Java Enterprise Edition platform in J2EE 5.0, which SUN recently rebranded to JEE 5.0. JavaServer Faces is available for use in J2EE1.4 application servers as a stand-alone Servlet.

The Web was never designed for business applications that require transaction and state handling. Over years developers spent a great deal of time tracking the state of a Web application using techniques such as hidden HTML fields, cookies, URL or session parameters just to overcome the problem of the HTTP protocol being stateless. JavaServer Faces helps developers to focus back on the business requirements of an application and no longer on the underlying delivery technology. JavaServer Faces is a UI framework that hides the details of the HTTP request – response cycle from the application developer.

Similar to the JavaBean architecture in Swing, JavaServer Faces uses UI components with state and behavior exposed through properties, for building Web interfaces. Though JavaServer Faces pages are generally assembled in JSP files, this is not a requirement. JSF is not a technology only for browser-based applications only but also for building mobile applications. UI components in JavaServer Faces are display agnostic. This means that the application developer doesn’t build applications for a specific device but applications that can run on many devices. The UI component renderer class, as part of a packaged set of renderers, in JSF determines the visual representation of a UI. If the initial application request comes from a Web browser then this representation is in HTML, otherwise an application is rendered as supported by the requesting client device, assuming a set of renderer classes exist for the device type.

A UI component, like a text field, is bound to the (JSF) managed bean model through ExpressionLanguage (EL) value binding. In value binding, EL is used to reference a pair of setter and getter methods in a backing bean. For example, the EL expression #{users.firstname} binds a JSF component to the setFirstname and getFirstname methods in the users bean. Another possible form of EL binding is method binding. Method binding references a method in the managed bean and is used in JSF to bind action properties, as in buttons, to the view layer logic to execute in case of complex navigation cases or if pre- and post- navigation processing is required.

Figure 3 JavaServer Faces architecture

Another role of managed beans is to bind UI components to domain data, e.g. accessing the result set of a JDBC query or looking up an Enterprise JavaBean (EJB) session. Additionally, UI components on a page can have a representation in the backing bean for programmatic access.

Oracle Application Development Framework (ADF) and JavaServer Faces

Oracle JDeveloper 10.1.3 supports JavaServer Faces development with visual editors. In addition, Oracle ADF can be used to declaratively bind JavaServer Faces and ADF Faces components to business services data. As mentioned when discussing Oracle ADF in the context of Swing, using the Oracle ADF binding provides a consistent development API for JavaServer Faces Web application developers to access Web Services, Enterprise Java Beans, TopLink, POJOs, ADF Business Components and other types of business services.

ADF Faces is the name for a set of 100+ JSF UI components that are built on top of the JavaServer Faces APIs and can be deployed into any JSF implementation, like the Reference Implementation from Sun or Apache MyFaces. In addition to an HTML renderer kit for browser clients, ADF Faces provides renderers for Web applications to display on telnet clients, mobile devices and PDAs, supporting the strength of JavaServer Faces as a display agnostic Web application development environment.

To integrate ADF with JavaServer Faces applications, the Expression Language value binding accesses the ADF bindings object, instead of data in the backing bean. The ADF binding object, named ‘bindings’ by default, is created on application initialization by the ADF servlet and grants developers access to all collections and methods exposed through the ADF data control and binding layer.

To reference and work with the ADF binding object programmatically in a backing bean, the binding object can be accessed through the ExpressionLanguage expression #{bindings} in the faces configuration and injected to the backing bean as the value of a managed property.

Figure 4 JavaServer Faces architecture with ADF

Delivering the Rich Internet Application Promise: AJAX and ADF Faces

AJAX is easy to understand but hard to implement for developers that aren’t Web technology experts familiar with Javascript, XML or the Document Object Model (DOM). For business applications AJAX only makes sense if used “ready made” within a component with a Web application framework like JavaServer Faces.

ADF Faces provides partial page rendering and dialog support that enable developers to build better Web clients. As an early implementation AJAX, partial page rendering decreases client response time in that it reduces the download size for Web pages that only need to refresh parts of the page.

The future direction of ADF Faces is to provide a set of Rich Internet Components, which leverages AJAX, for the Web application developer to build highly responsive and interactive Web clients without having to code JavaScript or DHTML. A sneak preview of the ADF Faces Rich Internet Application client was presented for the first time during JavaOne 2005.

When to use which technology?

• Development: The major Java IDEs support visual development for Swing and JavaServer Faces. When developing JavaServer Faces applications, developers can go a long way without having to write Java code.
• Components: Both, Swing and JavaServer Faces are component based using JavaBeans for their UI components. It is also possible to create custom components to use within an application.
• Pages and Layouts: Layouts in Swing are defined through nested Swing panels. The position of Swing components and their resize behavior is determined through LayoutManagers. Similarly in JavaServer Faces, the layout is defined through containers, like PanelPage and PanelBox in ADF Faces. A container can have many child components, with each of them being containers themselves. Though it may be tempting to use HTML tables to layout JSF applications, mixing technologies is not recommended when working with JSF applications.
• UI responsiveness: AJAX will do a much better job for Web applications with respect to immediate feedback given to users based on provided input or events raised in the model layer. Swing user interfaces are highly responsive and can refresh specific areas on the screen without repainting the whole. A stock application, for example, may send information to a Swing application about changed values, which the can be displayed to the user without having to re-query.
• Update, Insert and Delete: The Web model is based on the HTTP protocol, which is not designed for transactional and dynamic business applications. JavaServer Faces automatically handles a lot of the problems Web developers were facing in the past, but still, with handling multi row updates, there is an area that requires the developer to have his hands on. In contrast, In Swing multi row operations are no-brainers for application developers e.g. working with ADF Swing.
• Look and feel: Swing supports dynamic look and feel classes that apply a specific color scheme to an application at startup. The application look and feel is changed without changes required to the application code. JavaServer Faces uses style sheets to show different user look and feels. In addition Oracle ADF Faces provides a feature called skinning that works similar to the look and feel classes in Swing.
• Internationalization: Both technologies support string translations using resource bundles. JavaServer Faces obtains the preferred user language from the browser settings on the client while Swing applications determine the language from the locale set on the Java Runtime Environment. Both, JavaServer Faces and Swing can set the language programmatically so the application user could select a translation from within the application.
• Event model: JavaServer Faces and Swing components both use the JavaBean event model to publish information about changes in the model or the components. Interested parties can register events, like value change events, property change events or phase events using JavaBean listeners.
• Keyboard shortcuts: Though both technologies support keyboard shortcuts, Swing clearly has an advantage here because it is not dependent on browsers. All keyboard functionality is handled by Swing and can be controlled by the application developer.
• Desktop integration: Swing applications, if installed locally, have full access to the client desktop. JavaServer Faces applications provide only limited client desktop integration through the ability to upload and download files.
• Navigation: Swing performs programmatic navigation only. There is no external controller defined for the Swing standard that defines which panel should be displayed based on the outcome of an action. JavaServer Faces uses a controller component that can be configured with named navigation cases based on the outcome of an evaluation. The navigation can be defined as a static string for action components or, for more complex navigation, expressed in Java.
• Application control: Related to navigation, application developers have more control over a Swing application on the client compared to what is possible in JavaServer Faces. Users run a Swing application within a Java Runtime Environment, which isn’t conflicted e.g. by a toolbar that is not part of the application itself. JavaServer Faces applications running in a browser will always require developers to work around known browser limitations. Today there is neither a common browser standard nor a set of common APIs that enable application developers to switch off unwanted browser behavior or functionality, such as the browser back button or keyboard shortcuts reserved by the browser.
• Performance: For applications that perform data intensive operations, JavaServer Faces appears to be more performant than Swing because it downloads only display changes to the client. With AJAX, the required download size will become even smaller and performance will improve further. Though Swing can use business logic deployed on a remote server, this requires the use of remote method invocation (RMI), which is less performant than the JavaServer Faces model. Network performance however should always be analyzed for the individual application and in the context of possible user interface requirements of an application should be taken into consideration.
• Security: JavaServer Faces is integrated with declarative J2EE security making it easy to protect Web applications and to integrate with single sign-on. Swing is more difficult to protect and uses J2SE permission based security in combination with the Java Authentication and Authorization Service (JAAS), which requires more expertise.
• Deployment: JavaServer Faces are deployed to a J2EE container and accessed from the Web. The architecture of the deployment can be two-tier, where the business logic resides on the same server as the view layer, or three-tier. Swing usually is deployed on local clients or via JavaWeb Start, a server based software management option in J2SE. For JavaServer Faces deployment will be easier and more manageable using the Oracle Application Server Control or similar administration consoles.

To summarize the above, you use Swing today if your application requires immediate response to user inputs or events that change the user display. This also is true for complex User Interfaces that have multiple master-detail dependencies displayed on one screen. Applications that need to perform immediate item validation, which could be based on complex logic, also find better support in Swing than on the Web. Another key argument for Swing is the need of desktop integration that goes beyond file upload and download. Examples for such integrations are local printer access, access to external devices like phones or scanners and similar. Applications that need to define their own keyboard mappings are also better served with Swing than Web technologies where the enclosing browser consumes some keyboard combinations. Other browser functionality, like the browser back button, that could get in the way of the business controlled application navigation is not a problem when building Swing applications. Some businesses require applications to work offline, disconnected form the network, which is what you can build Swing applications for. Finally, Swing applications are developed in one language only, while JavaServer Faces uses a mixture of technologies like Java, XML and ExpressionLanguage.

You use JavaServer Faces and AJAX if you need applications that are accessible from everywhere with no client side installation required. This includes possible support for displays like PDAs, mobile phones and telnet clients. Unlike Swing, JavaServer Faces applications work easily through firewalls, using HTTP or HTTPS for protected client to server communication. JavaServer Faces are easier to deploy and require fewer resources on the client, because application logic is executed on the server. Today Internet applications are pervasive, and you can assume that application users are familiar with the look and feel and handling of Web applications. This reduces the learning curve a user has when working with new applications. Security is another important argument for using Web based JavaServer Faces applications. While it is possible to build secure Swing applications with JAAS, it is much easier to do so for Web-based applications that integrate with container managed security and single sign-on on the server. In addition, security integration in which identities need to be propagated to other components or applications is easier to achieve in JSF than in Swing. However, you should be alerted that using JSF in combination with AJAX is based on Javascript, which need to be enabled on the browsers.

Looking forward, advantages that the Swing technology has today will vanish over time. As an example, in the US, the cities of Philadelphia and San Francisco have initiated projects to provide wireless access all across the city. Once this model is adopted by the rest of the world, the ability to work in disconnected mode – a strength of Swing today – will no longer be a valid requirement. Another example of Swing losing ground is the advantage of immediate client display response that AJAX promises for Web applications.

Productivity with Choice: If you had to learn just one skill?

A quick search on Internet job offerings shows that the job market for Web application developers today is much larger than for Swing application developers. Ideally the single skill you want to learn therefore is Web application development, which includes JavaServer Faces, AJAX and JavaServer Pages.

For occasions where there is a need to develop Swing applications, Web application development skills are sufficient for this if the Oracle Application Development Framework and Oracle JDeveloper is used in combination with Swing.

Oracle JDeveloper is an integrated Java IDE that supports the complete development cycle for J2EE desktop and Web applications. Using the Oracle Application Development Framework, the application developer no longer has to learn how to work with different APIs to access various persistence layer technologies but can work with a single consistent API instead.

Using Oracle ADF, Web application developers work with the same set of meta-data files at design time and runtime that the Swing application developer uses to build Java desktop applications. Providing similar development gestures, a Swing application developer will find it easy to develop we applications and vice versa. Thus, if you had to learn just one skill, learning how to develop Web applications with the Oracle Application Development Framework is the best recommendation.

Summary

JavaServer Faces and AJAX is there for the same reason that humans learned to walk - evolution. Web applications began as static interfaces and have evolved into a platform for dynamic applications. AJAX is just the next logical step that needs to be seen in the context where it makes the most sense - JSF. Having rich Internet clients gives developers the choice to use the right technology for a problem to solve

• Rich Internet Applications (AJAX)
• Component based Web Clients (JSF)
• Dynamic markup based Web clients (JSP)
• Desktop integrated clients (Swing)

AJAX describes a perspective for J2EE application developers to bring complex business applications to the Web. As a Swing developer, you don’t need to like the hype around AJAX but you should like the idea behind it. Hype is the marketing of new opportunities, and this is what JavaServer Faces and AJAX are: New opportunities for application developers to build rich Web applications.

Swing is the standard way to develop Java applications for the client desktop and is the solution for a different type of development problem than JavaServer Faces and AJAX. It is continuously developed and enhanced through the community process and the work done at Sun, who also leads the Java Desktop Network Components (JDNC) project.

Though there is a functional overlap between Swing and JavaServer Faces/AJAX, they don’t directly compete. The technology that you choose for a job must address the problem you want to solve and not vice versa. Using the Oracle Application Development Framework, developers have the unique flexibility to choose the appropriate technology to develop Web applications and desktop applications with a single underlying skill set.