One of the really great things about having a custom-built Java implementation for the AS/400 is that the environment can be optimized to take advantage of the unique architecture of the machine. IBM’s Java implementation, implemented as it is “below the machine interface (MI),” does just that. There is a downside, however: Patience is required. Much of the rest of the computing world has been enjoying their Java 2, formerly known as Java Development Kit (JDK) 1.2, implementation since December 1998; we AS/400 programmers are still waiting. AS/400 implementation of the Java 2 specification will be available as a PTF later this year. (The Java Virtual Machine, or JVM, that comes with V4R4 is compliant with JDK 1.1.7.) According to MC’s Monday Morning AS/400 Update, the Java 2 PTF should have arrived alongside the DB2 Universal Database PTF sometime in September.

Fortunately, the specification for the JVM did not change significantly from JDK
1.1.x to Java 2. Nonetheless, Java 2 is really a significant leap for the language: There’s more functionality, much tighter security, and better enterprise integration available. The upgrade from JDK 1.1.x to Java 2 was termed a “library and performance” release by Sun, meaning that the bulk of the new stuff is in the API. In this article, I give you a quick peek at some of the new features available in Java 2.

The most hyped component of Java 2 is, without a doubt, the Java Foundation Classes (JFC). JFC is the set of new Java 2 services for GUI programming. The components of JFC had been available for more than a year before Java 2 was announced; they were (and still are) available as a widely distributed beta called Swing. JFC is Swing (more on this in a moment) 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.

Swing is a rewrite of the Abstract Window Toolkit (AWT). The AWT was a “lowest common denominator” set of GUI classes. What this means is if a function wasn’t available on one of the platforms supported by Java, it wasn’t available on any platform. Furthermore, the widgets (buttons, frames, etc.) didn’t look or behave identically on all platforms, because the ultimate responsibility for drawing the widget and processing events

JFC

fell to the operating system. (Widget is a generally accepted term for a software component.) Even worse, because of the operating system reliance, the AWT widgets weren’t extensible. For instance, if you wanted to design a button with an icon on it, you had to build it yourself.

Swing fixes these problems by rewriting all the widgets for you from scratch, all in Java. There are now “J” versions of all the basic widgets: JButton, JFrame, JList, and so on. In addition to the basic widgets, Swing adds several new ones. JTree is a hierarchical list similar to Windows Explorer. JTable is a row/column spreadsheet with cool features such as resizable and movable columns. JScrollPane allows you to scroll any container. Finally, JToolbar is a floatable panel that contains little icons representing actions.

Swing also changes the way in which you manage the GUI. All Swing widgets use a Model-View-Controller (MVC) architecture, making it possible, for instance, to use your own data objects as the store for a JTable rather than store copies of your data inside the JTable itself. MVC also allows a “pluggable look and feel” (PLaF), which makes a Swing app look and feel just like a Windows, a Mac, a Motif, or some other app. The JDK download includes samples of various PLaFs for you to try.

Security in Java 2 is much improved from that in JDK 1.1.x. In fact, the JDK “Summary of New Features” (java.sun.com/products/ jdk/1.2/docs/relnotes/features.html) on Sun’s Web site lists the security enhancements first. Clearly, this is an area that had come under scrutiny as companies investigated Java. In a time when companies fear Internet security breaches and individuals fear computer viruses, it’s great to know that Java 2’s security features are superior to those of any other language available for Internet applications.

Java 2’s security model augments the sandbox with a much more flexible system based on permissions and identity. Without augmenting the default sandbox security features, Java applets run in a highly restricted mode. Security in the virtual machine is defined by the Policy, which provides a way to control the powers of pieces of code. Java Security Manager now delegates its work to the Policy object. Policy, in turn, consults a policy file to decide whether sensitive operations are allowed. 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). You can extend the Permissions model by adding your own application-specific security checks.

Policies can be defined in a policy file or by using the new policytool application. This 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 the applets come from a trusted source. The level of control available is akin to AS/400 data access rights, where some users get only READ access to data, some get READ and UPDATE access, and some get full rights (READ, ADD, UPDATE, and DELETE).

Nothing is free, however, and the improved security in Java 2 is no exception. Expect a performance hit for the new JVM, due to the tighter security, from 10 percent to 30 percent, depending on whose estimate you choose to believe.

The Java Database Connectivity (JDBC) API included in Java 2 (which is now called JDBC 2.0) has several key features. Among them is the ability to have a true cursor when examining a result set. This feature allows you to move forward and backward as well as to modify entries. JDBC 2.0 also supports the SQL3 data types supported by the AS/400’s database: binary large objects (BLOBs), character large objects (CLOBs), and user-defined data types (UDTs). Of course, this new support is available only in the new JDBC drivers. The old JDBC drivers continue to work, however. By the way, IBM’s Java Toolbox for the AS/400 (which is bundled with OS/400) has included a JDBC 2.0 driver since V4R4. For more information on JDBC 2.0, see Don Denoncourt’s article “Test Driving JDBC 2.0

