Judging from the buzz you hear around the industry, it almost seems that the question of Java has been settled. You would think every organization is neck-deep in Java and that Java applications are about to come pouring out the doors. At a recent meeting of application development managers I polled the attendees on their use of Java. Only a few, it turned out, are actually testing some Java application development. A couple more are allowing their developers to experiment with Java on the side, mainly as a learning exercise and a way to keep the developers motivated. I take this poll whenever I meet with developers, and the results are usually the same.
So where is the incessant demand for Java? We hear it in the trade and business press and in reports from the trade show and conference circuit, but you don't yet find Java in rank-and-file corporate application development shops. Now, don't take this the wrong way. I do believe that Java has enormous potential, but at this point in the evolution of computer languages and software infrastructure, it hasn't taken over the world. Based on my years in the software industry, software success rarely comes in the form we expect it or when we expect it.
Remember the efforts seven or eight years ago to develop a software backplane that would allow various development tools to exchange information among each other? While those proposed backplanes never succeeded, today it is quite common to find tool and software integration happening on a regular basis. Similarly, CASE was once a high flyer only to crash because the technology at the time was too rigid. But today, development tool vendors are rushing to integrate analysis, design, and modeling -- key elements of CASE -- into their products. In both situations, the concept was right even if the implementations failed. With Java, something similar is likely to happen. Java won't change life as we know it. Java will not push out all other programming languages. It will not become the de facto language for applets. It will not turn all hardware platforms into commodities with no valuable differentiation. Clearly, the benefit of Java is that it is designed from the start to be a distributed software environment. Java will become most important as a server-oriented language for implemented distributed applications. The client-oriented Java applets will take a back seat in the long term.
Of course, developers have built distributed applications with other languages. The difference is that Java is designed to support a distributed architecture. If parts of applications are located on a dozen platforms, Java simply goes searching for the parts that aren't on the local system. The implication is that Java will make the job of writing applications for a company with offices across the globe less painful. It offers security across a distributed environment, runtime portability, and an agent language that assumes messages and information will be passed throughout the environment.
In short, Java expects that applications will be distributed across the network. Java will eventually enable developers to build applications at a high level of abstraction and assume a tightly defined object model. Developers working in C, C++, or another language can build distributed applications; but they are going to have to code the network awareness themselves by building the messaging and communications from scratch. By contrast, Java will take a lot of the difficult, complex work of building network-capable applications out of the hands of developers.
Despite all of Java's strengths and the beneficial things it will deliver down the road, development managers are wise to take a cautious approach to it. Of particular concern should be the tremendous hype that has blown up around Java. Managers are right to be skeptical when they hear vendors explaining their value-add by stating that their software is written in Java, rather than touting the sophistication of their technology in terms of its ability to solve business problems. Just because a software product is written in Java is not a guarantee that it effectively solves a business problem. An application that is portable to every platform running a Java virtual machine doesn't necessarily ensure business results. Much remains to be done with Java before we can be confident that it will deliver real business value. First, Java must strictly adhere to a standard implementation if it is to achieve its widely acclaimed portability. Java is not the first application programming language to promise universal portability. C, C++, PL/1, Ada, and even COBOL at one time offered the promise of portability across multiple platforms. C and C++ have achieved it to a large extent, but the cost is substantial complexity -- complexity that Java reduces through its automated garbage collection, virtual memory, and other features.
Neither is Java the first programming language to rely on the presence of a virtual machine for platform portability. Magic from Magic Software Enterprises Inc. has long used a virtual machine to deliver extensive write once/deploy anywhere portability. A number of other cross-platform 4GLs also use virtual machines. I'm not convinced that the pure virtual machine approach is the best solution for Java, given the performance limitations of the interpreted code. Instead, developers may prefer to create applications in Java that are then compiled to C or C++ for deployment. This will allow the applications to benefit from portability at the component level but still experience the performance of compiled code.
The Unix experience may provide some insight into the future of Java. Unix promised portability at the operating system level but never achieved it. Instead, vendors extended and enhanced Unix for the seemingly sound reasons of improving performance for a given platform or delivering some special functionality. The upshot: Many different flavors of Unix limited portability. Without strict adherence to a standard implementation, Java stands to repeat the mistakes of Unix and splinter into multiple versions and competing factions.
Although I want a standard Java implementation, I am leery of the recent 100% Pure Java initiative. I don't even know what 100% Pure Java means in terms of application development. I'm concerned that "pure" may be too rigid. Purity isn't required, standardization is. We need consistent interfaces in order to ensure interoperability.
Java today suffers from immaturity. The language is only two years old, and Java Beans, the Java component interoperability standard, is but a few months old. Just one browser, Sun Microsystems Inc.'s HotJava, currently supports the latest release of Java, although others will soon follow suit.
In the coming months and years, we will see a rapid maturing of Java. The just-in-time compilers will speed up, application testing tools will appear, the visual integrated development environments will improve, extensive Java class libraries will become available, and the various middleware needed to connect Java applications with the rest of the distributed computing environment will emerge. IBM, Sun, and other vendors are pouring millions of dollars of research and development into Java. When all these pieces fall into place within the next three to five years, we will finally be able to consider Java a platform for serious, server-oriented distributed applications and infrastructures.
Of course, there is no guarantee that all of this will happen, which is what makes the choice of Java today a bet on the future rather than a sure thing. While I'm confident that Java, in some form, is here to stay and will play a major role in corporate computing in the future, it is not going to replace everything else we have been doing.
If we look at the history of computing, we don't find hard stops where one technology ends and another starts. Instead, we see gradual evolution as older technology changes and adapts in the face of new technology. Today, mainframes, minicomputers, standalone PCs, LANs, client/server computing, the Internet, and intranets all coexist in the heterogeneous, distributed environment that is more the norm than the exception.
Meanwhile, you can take steps to prepare for a Java future without burning any bridges behind you. You can start by learning Java and experimenting with it. That means picking a project that will benefit from portability and a distributed object approach and getting started. At the same time, maintain a healthy skepticism. Make vendors demonstrate the business value of their technology, not just wave the Java banner, object-oriented banner, or any other technology buzzword. Insist that vendors provide detailed information about what their software does, how it works, and what business value it provides. Do this for Java -- and any other technology -- before you place your bet.
What did you think of this article? Send a letter to the editor.