Information systems, meaning primarily software, are increasingly seen as a competitive weapon by which faster development and deployment equals a business advantage. This means more features on a shorter deadline. For developers this can be achieved by working harder or, perhaps the smarter choice, adopting Java. While some organizations reject Java because it doesn't have the right brand name or they view it as a risk, a recent International Data Corporation study reports significant cost and time savings by organizations who use it.

Of course, I didn't really read the study because it confirms what Java developers already know: there are solid technical reasons why Java development should be faster and more robust. The developers of the language had the advantage of history and, for the most part, picked the best of other languages and skipped the worst. Java itself lacks many of the "hacks" present in other languages, which makes it easy to learn and use. The language has evolved rapidly and well, and although it may not be perfect, it's good and improving. The most fundamental property, ByteCode portability, makes building cross-platform applications easy - a huge savings since very few enterprises are totally homogeneous. The Internet ancestry and network support within Java are obvious advantages if you're building distributed systems. JDK and Swing provide a feature-rich class library. Graphical layout tools allow even those of us who are artistically challenged to create fairly good-looking user interfaces. Even the humble JavaDoc takes some of the pain out of the necessary task of documentation. Java 1.0 was viewed as a way to create bouncing images on a Web site, and Java 1.1 is a real enterprise business tool.

What's hard to find through statistics is that something about Java development just feels good. Unlike other languages, coding in Java rarely seems to reach a point where the language itself is the limiting factor. Part of the reason for this is that at runtime the objects can tell you about themselves. This capability is most obvious in the concept of an "interface," where the object is irrelevant and only the methods matter. This "dynamic runtime" allows you to ask objects what features they can provide while the application is running. While this may seem trivial, it leads to the powerful component architecture of Java: JavaBeans.

JavaBeans are usually manipulated in a graphical editor. While GUI builder capabilities are available in other languages, JavaBeans can tell the development environment much more about themselves than their simple design properties. Applications such as Sun's Java Studio, combining JavaBeans and other dynamic Java objects, allow nonprogrammers to simply and elegantly create whole applications. In an eerie video-gamelike world, mouse click-and-drag maneuvers connect the on-screen dots and build complete and powerful systems. Don't try this in other languages. In the area of factory automation, organizations have spent millions of dollars largely to re-create, in less dynamic languages, the capability that is available in an $89 software package, Java Studio.

Once you can ask a component about itself, you can begin to ask for not just an object, but for something that provides the functionality you need. This is a subtle but important distinction because it allows greater flexibility and removes the need to re-create software as options change. A tool to "output a document" may be a printer or a formatter and an e-mailer. In an ideal environment the application searches the network for the required functionality and uses it. Java's platform independence makes this possible. This could include not only hardware resources, but also sources of information and even filters to analyze that information. This is the essence and goal of Sun's JINI technology. It's also a logical extension of existing Java technology.

There are a great many other Java ideas and technologies either available or in progress. Many will succeed and become so commonplace they'll no longer appear exciting. In software, as in real life, imagination is limited by the language used, so we can expect new ideas and concepts both incremental and revolutionary that are today literally inconceivable. We're working with first-generation Java technology; JDK 1.2 has not yet even been released. The programmer's toolbox for JDK 2.0 (and 3.0, 4.0, etc.) will certainly contain items that have previously been impractical or haven't yet been imagined.

Java is changing the software development process. Building the components will be the task of the developer; building the enterprise will be the task of a systems engineer. You may view change as a risk, but risk is always part of an equation that includes reward, and the rewards are potentially large. There's little doubt that Java can provide a competitive advantage, and that the technology will advance in ways that traditional development won't be able to match.