Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Launching into Java

New client-side technologies bring Java apps out of the Web and onto the desktop

By Tal Liron, JavaWorld.com, 09/15/00

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.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.