Launching into Java

A long time ago, Java programmers were promised something like “class loaders that load resources from the Internet.” Today, we still can’t add the network to our classpath and access our bank accounts through a bank’s custom Java application. We expected Java to work out of the box. Now we are wiser, and know that distributed and local systems are different beasts entirely, and not special cases of each other. Running an application “off the network” has significant design and implementation considerations.

First, you need a secure environment where you can be sure that the application will not steal your data. Second, with the horrible response times of the network in comparison to a local filesystem, you want those resources cached locally and updated only when necessary. You also don’t want an entire application to download at once, because applications can get really big. You want the application’s features to download on demand, when you actually start using them. For example, when using a CAD studio, why download the heavyweight 3D design tools if you are working in 2D?

Sounds like a lot to ask from Java? Well, the pieces are all in the Java specification: a generic class-loading system, a built-in security architecture, access to the Internet, and access to your hard drive. So enough with the excuses! A number of solutions are here, now, and work (more or less) beautifully. They’re ready for you to use in your next Java application.

Um, what about applets?

Java applets are bad news, and have always been bad news. They were a hack that awkwardly solved a temporary problem with Web client dynamics, a problem that has since been more elegantly solved by DHTML scripting in its countless variations. Applet aficionados claim that applets can do anything that full-fledged Java applications can do — you can open Swing windows and access CORBA objects with them, for instance. While that’s true, there’s still a huge browser running in the background while you run an applet, and if the user closes it or moves to another Webpage, then the application is shut down. Worse, such applet/application hybrids are very limited in size — you end up waiting five minutes for a CAD/CAM “applet” to download its 20 MB jar file to your hard disk.

It is somewhat ludicrous that today’s Web browsers contain at least two virtual machines: one for Java, and one for the DOM scripting engine. Since when was it the browser’s business to run code anyway? I want my browser lean and mean and good at showing nice downward-scrolling pages with text and graphics. That’s what HTML was created for, and that’s what it does very well. It was not designed for database query, drag and drop, electronic wallets, or CAD/CAM. We have other, specialized environments for those applications.

What about servlets and EJBs?

With the advent of servlets, Java has found a happier place to live: on the server. There it can generate nice Webpages with text and graphics for your browser to display, and for you to scroll and view. The dynamic duo of server-side Java and HTML is ideal for on-screen report applications. Java loves getting the data and generating HTML, and your browser loves showing it to you. There are plenty of applications that fit this niche. However, there are many that do not. Just by adding the requirement of printing to reports, you are stretching that technology to its limit, because HTML is simply not good on paper. Still, as long as you just need to see reports generated on-screen, you can program them happily in Java on the Web server.

It is important to note that while server-side Java is nifty, it’s not all that special. There are, in fact, a plethora of languages, scripts, and engines that can gather data and publish it in HTML, and they existed before Java was even invented. Java has a lot to offer on the server, but it’s hardly an innovation. Java is more innovative at the local level: on your desktop computer. But wait: does Java really have a place on the client?

Nobody likes Java applications

Any machine that can run Java can run applications written in Java. Say that sentence aloud a few times and it’ll begin to make sense. Yes, it means that you only need to write your application once, and it can run anywhere. Sound familiar?

The problem, as we say in the military, is that can does not mean will. As far as the user is concerned, Java means slow and weird. It’s sluggish, eats up memory like there’s no tomorrow, and looks and behaves … well … kinda funny; not exactly like a native application, even with a native Swing look-and-feel. As a seasoned software user myself, I am disappointed when applications are only available in Java. Why couldn’t the designers have put in more effort and coded a real application? If multiplatform support is such an important goal, they should have huffed and puffed and designed native applications for every platform they want to support. The only case in which I would be happy to run Java is if I were running an obscure platform that happened to be Java enabled. In that case, I’d be happy if I got anything to run on my machine. But that case is rare. In general, native applications are always preferable for the user. Java saves developers time and money, but the user ends up paying for it by running inferior applications.

So, should Java stick to the server side? Absolutely not! There are good reasons why a user would want to run a Java application. Let’s review two key features of the Java Virtual Machine (JVM):

1. It is really safe. Once you have a security manager installed, the JVM can implement a “sandbox” where the Java code can play and scream all it wants, and you can rest assured that it hasn’t sent love letters using your email account or bought a car on your credit card.
2. It runs on many operating systems. Really, it does. Well, quite a few, anyway. Not all JVMs support the latest version of Java, but they eventually will. Well, maybe they will.

Now, what are two key features of Web browsers? Still thinking? You can stop now. They are the same two features mentioned above. This is not a fluke. It’s why Java applets were allowed into Web browsers in the first place, because they share a certain vision: browsers and Java, Java and browsers. Anybody can run them without fear.

And so we finally reach the place where Java truly shines, and where it really is an important innovation. You will want to run Java applications from the Internet, and will even prefer them over native applications, because Java is safe.

So here is the vision: Instead of clunky Web applications, service providers will design full-blown Java applications with multiple windows, drag and drop, printing and database-query capabilities, directory access, message queuing, and whatnot. Users will point their launchers (not their Web browsers!) at a URL and their service provider’s application will run on their desktop. It’s as easy as browsing the Web, and much sexier than those old downward-scrolling pages. We will laugh in disbelief at how our forefathers had to access their bank accounts, buy books, or read their mail over the Web. It’s high time to get the applications out of the Web and onto the desktop. This is more than a mere implementation of Java. It is, I believe, the only way Java has a chance of surviving as a viable client development platform.

3 … 2 … 1 … Launch!

And now that we’ve come full circle, let’s see how we can launch into Java right now with a description of some technologies that can help you take off.

Java Web Start, by Sun Microsystems

