Will Java fulfill its original mission? Simon Phipps, Sun’s chief technology evangelist, likens Java to a baby duck. “When Java technology was born, it looked around, saw a Web browser and thought it was an applet,” he jokes. His point: Java was miscast as a mobile and portable GUI. Its real mission in life was to become a platform for network services. I thought so too, from the moment I created my first servlet five years ago. I said then: “It’s a peculiar moment in our industry’s history. The Java buzz is intense. And yet when you look at the Web applications that people actually use every day to do their work, you invariably find that there are no Java applets in the mix. The universal client today is still the HTML browser. The universal client of tomorrow will be the HTML/JavaScript browser. Client-side Java is a glorious vision that will not change the way most people use the Internet anytime soon. Why not? It’s just more than what the majority of today’s computers and networks can readily push. So what are millions of people running every day? Server-based applications that feed the universal HTML client.” [1] That was a contrary thing to say in 1997. It also turned out to be a pretty good prediction. So here’s another contrary prediction: Now that we’ve all written off client-side Java, it may yet prosper. If this were a Gartner report, I would add something like “probability 0.634” — in other words, I’m not as sure now that Java will fulfill its original mission as I was then that it would prevail on the server. But here are some points to consider. * Surplus CPU cycles. With ridiculous power to burn on the desktop, it’s a lot easier to push layers of Java, including Swing, than it used to be. * More bandwidth. Our pipes aren’t as much fatter as our CPUs are faster, but at the edges of IT-controlled environments dialup is mostly a bad memory. * Java Web Start. Blurring the distinction between an on-the-fly applet and an installed Java application was a great (and long overdue) idea. It’s even possible, using “download=’lazy'” in the JNLP (Java Network Launching Protocol) file, to “trickle-feed” classes to the client. (A similar technique can be used for WinForms apps in .Net, by the way). * SWT. As we noted in a story on Eclipse [2], the Standard Widget Toolkit is seen by some in the Java community as a promising way to preserve the OS-native look and feel of Java more efficiently than Swing can do. * Java GUI remoting. Despite important advantages, Java Web Start can’t reproduce the lightness of the HTML/JavaScript browser. But there are lots of ways to skin a cat. IBM’s alphaWorks project offers a GUI remoting library called Remote Abstract Window Toolkit [3], originally for AWT and then more recently updated for Swing. A couple of years ago, the folks at VistaSource showed me Anyware Office, based on the Applixware productivity suite for Linux. For Anyware Office, VistaSource built a lightweight Java GUI renderer that connected, X-Windows-style, to a GUI server and to the guts of the Applixware suite. VistaSource has since focused elsewhere (on real-time data analysis engines), but now smart-client vendor Droplets is aggressively pursuing the concept. I spoke with Droplets’ CEO Philip Brittan last week and asked him how the company’s strategy compares with approach taken by some other vendors such as Altio and Digital Harbor, who ship high-level XML descriptions to a Java-based client-side renderer. With Droplets, Brittan explained, the developer leverages the normal GUI construction machinery in, for example, Borland JBuilder. The thin-client effect is achieved by writing not to AWT or Swing, but to alternate Droplets libraries that are “almost like” them and that enable the application’s face to be peeled off and to run remotely. The phrase “almost like AWT or Swing” is, of course, a red flag. But Brittan responds in an intriguing way. Droplets has joined the team working on JSR (Java Specification Request) 127 [4], aka “JavaServer Faces.” This project is chartered to rope together various initiatives — ranging from Struts to XForms — into a standard component framework for creating user interfaces in the servlet/JSP arena. According to Brittan, that charter may now expand to encompass a Droplets-style Java face as well as a conventional HTML/JavaScript face. Sounds like a great idea. Despite all these fascinating arguments, I’m not quite ready to reverse my skepticism about client-side Java. But just because it was the wrong thing in 1997 doesn’t mean it’s the wrong thing forever. 1. https://www.byte.com/art/9706/sec8/art1.htm 2. /articles/pl/xml/02/06/17/020617pleclipse.xml 3. https://www.alphaworks.ibm.com/tech/remoteawtforjava 4. https://www.jcp.org/jsr/detail/127.jsp Software Development