Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
At this week’s Java Business Expo in New York, Sun’s just-released platform upgrade, Java 2, has been the core focus. Previously dubbed JDK 1.2, the new release includes a variety of noteworthy features. This week, we will look at the following:
Swing
Let’s start with what Swing is. First there was the Abstract Windowing Toolkit (AWT), which shipped with JDK 1.0. AWT provides a core set of “widgets” (or user interface components), including buttons, windows, scrollbars, and so on. JDK 1.1 changed the event model, but left the widget set intact. Swing is a radical rewrite of the widget set.
The fundamental AWT classes — Frame, Graphics, Image, and so forth — are still used to manipulate pixels and to put them on the screen. However, everything that sits on top of those classes has been rewritten. (You can still use AWT widgets, but who’d want to?)
For a number of reasons, the designers of AWT used a so-called “peer architecture” to implement the core components. Each widget in the AWT does not actually draw itself, rather, it possesses a native “peer” object that interacts with the native OS widgets — the native widgets do the actual drawing and event processing. While it was a valiant first pass, it leads directly to two major problems. First, it’s impossible to extend (subclass) the various widgets. Since the OS is dealing with all the drawing and event-processing, if you wanted to design, say, a button with an icon on it, you would have to build it from scratch. Second, Java GUIs behave differently on different platforms — they look slightly different, act slightly differently, and have slightly different bugs.
Swing fixes these problems by rewriting all the widgets from scratch for you, all in Java. There are now “J” versions of all the basic widgets — JButton, JFrame, JList, and so on. These basic widgets all share a solid foundation of common functionality, as well as possessing many new features. For instance, all widgets are double-buffered, can have tooltips, are extensible, track the Tab key for focus, support keyboard shortcuts (“accelerators”), are customizable to specific countries, and more. JButtons and JLabels can contain icons, built from GIF files, in any orientation. JPanels can have standard borders. JMenus or JMenuBars can be added to any container. And so on.
In addition to the basic widgets, Swing adds several new ones. A JTree is a hierarchical list similar to Windows Explorer. A JTable is a row-column spreadsheet with cool features such as resizable and moveable columns. A JScrollPane allows you to scroll any container. A JToolbar is a floatable panel that contains little icons representing actions. A JEditorPane provides a fully functional HTML renderer. You can now display HTML files inside of any application or applet.
A noteworthy feature of Swing is BoxLayout, a straightforward left-to-right or top-to-bottom layout manager. If you thought Layout Managers in AWT were unnecessarily arcane, you’ll appreciate BoxLayout’s capability to create a rectangular partitioning of the screen simply by nesting horizontal and vertical containers. (Try this experiment: Think of any layout you could create using GridBagLayout. Now think of the same layout using nested BoxLayouts. Which was easier to code?) It also lets you do neat stuff within a container, like add “glue” and “struts” to keep the components together or apart. [*1]
Swing also adds some good fundamental GUI design concepts. All Swing widgets use a model-view-controller (MVC) architecture, making it possible to use your own data objects as the store for a JTable, for instance, rather than storing copies of your data inside the Jtable itself. MVC also allows a “pluggable look-and-feel” (PLAF), which allows a Swing app to masquerade as a Windows, Mac, Motif, or other app. An Action allows you to decouple a piece of functionality (for instance, “Save Document”) from the widgets that initiate that functionality — menus, buttons, toolbars, and so on.
JFC
Java Foundation Classes (JFC) is the set of new Java 2 services including but not limited to Swing. JFC is Swing plus Drag-and-drop plus Java2D plus Accessibility plus some other miscellaneous services such as Keyboard Navigation and Undo. In other words, Swing is in JFC, but JFC is not Swing.
Collections
Every computer science major has to take a course in Data Structures and Algorithms; every such class covers the Stack, the Queue, the Set, the Linked List, sorting algorithms, and so on. Java has finally passed CS 101. The Collections Framework provides a clean, standard, interface-based set of classes and methods that are both simple and powerful, plus a set of sorting algorithms. (You can finally sort an array!) Using the List, Set, and Map interfaces “reduces programming effort, increases performance, allows for interoperability among unrelated APIs, reduces effort to design and learn new APIs, and fosters software reuse” — so say the Java 2 docs. From now on, says Sun, there’s no reason to “roll your own.”
However, while nearly all new APIs use some sort of collection, almost none use the Collections Framework. JDBC has a ResultSet; HttpServlet has an HttpSession; JNDI has a Context; JList and BeanInfo and Class and so forth return arrays of objects. None of these collections implement the framework interfaces.
This lack of implementation does not necessarily reflect a failure of the APIs themselves. It took a long time for the Collections team to finalize the APIs. Furthermore, the team decided to keep the framework as part of Java 2 and not to release the APIs early as a “standard extension.” This meant that while the Collections Framework has been ready for action for the better part of a year, it has been difficult to integrate into other programs (suffering the same package naming confusion as Swing).
Java for the Enterprise
Sun is making a big marketing push for Java to become the standard in enterprise computing by being chosen as the development platform for companies creating reliable and high-performance distributed, database-driven, transaction-aware programs.
- CORBA — JavaIDL is now a core package, and Java 2 contains a pure Java ORB. That means any Java VM can act as a CORBA client or a CORBA server, and any Java object can become accessible through CORBA.
- RMI — You can now use custom sockets, sending RMI requests over SSL or IIOP. Also, a remote object can remain dormant until created by a client request.
- Transactions — Java 2 supports an implementation of the OMG/CORBA Object Transaction Service (OTS/JTS) with an alternate Java API on top (JTA). This allows a single transaction to comprise actions occurring on multiple VMs and multiple databases; all those actions will either succeed or fail as one.
- JDBC — Database access has been improved, with support for scrollable and updatable result sets, batch updates, connection pooling, rowsets (sort of a Bean-enabled database view), distributed transactions, extra data types, and so on.
- Enterprise Java Beans — While not technically part of the Java 2 release, EJB is a huge initiative coming out at basically the same time relying on the above enterprise features. EJB provides a common API for developing business components that live inside of Java application servers, provided by many different vendors. There are several organizations that can teach you more about EJBs, such as Purple Technology.
Security
Java 2 represents a major advance in Java’s security model, augmenting sandboxes with a much more subtle and capable system based on permissions and identity. Security in the VM is defined by the Policy, which provides a way to control the powers of pieces of code. The Java SecurityManager now delegates its work to the Policy object; the Policy, in turn, consults a policy file to decide whether sensitive operations are allowed. The Policy grants particular Permissions to the program based on a combination of where the code came from (the code base) and by whom the code was written (the code signature). Programmers can also extend the Permissions model by adding their own application-specific security checks.
Policies can be defined by editing a file or by using the new policytool application. The new security model allows for a great range of possibilities. For example, a user may decide to allow applets to save files to particular directories if they come from a trusted source. There is also more control over network-loaded code; this will be of particular interest to distributed Java efforts such as RMI and Jini.
Java 2 also expands support for cryptographic key management, including a keytool for managing key databases. Sun has also defined a Java Cryptographic Extension (JCE) to give an interface to public and private key encryption. Because of U.S. export restrictions, the JCE implementation will only be available from Sun in the U.S. and Canada; third-party implementations are being developed in other markets.
Although the new platform supports these security features, a user interface has yet to be integrated into the major browsers. Keytool offers no GUI interface for keytool and policytool, while graphical, may be somewhat intimidating for the non-developer.
References
- Announcing the Java 2 Platform
- Java Business Expo ’98
- The Swing Connection
- JDK 1.2 Documentation on Security
- Overview of Java security
- Java Security Tutorial
[*1] Due to a bug, BoxLayout doesn’t correctly align components to the left or right.
Nelson Minar contributed research to this article.