Java Web Start is currently an early access version 0.4, and while it is promising, at this stage it still lacks critical features:

• It requires the Java 2 Platform, Standard Edition, which shuts out anyone still running JDK 1.1. For example, anyone with Microsoft’s JVM (which is anyone with Microsoft Internet Explorer — and is thus the typical Internet user, or so we are told) will have to install Sun’s JRE to use Java Web Start. Worse, Macintosh users do not have any J2SE support available, excepting those brave souls who are testing the Mac OS X Public Beta.
• As its name makes clear, Java Web Start is Web based, meaning that the application is published to a standard HTTP Website. That makes it easy to use and Internet friendly, but difficult for corporate intranets which have to use more manageable and secure object-oriented infrastructures, such as CORBA, and manage their networks using directory services.
• It has no real on-demand downloading scheme. Jar files are either eager, which means that they must be downloaded before the application can start, or lazy, which means that they can be downloaded later. What later means in this context is unclear, because there is no information about what those jar files contain. The first time the application needs a resource, it must download all the lazy jar files. Essentially, that divides the application into a maximum of two features. This is unacceptable for large applications, which may have many features, and so it limits Java Web Start applications to applet-sized applications.
• Its security sandbox is ported directly from the applet world. It seems that Sun’s programmers used code from a secure applet viewer — perhaps the HotJava browser. Do you remember what that means? Signed jar files gain free reign on your system unless you disable certain capabilities. It’s a license-based security scheme that is ill suited for the many things applications may need to do to your system. That has been alleviated somewhat by a service scheme that allows the application access to certain protected services, such as file selection dialog boxes. It is unclear at this point which applications gain access to those services and which do not.
• Finally, Java Web Start is proprietary software, and requires licensing from Sun Microsystems to integrate in your product.

To conclude: At its current stage, Sun’s solution is a move in the right direction. You should, however, be cautious about embracing it right away, especially if you are deploying a large-scale application. Java Web Start is still at an early stage of development, and may (and should) change dramatically.

Java URL and the Safe Network Launcher, by yours truly

I started the free Java URL project more than a year ago. At the time, Java Web Start was nowhere in sight; thus, with the Java URL, I attempted to create my own standard: Java Transfer Protocol (JTP). Once Java Web Start was revealed, I saw little benefit in multiple standards, and so quickly redesigned Java URL for compliance with the Java Network Launch Protocol (JNLP). JNLP, produced through Sun’s Java Community Process, is an open specification that you can use to design your own client to launch applications.

Without getting into too many details, JNLP consists of an XML file on a Web server that describes resources required by an application and locations where those resources can be found. For now, I have extended JNLP to support the JTP features it didn’t have. Those features were necessary to support the functionality that Java Web Start lacks. Those extensions are not required, however, and the Safe Network Launcher (Java URL’s client) happily launches standard JNLP applications.

Java URL is more ambitious than Sun’s Java Web Start:

• The Safe Network Launcher does not rely on Java 2 Platform features. It has already been tested on Microsoft’s JVM and even the Personal Java platform. Of course, it can only launch applications that were designed for the JVM being run. Still, service providers can design a single application that can be launched with Microsoft’s JVM, Apple’s MRJ, and on Personal Java.
• The architecture is open and extensible. The JNLP file is a special case of a Java URL catalog that can be implemented without JNLP. For example, it may read the application’s structure and requirements from a database or a source control system, or autogenerate it from an application’s class files. Likewise, a custom loader can be created for getting a resource through a protocol more secure than our old friend and enemy, HTTP. You can also implement a cache for specialized storage that is not a filesystem, such as specialized flash memory or a local database.
• Java URL specifies on-demand downloading. JNLP has been extended to allow an unlimited number of features per application, not just two. Your application can be as large as you need it to be. In fact, it can be an entire suite of subapplications that are downloaded as the user needs them. As noted, Java Web Start can only divide an application into an eager and a lazy feature.
• The Safe Network Launcher has a custom implementation of the security sandbox that uses a very simple security scheme: Whenever an application tries something intrusive, such as reading from or writing to a file, opening a network socket, or printing, a dialog box will appear that explains the activity and asks the user to allow or forbid it. The decision can be stored in the cache for future attempts of the same kind by the application. For example, if the application tries to read a file, the user can let it read any files from that directory. The user can allow the application to print a certain job, and may deny a future, unexpected print job. Currently, Java URL disregards licensing completely. Within a safe intranet, the Safe Network Launcher can run in permissive mode, in which the sandbox is disabled.
• Java URL is licensed under the GNU General Public License, like Linux, Emacs, and GCC. All source code is available, and modifications must be distributed under the same license. If users and programmers embrace it, Java URL will surely benefit from considerable enhancements, most likely in the number of protocols and technologies it supports.

The bottom line is: Java URL works, can launch JNLP, and is free. You can download the Safe Network Launcher and all its source code right now. You can tinker with it to fulfill your special requirements, such as launching over CORBA, loading from a relational database, or caching to a cellular phone’s flash memory. You can also integrate it with your custom client environment and not pay any licensing fees.

Conclusion

There is little desire or need to design Web applications that are not on-screen report applications. You can develop your application in Java and enjoy all the benefits of Web applications: user trust, zero deployment, straightforward upgrading, and accessibility to many devices, from set-top boxes to cellular phones. With Java URL and Java Web Start, you can do all this right now. Will the transition be painful? Hardly. On your homepage, mention that a Java version of your application is available, and hail its benefits. Include a link to download either the Safe Network Launcher or Java Web Start. Instead of browsing to http://www.mycoolservice.com, users will launch http://java.mycoolservice.com — and they will never want to use Web applications again.