JDK 1.2: Features and critiques

Wednesday Dec 9th 1998 by Alexander Day Chaffee

In Part 2 of our review, we cover the "why-to-buy" aspects of the new "Java 2" release, including JFC/Swing, Collections, and Java for the Enterprise.

In Part 1 of this article, we discussed the history of the JDK 1.2 (which is also now being referred to as the key part of Java 2) release and issues of compatibility and support. Now we cover the "why-to-buy."



In case you've been living on a deserted mainframe for the last two years, let's start with what Swing is. First there was AWT, the Abstract Windowing Toolkit, 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 basically intact. Swing is a radical rewrite of the widget set.

Note that 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, not rewritten, but written again. (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 the two major problems with the AWT. 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 different, and have slightly different bugs.

Swing fixes these two problems by rewriting all the widgets from scratch for you, all in 100% Pure 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, all can have tooltips, are extensible, track the tab key for focus, support keyboard shortcuts ("accelerators"), are internationalizable, 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 widgets. A JTree is a hierarchical list, like the Windows Explorer. A JTable is a row-column spreadsheet, with cool features like 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. Yes, really! You can now display HTML files inside of any application or applet.

For some reason, my personal favorite feature of Swing is BoxLayout, a straightforward left-to-right (or top-to-bottom) layout manager. Layout Managers in AWT have always struck me as unnecessarily arcane. I've always thought, all we need is a simple vertical FlowLayout, and we can create pretty much any rectangular partitioning of the screen simply by nesting horizontal and vertical containers. With BoxLayout, we have that ability. (Try this thought experiment: think of any layout you could create using GridBagLayout. Now think of the same layout using nested BoxLayouts. Which was easier to code?) We can also do neat stuff within a container, like adding "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, for instance, use your own data objects as the store for a JTable (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.

I like Swing. It makes Java GUIs fun to program and makes your apps look sharp. And finally, somewhere between the Symantec 3.0 JIT and beta performance tuning, Swing widgets are not dog slow, at least on a 120-MHz Pentium. (At least Swing menus are quicker than Windows 95 system menus.)


While I won't get into specifics here, I must clarify a common naming confusion. Java Foundation Classes (JFC) is the name for a set of new JDK 1.2 services including but not limited to Swing. JFC is Swing plus Drag-and-drop plus Java2D plus Accessibility plus some other miscellaneous services (like Keyboard Navigation and Undo). In other words, Swing is in JFC, but JFC is not Swing.


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. Now 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. (We 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 JDK 1.2 docs; and for the record, I agree with them. From now on, says Sun, there's no reason to "roll your own" collections.

So why isn't Sun following its own advice? Nearly all of the new APIs use some sort of collection, and nearly none of them use the Collections Framework. JDBC has a ResultSet; HttpServlet has an HttpSession; JNDI has a Context; JList and BeanInfo and Class and so forth all return arrays of objects. None of these collections implement the framework interfaces.

To me, this seems to reflect a failure of internal marketing, not a failure of the APIs themselves. First, it took a really long time for the Collections team to finalize the API. Second, they decided to keep the framework as part of JDK 1.2 and not to release them 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). Finally (and this is pure speculation on my part), the framework must not have strong enough advocacy inside of Sun, so there was nobody on the inside pressuring, say, the JDBC group to support the APIs.

This is all too bad, but doesn't affect the bottom line: Collections are good. In as much as you use them, your code will benefit. Eventually, one hopes the various API development groups will see the light as well.

Java for the Enterprise

This topic really deserves a few articles of its own. Java is making a big marketing push to become the standard for enterprise computing. That means being chosen as a development platform for large companies who need to create large, distributed, reliable, high-performance, database-driven, transaction-aware, 24/7 monsters, um, that is, programs. So now Java does ...

  • CORBA -- JavaIDL is now a core package, and JDK 1.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 now 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 JDK 1.2 release, EJB is a huge initiative coming out at basically the same time, and 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 which can teach you more about EJBs.


JDK 1.2 (or Java 2) represents a major advance in Java's security model, augmenting our beloved (and maligned) 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 who the code was written by (the code signature). Programmers can also extend the Permissions model, easily 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 United States and Canada; third-party implementations are being developed outside the U.S.

Note that the user interface for all this has yet to be integrated into the major browsers; there is no GUI interface for keytool; and policytool, while graphical, is a little too scary for a non-developer to use. Looks like we'll have to wait a little longer for a universal, clean way to integrate Java crypto into our daily lives. However, as programmers, working on particular applications that need security, we can start work right now with JDK 1.2.


Despite its few wrinkles, JDK 1.2 is such an overwhelming improvement that I can't recommend it highly enough. Once it runs on Linux, Java will be poised to take over the universe -- yet again.



Thanks to Nelson Minar (http://www.media.mit.edu/~nelson/) for research and assistance preparing this article.

[1] Unfortunately, there's an annoying bug in BoxLayout -- it doesn't correctly align components to the left or the right. I'd like to ask you readers to do me a favor. Please go the Java Developer Connection Bug Parade and register a few of your three bug votes for bug number 12345. Maybe then it will get fixed ...

About the author

Alexander Day Chaffee is the CEO of Purple Technology, a leading Java training and consulting company. (If you want to take a class, click here!) He has been promoting, teaching, and programming in Java since way back in 1995. As the director of software engineering for EarthWeb, Alex co-created Gamelan, the official Java directory. He has also given presentations at numerous users groups and conferences, written articles for several magazines, and contributed to the book The Official Gamelan Java Directory.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved