Deprecated: mysql() [function.mysql]: This function is deprecated; use mysql_query() instead in /usr/home/taubler/www/htdocs/articles/inc.php on line 153

Deprecated: mysql() [function.mysql]: This function is deprecated; use mysql_query() instead in /usr/home/taubler/www/htdocs/articles/inc.php on line 171
Java Swings Well with Hybrid Web/Desktop Applications
Articles index









Deprecated: Function split() is deprecated in /usr/home/taubler/www/htdocs/articles/article.php on line 128

Java Swings Well with Hybrid Web/Desktop Applications

Last updated: 2007-09-05

These days, Web 2.0 trends such as AJAX can be considered a success, perhaps not so much from a technical sense (there are, after all, numerous competing—and dare I say buggy?—frameworks and toolkits being developed, best practices being formed, etc) but from the standpoint that they are here to stay. It would be hard to imagine next week, next month, or next year the collective online community deciding "Hey, you know that asynchronous stuff we've been developing? Where users don't need to refresh entire pages just to submit a little data, or retrieve a tiny bit of information? That was dumb. Let's go back to the one-full-page-per-request model."

That being said, it's about time for the Web world to find its newest fads and trends. One likely candidate is the concept of Web/desktop bybrid applications. Such apps would be deployed over the Web (updates to the app would similarly be deployed.) But once it was loaded onto the user's computer, it could be run without relying on the network (assuming the purpose of the application wasn't entirely network driven.) Such applications would also tend to have functionality that is nearly as rich and feature-packed as traditional desktop applications. There are all sorts of ideas about the best technologies to address this perceived need. Java is ideally suited to be such a technology. In addition to Java applets and standard desktop applications, Swing-based Java applications can be deployed via Java Web Start. This technology allows users to launch a fat, feature-rich application merely by clicking on a link in a Web page. Updates are handled behind-the-scenes, invisibly to the user. And the user can subsequently launch the application even if the computer is not networked.

The (re)birth of an idea

I attended O'Reilly's Web 2.0 Expo at Moscone Center in mid-April 2007. Many topics abounded in this conference, but one in particular, Bringing Applications from the Web Browser to the Desktop (to quote the title of one particular talk) caught my attention. I attended the aforementioned talk, and found the speaker discussing Adobe's Apollo project (now called AIR). According to the speaker, you could use Adobe Flex to create an application that went beyond standard HTML stuff—we're talking custom widgets, remote procedure calls, and more—and allow the user to deploy it to their desktop. Who cares what browser they were using, or whether they're on a Mac or a PC? It would work either way!

Perhaps I was the only Java developer in the room, and perhaps I was alone in my particular point of view. But I couldn't help wondering, don't we already know how to do this?

Still eager to explore, I attended a BOF session given by members of the the Artemis Project. This project attracted my attention because its purpose is to meld Flash with Java, allowing a developer to, say, write a desktop application with a Flash UI and a Java backend.

The BOF sessions leaders first asked the small group of attendees to go around and introduce itself. Not so surprisingly, I was the only Java developer. Next, one of the session leaders asked us to come up with reasons why someone might want to write an application with a Flash frontend and a Java backend. It quickly became clear to me that I misunderstood the question. While the speaker was asking why one might desire a Java backend on a Flash application, I was wondering why I would want to attach a Flash UI on my Java application. It wasn't hard for the group to find answers to the intended question. So I then asked my version of the question.

"Why would you need the Flash part in the first place?"

There was a bit of a pause, and an ever-so-slightly confused look on the speaker's face. "Well, writing UIs in Java is hard. Have you ever actually tried doing it?"

"Well, yeah," I replied. "I do it all the time. It's actually pretty fun."

Someone in the group gave a little laugh. "I read about this thing called a GridBagLayout that you use to lay out UIs in Java. It looks hard."

"Well, then, you don't have to use it," I replied. "There are plenty of other layout managers. But it's pretty powerful when you need to get a tricky layout to work." At that point, I realized I was in serious danger of monopolizing and digressing the conversation—and besides, I was there to learn and not evangelize—so I shut up.

A quick sidebar

I should probably take a quick timeout to explain a few things. First, I'm not here at all to bash Flash, Flex, or AIR. I'm a huge fan of Adobe's (and was of Macromedia's, back when such a beast existed on its own). And Flash has gotten people thinking anew about rich internet applications. My perspective is that there are plenty of people out there developing Flash applications; the world probably doesn't need another one in me. Java has always interested me more because when it comes to the argument of more powerful versus easier (okay, I'll concede, easier often equals more productive), my interest lies in the more powerful camp. And that being said, Flex seems to be quite a departure from "traditional" Flash development, seeming more—dare I say it?—Java-like. So I've been playing around with it.

But let's be honest; Flash doesn't really need more promotion. Attending the Web 2.0 Expo certainly demonstrated that to me. Instead, I'm simply pointing out that Java and Swing are at least as viable—and probably more so—as technologies for the Web/desktop hybrid application model.

Okay, I have a confession. I already had an answer to my own question. Primarily, it's deployment. When comparing apples to apples on those computers—say, a Java applet to a comparable Flash movie—the Flash experience tends to be a little better. Flash movies start almost right away; at the very least, a custom "splash screen" of sorts can display first as the rest of the movie loads. Historically, Java applets have been slower to load; the entire applet and all of its classes and resources must be loaded—and the entire JVM started, as well—before any custom functionality can kick in.

The difference is even more pronounced for those computers that don't have Java or Flash preinstalled. The Flash plugin download is much smaller and faster than the Java Runtime Environment (JRE) download, which is required for applet display within a browser. The reason, of course, is that the JRE's functionality extends well beyond the browser. But when a user cares only about a small interactive browser component, that reason is irrelevant.

That all being said, the differences between the two are are relatively small, and have been getting much smaller. Still, developers sometimes shy away from using Java for rich internet applications. So... what might be some of the other reasons?

Why does Java give people the jitters?

Front-runner burn-out

Part of the answer to that question comes from the history of Java. Java applets represented perhaps the earliest form of rich internet application, at least as we know them today (remember Future Splash? That's the name of a product that was eventually renamed to Flash, and it began its life as a Java applet). And as such, they suffered somewhat. First, Java was originally not developed to serve the purpose of an RIA, but rather, as a language for controlling set-to boxes. Its development coincided with the growth of the Internet and Web, and so it was retrofitted with an API and runtime that allowed it to run within a Web browser. While fairly revolutionary at the time, Java applets weren't designed from the outset to provide the best user experience. Users put up with its limitations because, probably, they simply didn't know better. Apparently content with the rate of adoption for Java applets, Sun did little to improve the applet experience.

Sun could have learned from its earlier mistakes, but instead, it seems that others—notably, of course, Macromedia—paid more attention. Granted, the Java platform extends far beyond mere mini-applications that run within the browser, so focusing on applets might not have seemed like a high priority. However, the user experience—and the user perception—of Java applets suffered in the process. And because in the minds of many people at the time, users and programmers alike, Java == applets, the perception of Java as a whole began to suffer. The Java applet technology has improved dramatically over the years, and continues to do so, but its reputation has stuck.

Marketing

Here's a statement that might come as a sarcastic shock to you: Sun Microsystems is not good at marketing. Here's another: Adobe is. While I don't suggest at all that Adobe is all-fluff-and-no-stuff (again, you're talking to an Adobe user and fan here), their marketing clout has furthered the acceptance of Flash and its related technologies. Meanwhile, Sun puts out the occasional lame attempt to promote Java (Über-coder, anyone?) And it kind of makes sense. Adobe (and, previously, Macromedia) would benefit whenever its marketing efforts would convince someone to use its tools. It's worth their money to hire spokespeople like Bruce Eckell to say that they love Adobe's products. Sun... well, I'm not sure anyone—Sun included—is quite certain how acceptance of Java directly translates to its bottom line.