Security

JDBC

with jt400” in the April/May 1999 issue of AS/400 NetJava Expert (Web Edition) at www.midrangecomputing.com/anje/99/04
.

Collections

Java 2 incorporates significantly improved support for collections.

Collections are a vital part of object-oriented programming, as they enable you to address groups of objects without resorting to clumsy array programming. (As an aside, I spent a year trying to use an object-oriented database. The majority of the database code I used was involved in either accessing objects via collections or updating collections with new objects.) Collections are to object-oriented programming what logical files (or views) are to relational database programming. They are vitally important to Java being accepted in the enterprise.

The Java 2 Collections framework provides a clean, standard, interface-based set of classes and methods that are both simple and powerful. The framework also provides a set of sorting algorithms. Figure 1 provides a summary of the collection classes available in Java 2. According to the Java 2 docs, 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.”

The good news with this improved collections support is that you no longer have to “roll your own” when it comes to Collections. The “legacy” collections (Vector and HashTable) have been retrofitted with the interfaces from the Collections framework. The bad news is that you’re actually ahead of Sun in this regard. There are several classes that return Collections, but most classes don’t use the Collections framework. For instance, JDBC does not.

CORBA Support

Also new in Java 2 is a 100% Pure Java Object Request Broker (ORB) that supports interoperability between the Common Object Request Broker Architecture (CORBA) and a Java Runtime Environment (JRE) through Java Interface Definition Language (IDL). CORBA is similar to Remote Method Invocation (RMI) but intended for distributed object applications. Unlike RMI, CORBA works between disparate computing languages and platforms. CORBA support in Java 2 may make developing with Enterprise JavaBeans (EJB) easier, as CORBA is a likely candidate for communication between Java environments and existing application services.

Java 2 also supports an implementation of the OMG/CORBA Object Transaction Service/Java Transaction Service (OTS/JTS) with an alternate Java API on top. This implementation allows a single transaction to comprise actions occurring on multiple virtual machines and multiple databases, including the application server, resource manager, and standalone transactional application. With this architecture, all those actions succeed or fail as a unit.

Earlier Java implementations required a print dialog (interactive), so you couldn’t automate print jobs. Printing in Java 2 now supports an optional print dialog. Located in the java.awt.print package, the main class for printing is PrinterJob, and you must implement the java.awt.print.Printable interface.

Look Forward, Look Back

Sun has pulled off an amazingly AS/400-like feat. Java 2 is fully backward-compatible with all previous versions of Java. No deprecated methods have actually been removed, nor are there any plans to remove them. Even the old 1.0 event model is still supported, so all your old source code should compile and run fine. Of course, your testing bears this out, right?

Printing

The Rule of Three

And so the Rule of Three holds true again. The Rule of Three states that any software product is not ready for “prime time” until the third release. The Java faithful have kept the torch burning through JDK 1.0.1 and JDK 1.1.x, and their faith has been rewarded with Java 2. Go forth and convert the masses!

Reference

“Test Driving JDBC 2.0 with jt400,” Don Denoncourt, AS/400 NetJava Expert (Web Edition), April/May 1999, www.midrangecomputing.com/anje/99/04

Related Materials

• ”At Long Last...JDK 1.2,” Alexander Day Chaffee, Gamelan’s Java Journal Tech Focus, December 2, 1998, www.gamelan.com/journal/techfocus/ 120298_1jkd12rev.html
• ”JDK 1.2: Features and Critiques,” Alexander Day Chaffee, Gamelan’s Java Journal Tech Focus, December 10, 1998, www.gamelan. com/journal/techfocus/ 120998_2jdk12rev.html
• ”Prepare Yourself for What’s New and Different in the Forthcoming JDK 1.2 Release,” John Zukowski, JavaWorld (Web edition), November 1998, www.javaworld.com/ javaworld/jw-11-1998/jw-11-jdk12_p.html

HashSet Holds an unordered set of objects with no duplication ArraySet Similar to HashSet but intended for smaller sets because it has faster creation and iteration than HashSet
ArrayList A dynamically sizable class similar to Java 1.1’s Vector class but unsynchronized
LinkedList A doubly linked list that may provide better performance if insertion and deletion occur frequently
Vector A dynamically sizable, synchronized array. The Vector class has been available since Java 1.0. Sun expects you to use one of the other Collection classes but still supports Vector for backward compatibility.

ArrayMap Intended for small HashTables because it has faster creation and iteration than HashMap
HashMap An unsynchronized HashTable
TreeMap A balanced binary tree implementation of the Map interface.

Unlike HashTable, it imposes ordering on its elements. HashTable Implements a HashTable that maps keys to values. Same as

JDK 1.1. The HashTable class has been available since Java 1.0. Sun expects you to use one of the other collection classes but still supports HashTable for backward compatibility.

Figure 1: The concrete implementations of Java 2’s collection classes give you perhaps too many options for holding groups of objects.