Related Web Works

[Microsoft] [ActiveX] The Power of the PC. The opportunity of the Internet. ActiveX brings new opportunities for developers.

How can Java rule the world?

Three key steps to Java's success

Summary Can Java rule the world? Yes. But if it expects to be more than just another programming language for clients, it needs to provide a better environment for building database and server applications. (1,500 words)

By William Blundon

The rumbling sound heard across the planet is not a sudden rash of earthquakes, but the mad rush of a million pairs of feet scrambling to bookstores to buy the latest tome on Java. As the Java Gold Rush accelerates, GreenPeace estimates global deforestation will increase by 25 percent this year alone, as paper mills worldwide try to keep up with the demand.

Being a Java programmer is way cool. Experienced C++ programmers (at least those who consider Java a viable alternative) suddenly are in the limelight and smiling broadly. "You see," they say, "we were right all along. Just a little ahead of our time. Consulting contract? Hey, man, talk to my agent." No longer perceived as the hirsute hackers of the computer set, they are magically transformed into Internet Royalty.

The hype machine works 24 hours a day. Java is everywhere. Java is everything, Java rules! Bill Gates has retreated to a bunker in Seattle. It's all over for Microsoft. The boys and girls from JavaSoft are off to do their start-up. Venture capitalists are throwing checks at them like teenage boys lobbing room keys at Madonna.

What's going on here? And when?

Some basic facts Java is a programming language. People use it to write programs that run in a client/server configuration and over remote networks. Java code also can run within a virtual machine in a browser. Nearly all the programs written in Java today are applets, small programs designed to perform simple functions. All the Java code in the world would probably fit on one CD-ROM. (All right, maybe two.)

So far, Java is a programming language primarily for clients; server support is weak. The best Java development tools are currently found in press releases. Existing Java compilers produce executables that run ten times slower than equivalent C or C++ code. Downloading Java applets over the Internet to a remote client is just as slow as downloading a GIF image; for executables over 30 or 40 kilobytes, it can be painful.

What's needed? Currently, developers typically employ Java to animate logos, sketch cute cartoon characters, and emulate stock tickers from static data. People are writing simple applets, that's about it. True, there are some brave souls trying to write full-fledged applications software for client/server environments. Nearly every software company in the world is trying (or claiming) to develop a Java product of some sort. But the market remains in its early-adopter phase.

Today's reality is that most developers are making hard trade-offs about where to use Java and where to use another language, especially C++. Many developers are designing applications that use Java to manage all or portions of their user interface, and C++ code where performance is critical. The belief is that an intelligently designed program, with components written in C++, can be rewritten (or translated) to Java when compiler performance improves.

This is a logical assumption, but it comes with a few warning flags. As a new language, Java has weak links to legacy systems. C++, on the other hand, has ten years of C and C++ development behind it. While the commercial market for C++ class libraries is not robust, it is easy to find code, code fragments, and class libraries within a corporation or in the public domain. Java can employ a C interface library to talk to legacy applications, but the existing code base is small. Similarly, some of Java's strengths create some new challenges. For example, while Java eliminates the need to understand the complexities of pointers, it has created a nearly equal need to understand and manage threads.

Can Java rule the world? Possibly, maybe even probably. Java's widespread use requires that the Java community address the following three issues as quickly as possible.

Issue 1: Application development environments There is an old joke in the Unix community: Unix documentation is written for people who already know the answers. In a similar vein, Java is very easy to use -- if you're an accomplished C++ programmer. Let's face it, Java is not exactly a 4GL.

In theory, developing in Java can be faster than C++ because it is much closer to an interpreted environment with class-level compiling and resolution of dependencies at runtime. The language is more accessible to developers than C++ because it eliminates the need to develop a specific pointer-based memory management scheme. Early indications show that accomplished C++ programmers can be two to three times more productive writing Java. However, the vast majority of people developing software are not C++ programmers.

As the revolution continues, vendors must provide a new set of development tools to make Java accessible to mainstream programmers who are willing to develop serious Internet or Intranet applications. Today, these mainstream developers write forms-based and database-centric applications in Visual Basic or some other 4GL. Connectivity to their information repository is very important. New tools must come to market quickly, tools that can rapidly make these developers more productive. The tools must be visual and easy to use, and hide the complexity of Java as much as possible.

Issue 2: Server support Java already has the essence of a good client environment. Communication between clients and servers, however, is still primitive and remains limited to pipes, sockets, and file I/O. Java needs a clean, higher-level interface to databases and servers, like ODBC and OLE, to access persistent data. SunSoft offers one solution, a downloadable API for JDBC, a Java variant of ODBC. Meanwhile, Microsoft has announced the Internet Database Connector, which will allow existing ODBC applications to connect to their Internet Information Server. The jury has not yet reached a verdict on how well these and other interfaces will work. But one way or another, Java needs a higher-level interface to databases and legacy applications.

The real beauty of the complete Java environment is total independence of applications in a virtual machine. When there is better server support for clients and servers, it will be possible to make on-line modifications to applications written in Java. In other words, live applications may be modified while running. The result will be ideal: applications that run 24 hours a day, seven days a week.

Assuming that good server support appears quickly, the next problem involves developing rules for partitioning client and server executables. Until the typical network connection increases beyond 28.8 kbps, bandwidth will continue to be a problem. The remaining challenges include defining a server environment that minimizes the need for large applets on the client, defining a Java compression or buffering standard for transmission of larger applets, and distributing a robust set of standard applet libraries that will be available on every client system.

While the promise of Intranets and the World Wide Web is enormous, large-scale applications designed for this environment will require a new level of sophisticated systems for the enterprise.

Issue 3: N-Tier client/server Java (language and virtual machine) can become the new client in corporate client/server systems. Since the new client can run on virtually any computer and operating system, the promise is that new software will be written not for 2-tier or 3-tier client/server computing, but for N-tier computing. It should be possible to write applications that scale seamlessly from workgroups to departments, throughout -- and outside -- an enterprise.

For this to happen, software must be supported by a set of servers with some redundancy built in. Load balancing and partitioning become more and more important. A large Java-based site may have different applications servers: one for downloading applets, one for customer support, and others for vendors, a sales force, and the public. Applications certainly will be spread over multiple servers.

Oracle is attempting to solve part of this problem with its Web Request Broker. Other vendors undoubtedly will follow with OLE- and CORBA-based products.

Interactive applications such as online customer support with text or voice will need a peer-to-peer architecture. So will protocols for other higher-level communications, for exchange of applets, and for remote debugging.

There is a lot be done -- in the language, the virtual machine, the integration with legacy systems, and major additions to the infrastructure for distributed computing.

The market is in its infancy. If you're looking for the guaranteed financial play for the Java revolution, forget about high-tech. Think forest products. []

About the author William Blundon is president and COO of SourceCraft, Inc. (http://www.sourcecraft.com), a leading developer of Intranet development tools for Java and C++. His focus in the last seven years has been on distributed object environments and the Internet. He is a former director of the Object Management Group. He can be reached at william.blundon@javaworld.com

What did you think of this article? -Excellent! -Okay -Poor [-----] -Too long -Just right -Too short Comments:

[JavaWorld Main Page] [Nuts & Bolts] [News & Views] [Java Resources]

[(c) Copyright 1996 Web Publishing Inc., an IDG Communications company]

If you have problems with this magazine, contact webmaster@javaworld.com URL: http://www.javaworld.com/jw-04-1996/jw-04-worldrule.html Last updated: 15 March 1996