Welcome Guest. | Log In| Register | Membership Benefits


Hot In '97: Java Too Dependent On Desktop Browsers

Users desire multitasking Virtual Machine
By Andy Patrizio
Issue date: Jan. 6, 1997

The demand for Java programming tools has outpaced JavaSoft's ability to deliver a mature, full-featured programming environment, according to industry observers.

Two significant shortcomings of the programming language were recently identified by Jeffrey Morgenthal, a project m anager with technology research firm D.H. Brown Inc. in Port Chester, N.Y. The first is the lack of a common naming method that will work across all major operating environments. The second is the lack of multitasking within the Java Virtual Machine.

These limitations are problematic to developers creating applications capable of exiting independent of a browser. The shortcomings may become even more of a problem once developers deploy enterprise applications using Java.

"JavaSoft and its partners have been concentrating so much on the browser environment, they're not paying enough attention to the issues when you leave the browser and deploy independent Java applications," says Morgenthal.

Most developers use the URL naming convention for Java applications and applets. But if a program isn't going to run in a browser, using a URL doesn't make a lot of sense. TCP/IP systems use the Network File System's common naming convention, and Novell NetWare supports multiple naming methods found in Windows, Macintosh, and Unix by supporting a 32-bit name space within its file system.

A Windows developer building a Java application could hard-code a file allocation table (FAT) designation in the program, such as C:\..., but if he tried to run that application on a Macintosh or Unix workstation, the program would fail. This means that file access for Windows won't work under the Macintosh without modification.

As more developers build stand-alone Java programs, they will experience the frustration of this limitation. But it could take a year or more before serious development brings on industrial-strength stand-alone applications, Morgenthal says.

Mark Erdrich, a senior software engineer with Alldata Corp., experiments with Java but is not in a situation in which the problems adversely affect development. "We're not on the leading edge. We'll let other people do the bleeding for us," says Erdrich, whose Elk Grove, Calif., company publishes automotive repair informat ion.

Where It Hurts
TriTeal Corp. is one company on the leading edge. It's creating a comprehensive graphical desktop environment for a network computer called SoftNC. "These shortcomings are truly a limitation, but we don't view it as a critical limitation," says Oran Thomas, chief technology officer for the Carlsbad, Calif., company. Java is still maturing and JavaSoft hasn't addressed all critical issues yet, he says.

Once Java applications are widespread, users and system administrators will start bemoaning Java's lack of multiprocessing capabilities. The Java Virtual Machine cannot run two applications at the same time--though it can run one applet with multiple threads.

The difference between applications and applets is that an application begins with a main command in the source code and runs as a process, while applets are run with an init command in the code and as a subprocess to a main process. The Java VM can run one process with many subprocesses, b ut not two processes.

If the Java VM is run on a computer with an operating system, such as Windows or Unix, users can get around this limitation by running each application in a separate VM. Because a VM consumes lots of memory--from 1 to 4 Mbytes of RAM, depending on platform--this scenario could result in sluggish performance.

Network computers are in a different situation. NCs run a single Java VM, which can be limiting. "What good is a JavaOS that can only run one application at a time?" asks Morgenthal. "As more people get away from the browser and enter into the realm of sophisticated desktop applications, they might want to run two or more applications simultaneously."

Applet Band-Aid
TriTeal suggests that applications be written as an applet. That's how it is handling the problem for SoftNC, which is written as an application while all supporting programs are written as applets. But that's not a complete solution. An NC running SoftNC won't be able to r un Corel Office for Java, for example. For the file system issue, TriTeal does all file access through the HTTP and URL protocols.

NetDynamics Inc. came up with a workaround for the Java VM limitation. The company added middleware to its database-to-Web server bridge that acts like a task scheduler. Zack Rinat, CEO of NetDynamics in Menlo Park, Calif., maintains that adding the extra layer to manage multiple queries was not that difficult. "I believe Java is ready for prime time on the server, and the applications that we have are a good indication of this," he says.

Other Java developers say file naming and single-tasking are not overwhelming problems. "We've been doing a lot of Java development, and I don't think we've run into many problems," says David Greenberg, manager of technical services for ObjectTech Corp., a Parsippany, N.J., developer of client-server and Internet applications. Though shortcomings are a nuisance, Greenberg feels it's just a matter of time before JavaS oft deals with them. "Java is only a year-and-a-half old, as opposed to C++, which took 10 years to evolve," he says.

The issues raised by Morgenthal's report "are not issues our customers are bringing to us," says David Spenhoff, director of product marketing at JavaSoft, in Cupertino, Calif. "But I can assure you that if it does become an issue, we will take steps to resolve it."

Ear To The Ground
When pressed, Spenhoff would not divulge specifics on file system or a multiprocessing VM, partly because JavaSoft hasn't done any design for that technology yet. But if customers demand it, JavaSoft will provide a fix, he insists.

"These are not architectural issues, they're simply features," says Spenhoff. "I assume it would be relatively easy to add."

Playing the devil's advocate, Microsoft says developers have let their expectations get ahead of Java. "People assume Java is this totally cross-platform environment," says Charles Fitzgerald, program manager for the Internet platform and tools divisions at Microsoft. "The reality is, every operating system works differently. It's one thing to talk about delivering an identical experience everywhere, but all computers are not the same."

The two limitations are having no effect on Microsoft's development efforts, Fitzgerald says. Moreover, he expects they will be fixed in due course.

"People aren't building a lot of big Java applications yet," he adds. Developers are not very far along on the learning curve."

Return to Hot In '97 Menu

Comments?

http://www.informationweek.com