Alright, then why use Java for this new Web/desktop hybrid trend?

The above points notwithstanding, my answer to Why use Java for Web/desktop hybrid applications? is an emphatic Why on Earth not? Many of the issues facing Java GUI applications are ones of perception; or rather, misperception. The remainder, particularly those surrounding deployment, are being addressed. First off, much to Microsoft's distaste, many Windows-based PC vendors are shipping with Java pre-installed. All Macintoshes already do. And with Java's being open-sourced as of late, many Linux distributions will now include Java. So even more systems will be shipping with Java to begin with.

Easier deployment

But there will still be those without Java pre-installed. For those, the deployment process will be dramatically improved through a number of steps being taken my Sun. Many of these steps are addressed in articles such as sun.com's Consumer JRE: Leaner, Meaner Java Technology, but I'll summarize them here. First, the installer itself will be more streamlined, much easier to use, and less "scary". Updates will be done via "patch-in-place", meaning that users won't find their machines littered with various JREs (of course, the likes of us developers can still install multiple JRE versions should we choose to.)

The Java Deployment Toolkit will also simplify the detection and (if necessary) deployment of a suitable JRE. Up until now, the options for detecting if a user had a suitable JRE were rather limited. Furthermore, if an applet user needed to install one, they had to venture over to java.com, install Java, and then return to your site to continue. The Deployment Toolkit, on the other hand, provides a cross-platform and cross-browser approach to automatically detect the user's JRE level, install an appropriate version if necessary, and continue with the loading of the applet.

Okay, what if the user is not on a browser? For those cases, Sun will distribute a getjava.exe program. This utility, intended to be used as part of a native Windows installer, will allow for the detection and (if needed) installation of a suitable JRE. Its use will look something like this:

getjava -version 1.6+
If Java 6 is installed on the system, getjava will return 0. If not, it will install Java 6 (or higher) and then return 0.
getjava -detect -version 1.5.0_11
Will return 0 if the desired version is present on the user's system, or some other error code if not.

Faster deployment

For those times when a download is needed, it will be much smaller than it previously had been. Java is of course a powerful platform, and is thus rather large in size. And it will only get larger. However, few programs use most of Java's built-in APIs. This currently causes many programs to endure an unneccessarily long download time (small programs are hit especially hard.) The solution is to modularize the kernel. Initially, only the core part of the kernel—that required for a simple Hello World application—will be downloaded. The remaining components will be downloaded on demand, or lazily loaded. Of course, once a component is downloaded, it will not need to be downloaded again. Eventually, all parts will be loaded and installed. Developers worried about their users experiencing pauses will be provided a mechanism to specify components that must be present before the application starts.

Perky start-up speeds

Systems that already contain a suitable JRE will still benefit greatly from upcoming changes in the Java platform. This is particularly true in the area of application startup time. There are two types of Java application startup: Cold Starts (when the JRE is not yet in memory) and Warm Starts (when the JRE is in memory). Warm starts are neraly instantaneous at this point; cold starts, however, add on the necessary disk reads to load the JRE, and thus still tend to be slow. The solution (at present, only for Windows machines) will simply be a service that touches the JRE files to force Windows to keep them in disk cache. Thus, all Java application launches will effectively be warm start. Such a service will be automatically disabled on resource-constrained machines.

But isn't Java "hard to use"?

