Components « Development « Java Articles

The goal of this article is to arrive at a common conceptual framework to develop a Java component step by step, following Java best design practices, and starting from scratch. The expected audience of this article needs to have prior knowledge of Java and UML, and Java/J2EE design patterns. The key areas to be addressed in the this article are:

JSF is touted to be the ultimate component framework for Java web application programming. Tapestry claims to be based on the idea of component development. And across enemy lines, ASP.NET generated a whole new market for web components. What are web components and can they be developed with something more traditional like JSP and Struts?

"Write once, run anywhere." This has been the mantra of Java developers since day one. The philosophy has given us great flexibility and power, but always with trade-offs. Certain types of programming have effectively been off-limits to Java developers because of the speed requirements or access to native services. Now, finally, things are looking better. JIT virtual machines and Moore's Law have taken care of the speed improvements and the new JDesktop Integration Components finally let Java developers write programs that tie closely to the native operating system. Part one of this series covered the desktop, file, browser, and system tray components. In this article, we will explore an entirely new area, the SaverBeans SDK, which lets us write screen savers entirely in Java. We will go from a simple example to adapting a particle simulator with user-supplied configuration.

In the previous article in this series, we started creating a wizard component for a web application using a model-driven approach. We designed a set of rules represented by a linked list of wizard steps. Now it is the time to integrate these rules with a corresponding user interface (UI).

A wizard must execute its steps in the correct sequence. This is difficult to achieve in a web application, because a user can jump from page to page, or can leave the application, browse another web site, and then return back. It is possible to restrict a user to a certain step order by controlling page sequence. But a model-driven approach seems to be more robust, cleaner, and easier to implement, and provides better integration with the application domain model.

This book excerpt is from Chapter 6 of JavaServer Faces by Hans Bergsten, ISBN 0596005393 , copyright 2004. All rights reserved. This chapter, titled "Creating and Rendering Components," is posted with permission from O'Reilly Media.

JDesktop Integration Components, or JDIC, is a catchall project for a set of modules that gives Java developers access to native features through cross-platform APIs. It was started by the Desktop group at Sun to let Java applications better integrate with the desktop on which they are running. They made JDIC open source to as a way to get rapid feedback from developers on desired features, as well as bug reports. While there are no current plans to do so, the JDIC team is looking into pulling some of the JDIC features into a future version of the core Java libraries.

Java technology programmers often use the javax.swing.JList component to provide list views of similar data, whether it be a phone contact list or a grocery list. Despite the convenience of this user interface (UI) component, a JList doesn't sort its elements. It displays them in the same order provided by its underlying javax.swing.ListModel interface. Neither the ListModel interface nor the javax.swing.DefaultListModel class provides sorted data. Instead, the default model provides its content in the same order as you enter it. If you enter unsorted data -- for example, the letters B, C, and A -- the model provides it to list components without sorting it to either ascending order -- A, B, C -- or to descending order -- C, B, A. Lists are appropriate UI components for many applications, but an unsorted list has limited usefulness.

As fun as World Wind is to play with, that is not its purpose. Instead, World Wind is a Java technology component that you can integrate into your applications to incorporate 3D earth modeling. World Wind does all the hard work for you, such as dynamic image selection and retrieval for images of the earth's topography.

In a recent article, JSFTemplating was applied to writing JavaServer Faces components. That article presents a simple way to develop a JavaServer Faces component Renderer, moving the markup for a component from Java code to a template file and vastly improving the clarity and maintainability of the component.

We have two final components, a Session data holder, and an Authenticator. The SimpleSession is dirt simple with no dependencies. It just holds session state (the logged in user). The SimpleAuthenticator is more interesting. It depends on the UserDAO and the Session components. It also, finally, provides a service method (authenticate(String,String): void) which uses those components (sets found user in session if valid, throws exception if invalid (you can argue this point as well, I like exceptions for auth failure, other people like returning error codes)). It is worth noting that the only reason there is an interface/impl seperation between these particular components is for unit testing (maniax is allowed to argue this one, but notice they are seperated ;-)

Anders Hejlsberg: You can indeed do with interfaces what you do with delegates, but you are often forced to do a lot of housekeeping. Let's look at how you handle events in Java, for example, versus how you handle events in the .NET world. Because there are no delegates in Java, you end up using interfaces.

Swing has a lot of functionality to hope with this kind of task, but this time try to limit yourself to using only JButtons, JTextFields, JPanels, JLabels, and of course JFrame. The aim of this exercise is to get you thinking in terms of layout managers. How will you use layout managers to get the JFrame to look like a web browser using just this handful of lightweight components?

Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.

When Java APIs were first introduced, the AWT classes consisted of mostly heavyweight objects. (One exception to this was the Component class.) The objects are heavy because they require the simultaneous creation of what is known as a peer (that is, a platform-dependent object) in order to be displayed on the screen. The peer, also known as a native window, changes based on which platform you are running on. On the other hand, most Swing classes that extend AWT do not make use of a peer object so they don't carry the baggage that the original AWT classes do; hence the name lightweight. A lightweight component is not associated with a native opaque window. Therefore, no matter where you run your program, you will get the same look and feel, and most importantly there is no native code involved. In other words, if you use a non-Swing button, you will get a button whose look is based on the operating system (OS); whereas, if you use a Swing button, you will get a drawing of an object that appears to be a button independent of the OS. It is also important to point out that even though some of the classes make use of native OS code, this does not inhibit an application's portability. The native code is built into the Java run-time environment, not your application.

"... many developers noted that the APIs for FocusEvent and WindowEvent were insufficient because they did not provide a way for determining the "opposite" Component involved in the focus or activation change. For example, when a Component received a FOCUS_LOST event, it had no way of knowing which Component was gaining focus. Since Microsoft Windows provides this functionality for free, developers migrating from Microsoft Windows C/C++ or Visual Basic to Java had been frustrated by the omission."

The Fractional metrics' rendered hint is used to provide more precise drawing of the editor pane's content. We should restore the previous AffineTransform after scaling because the same instance of Graphics is used to paint other components in the parent frame.

I have already covered the difference between the interface and the implementation of a class. No matter how well you think out the problem of what should be an interface and what should be part of the implementation, the bottom line always comes down to how useful the class is and how it interacts with other classes. A class should never be designed in a vacuum, for as might be said, no class is an island. When objects are instantiated, they almost always interact with other objects. An object also can be used within another object, or be inherited. This article can be thought of as a dissection of a class and offers some guidelines that you should consider when designing classes. You'll examine a simple class and then take it apart piece by piece?using the cabbie example presented in an earlier column.

Today, server-side Java development has become simpler because of component models using EJBs. The fundamental concept behind these component models is to allow components to do only business logic and let the application server manage the non-functional features such as threading, performance and so forth. However, these components still do logging, billing, and other functionalities, which vary based on the deployment scenarios. If a framework or an application server could either provide these functionalities or allow plugging of components providing these functionalities, the reuse of these components would attain a much higher level. This article talks about obtaining such a reuse of components using the StateChangeListener design pattern, which is an extension of the Observer-Observable pattern.

So far in this series we've discussed how to trap events in Swing and how to safely change the GUI components in a multithreaded environment. In this article, we'll begin to get into Swing's feature-rich text components.

This technique of forwarding to peers is dubbed the "heavyweight component" technique because peers are resource intensive -- each heavyweight component renders itself in a separate native window. Additionally, native windows impose certain immutable characteristics, including a square shape and opacity. These qualities are inherited, making it very hard to build a set of, say, round or partially transparent components.