Cool APIs increase Java’s functionality

June 8, 2001— Java just keeps growing in scope and functionality. Time and again, the participants in the Java Community Process (JCP) find new APIs to construct and deliver. In fact, recognition of the JCP played a big part in this year’s JavaOne. At every session, speakers mentioned the Java Specification Request (JSR) that produced the spec, and the list of participants along with their organizations. Sun personnel took the bows, but it was clear that a wide range of organizations contributed to the JCP’s efforts.

In this article, I’ll present three of the coolest APIs discussed at the conference:

• Java Printing Service (JPS)
• Wireless device connections (Bluetooth)
• Remote client launching (Java Web Start)

Java Printing Service (JPS)

Although Java has had printing APIs for a while, they’ve all focused on setting up pages filled with graphics. That’s great if you’re a graphics wizard, but it’s hardly the kind of thing that an ordinary mortal can use. A new package in the JDK 1.4, javax.print, makes it reasonably easy to find a printer and send a document to it.

The API, based on a JSR submitted by Xerox provides methods for finding a printer based on its name, location, or capabilities. It also provides mechanisms for specifying the number of copies, whether a user wants single- or double-sided printing, and paper size. The Java Printing Service features all of the standard international paper sizes, including European A4, US letter, and Asian B5 sizes.

With JPS, data formats are specified using MIME types, for example: image/jpeg, text/plain, and text/html. Even better, the API includes a formatting engine that understands HTML, and an engine that, given a document that implements the Printable or Pageable interface, generates PostScript. The HTML formatting engine looks particularly valuable given the prevalence of XML data storage. You only need to set up an XSLT (eXtensible Stylesheet Language Transformation) stylesheet, use it to convert the XML data to HTML, and send the result to the printer.

Although the API includes a PostScript-formatting engine, it leaves out a PDF format generator. However, given that the APIs are defined, I suspect that PDF output cannot be far behind.

The printing API features a couple of other gaps that make it less than complete for creating commercial products that an independent software vendor would want to produce. For example, the API lacks a print-preview capability, and the ability to specify tray switching during printing.

Tray switching is important when you want to specify that page one prints on letterhead paper, while the rest of the document prints on plain paper. You need print preview, of course, when you want to give users the ability to see how their document will look when printed.

Since the 2D graphics package provides the functionality that a print-preview operation requires, and since tray switching is a fairly simple refinement to the API, it is reasonable to expect that both will be implemented at some point in the future. However, no mention was made of any plans to do so.

Although the glamorous commercial applications still lack some of the functionality they need, the workhorse applications written by the majority of developers can now provide reasonable printing functionality. And that fact makes the Java Printing Service API a welcome addition to Java’s libraries.

Wireless device connections (Bluetooth)

The Java version of the Bluetooth APIs are still at a fairly early stage, but they have important implications for the way we will work and live.

Bluetooth aims at dynamically connecting devices in close physical proximity — within about 30 feet of one another. It was designed to run on extremely inexpensive hardware, with a minute system footprint, so it can be used with PDAs and cell phones as well portable computers and wired devices.

Bluetooth is a platform-agnostic protocol so Java isn’t necessary to make use of it. But the Java version of the Bluetooth APIs will ensure that Java-enabled devices can use it.

With Bluetooth, a keyboard, mouse, or joystick doesn’t have to physically connect to a computer with a cable. That’s nice for a desktop system, but it’s particularly valuable for a portable computer.

Similarly, once you get into your car, the headset will work with your cell phone without having to plug it in. The same kind of headset could work for your TV or radio — whichever happened to be turned on.

In a business meeting, Bluetooth will allow you to create an ad hoc network with everyone present so you can share files and show presentation slides without fiddling with wires. In your office, the same kind of dynamically constructed network will provide virtual docking at your base station to access the printer, log on to the Internet, or synchronize directories.

The specification lead for Bluetooth, Motorola’s C. Bala Kumar, pointed out that such ad hoc networks could also be used for purchasing tickets at a kiosk, checking into a hotel, returning a rental car, or checking into an airline.

In short, the Java Bluetooth APIs promise to make a big difference in the way we move through the world.

Remote client launching (Java Web Start)

Frankly, I was surprised that Java Web Start didn’t win the 2001 JavaWorld Editors’ Choice Award for Most Innovative Java Product. Tomcat 3.2, which did win, was another deserving API. But talk about innovative: Java Web Start gives you the printing and I/O capabilities of an application, with the security-sandbox and deployment ease of an applet, all while taking browser incompatibilities out of the equation. That’s pretty cool all by itself. But at JavaOne, principal architect Rene Schmidt detailed the procedures for using some of the API’s advanced functions.

Schmidt outlined the process for partitioning an app by dividing it into multiple jar files, and associating them with the additional libraries they need. He then showed how to set up the application descriptor file to specify a lazy download of that app’s segment so the user doesn’t have to download the app all at once.

He also pointed out the DownloadService API, which the app can use when a function is invoked. For example, if the help system is invoked, the app can ask the DownloadServiceto retrieve the appropriate jar files before initiating that operation.

If the functionality has already been downloaded, of course, the DownloadServiceis a nonoperation (a noop). But if the jar needs to be retrieved, then a default progress dialog can explain the situation to the user, show a progress bar, and provide an opportunity to cancel the operation. (You could also use your own dialog, but the default dialog makes it easy.)

Schmidt also covered the process for creating jardiff files — jar files that contain an incremental update. He also demonstrated how Java Web Start downloads the appropriate incremental update automatically, depending on the version users currently have installed on their systems.

Schmidt discussed APIs for a variety of other services, including file save, file open, and clipboard access. In keeping with the security sandbox that the app runs in, a warning dialog appears the first time the app attempts to access the clipboard. The operation proceeds only if the user approves the operation. After that, further clipboard access continues without an intrusive dialog. In other words, Java Web Start provides dynamic, user-mediated security controls, without requiring that the user set up policy files to do the job.

Finally, Java Web Start handles downloading and installing whatever VM users need to run the application they have chosen. The bottom line is that Java Web Start combines a convenient and efficient mechanism for distributing powerful applications with the ease of deploying applets.