Java is about as hard as it needs to be. When compared to traditional Flash development, for example, Java development certainly more difficult. However, Flash has traditionally been far, far less powerful than Java; using a WYSIWYG development environment can only get you so much. Still, Flash—and particular Flex—has made strides in that aspect. ActionScript (Flash's scripting/programming language), in particular, has radically changed. One need only take a look at the Flex developer guide to see that. Actually... let's take a look at some of it now. The ActionScript 3.0 Overview page lists among the new features Runtime exceptions, Runtime types, and Sealed classes. Package namespacing and interfaces have also been added. Hmm; this all sounds oddly familiar. Some might consider these, and the many other changes to ActionScript, as making it harder to use Flash/Flex. Others, like me, recognize them as invaluable to building large-scale applications.

Many people will point to Flex's declarative style of UI construction as being easier than creating UIs within Java code. Flex uses XML to define interfaces, similar to using HTML. For example, a simple interface might be laid out like so:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<mx:Panel title="My Application" width="200" height="300">
		<mx:Label text="Welcome to Flex!" mouseDownEffect="WipeRight" />
	</mx:Panel>
</mx:Application>
Whether or not such an approach is "easy" or not is in the eye of the developer. But those favoring a declarative approach will find one in Java FXScript. An example of declaratively creating a UI with FXScript might be:
import javafx.ui.*;

Frame {
	title: "Hello World JavaFX"
	width: 200
	height: 50
	content: Button {
		text: "Press me!"
		action: operation() {
			MessageDialog {
				title: "You pressed me"
				message: "Hey, don't do that!"
				visible: true
			}
		}
	}
	visible: true
}

Different developers might be able to nitpick various pros and cons to each approach. But a dramatic difference in ease of use? I just don't see it!

Beyond all of that

Clearly, there are plenty of reasons why Java isn't a bad choice for developing hybrid Web/desktop applications. But what makes it a good—nay, great—choice? The first answer should be obvious. Java has a huge, HUGE number of libraries to cover nearly every need that's out there. Advanced 2D and 3D graphics are second-nature to Java. Networking/RMI. Advanced I/O. Security and cryptography. Persistence. XML. Countless frameworks to cover nearly any need. Other environments could, of course, someday contain similar libraries, but Java has a giant head start there.

Then there's tooling. Most Java developers are aware of the plethora of IDEs out there—Eclipse, NetBeans, IntelliJ IDEA, etc—to make life dramatically more productive and fun for Java developers. GUIs can be designed in WYSIWYG fashion, for example, with NetBeans' GUI builder and Matisse, its companion layout manager. Performance issues can be addressed with the profiling tools that ship with the various IDEs. Internationalization becomes dirt simple. The list of benefits associated with the various IDEs is huge.

And how about scripting languages? Clearly, building large-scale application greatly benefits from a strongly-typed object-oriented language like Java (or, for that matter the new ActionScript). But smaller applications—or smaller portions of an overall, larger application—might benefit from a scripting language. Well, keep in mind that Java is far more than just a programming language; it's an entire platform. And it's a platform that's capable of running other languages than just, well, Java. Want to write a portion of your application in Ruby? Use the Java platform and the JRuby implementation. Need to do a lot of parallel programming in your application? Implement some of it in Scala. Various sites like this one list some of the more popular scripting languages that can be used within the Java runtime, but in reality there are well over a hundred.

Oh, by the way... it's already being done!

Finally, Java technology already exists—and has existed for some time—to create rich applications on the desktop, within the browser, and in between. Above, we discussed Java applets that run within the context of a Web browser. Java applications can also be easily deployed and run as traditional desktop applications. A lesser known technology, but one entirely relevant to this discussion, is Java Web Start. This technology allows Java Swing-based applications to be deployed and updated via the Web, while installing as a standard application on the user's computer and running like a normal desktop application.

So those of us who develop Swing applications have numerous deployment options. And the apps that we deploy go way beyond standard HTML stuff—we're talking custom widgets, remote procedure calls, and more. And who cares what browser they were using, or whether they're on a Mac or a PC (or Linux, Solaris, or nearly any other operating system)? They'll run anywahere!

Hmm... now why does that sounds familiar?





Privacy Policy: Any information collected, whether from online help, registration, or any other means, will be used only for support purposes. Such uses are: to send customers registration information, to verify that a user is registered in order to provide support, and to notify the user if an important or useful bug fix or upgrade has been made. Under no circumstances will customer information be sold or otherwise given to any other party, person, or organization. We're in the business to develop software, not sell people's information.