| You've heard the hype. You've groaned at the bad coffee
puns. Now it's time for the crucial question: Is Java for
real? Straight answer: Java isn't just for building cute Web pages anymore. Java is establishing itself as a serious programming language capable of tackling the most sophisticated business applications. Never in the history of computing has a new language attracted so much support from toolmakers, software developers, and OS vendors in such a short time. The larger question is, "How much further can Java go?" The answer, incredible as it may seem, is that Java could surpass Windows as the software platform with the world's largest installed base by the turn of the century. This is possible even in light of five critical Java shortcomings — including an immature security model, slow performance, and a hodgepodge of unpolished development tools — that exist today. Nevertheless, the key events are already in motion for Java to overtake Windows and cause enormous changes in commercial and corporate software development. The bottom line: All of us who have anything to do with software development ignore Java at our own peril. More Than a Language Java transcends being a language to being a software platform because of the Java virtual machine (VM), which simulates a computer in software. The Java VM can run on existing computers and OSes (e.g., Windows and the Mac OS), or it can run on hardware designed only for Java. Developers who use Java, whether they realize it or not, are supporting a new platform that exists independently of the underlying OS and hardware. Today, many commercial developers write their software for Windows first, because Windows runs on about 90 percent of the world's PCs. Then they either port their programs to the minority platforms (e.g., Mac, OS/2, and Unix) or ignore them. If the Java VM someday commands a larger installed base than Windows, developers may write for Java first — and last — because Java software is inherently cross-platform and can run on any system with a Java VM. In effect, Windows would become another minority platform (albeit the largest one) that may or may not justify the extra expense for special support. Java could trigger the biggest platform shift since Windows surpassed DOS — all without forcing you to change your hardware and OS. The Java Language Before Java can become a dominant platform, however, corporate and commercial software developers must embrace it as a language. As recently as last summer, many of us were asking if Java was powerful enough for serious software development. Today, that question is obsolete. Consider the following: • In October, Sun estimated that more than 200,000 professional programmers were using Java. • According to Sun, one-third of all the enterprise developers at companies with more than 5000 employees use Java. • Last summer, 11 companies (including Cisco Systems, IBM, Kleiner Perkins Caufield & Byers, Netscape, and Oracle) pooled $100 million to form the Java Fund, a unique venture-capital resource for new Java projects. • IBM and more than 50 independent software developers announced the San Francisco Project, a plan to build new business applications with Java. These developments help overcome Java's reputation as a lightweight language for creating decorative Web applets. Look beyond the bouncing heads that enliven Web sites, and you'll see that Java is an industrial-strength, object-oriented language that supports inheritance, encapsulation, polymorphism, multithreading, dynamic linking, and interfaces. It's in the same major league as C++. Why is Java winning over professional developers, who are notoriously hard to please? Java closely resembles C++, so experienced programmers probably have more to unlearn than to learn. Yet it offers significant advantages over C++. Java makes it easier to write code that's portable, reusable, and bug-free. Cross-platform compatibility is a tremendous factor in Java's early success. Java compilers (available for Windows, the Mac OS, and Unix) convert Java source code into class files of byte code. The class files correspond to executable binary files generated by compilers for other languages. Unlike native binary files, however, Java byte code isn't specific to a particular microprocessor architecture. Its "native" architecture is the Java VM, which today exists only in software. (Soon, it will exist in hardware as well; see "Sun Gambles on Java Chips," November 1996 BYTE, page 79.) As a result, Java class files are portable to any hardware platform that has a Java run-time environment. The environment consists of the Java VM, some standard class libraries, a byte-code verifier (for security), and a byte-code interpreter. The interpreter runs the class files on the VM without requiring programmers to rewrite or even recompile their source code. This "write once, run anywhere" universality is so compelling that some companies are writing their Java development tools in Java so they'll run on any machine. Ignite Technologies' Layout Mill, a visual GUI builder, is one example. "For the first time, developers can write applications using their Windows people, their Unix people, and their Mac people," says Bill Kelly, president of Ignite. "All of the programmers can work on the same project with the same tool on any platform. This allows developers to hire programmers based on the programmer's expertise with the type of application they want to write, not just the kind of machine they know how to use." Because Java programs stay within the Java run-time environment, they normally don't interact directly with the native CPU or OS. The run-time environment handles memory management, including garbage collection, so programmers don't have to allocate memory or dispose of leftover objects. There's no need for pointer arithmetic, another major source of bugs in C++. Java has a clean, efficient model for error handling and encourages code reuse because it's object-oriented from the ground up. Java also substitutes interfaces for the complex multiple inheritance of C++. According to John F. Andrews, president of CSX Technology, programmer productivity and cross-platform freedom were "key factors" in his railroad's decision to use Java for a massive shipment-tracking application. CSX thinks it's the largest enterprise application yet written in Java. "Java happened at exactly the right time for us," says Andrews. Java's much-vaunted portability isn't flawless, however. Sun's JDK 1.0 doesn't fully encapsulate the native APIs of underlying OSes, so Java pioneers must work with a more limited vocabulary of GUI widgets and features. Also, there are numerous quirks in the way different Java run-time environments map high-level objects to native APIs (see the sidebar "The Bitter Taste of Java"). Growing pains are inevitable with something as spanking new as Java. JDK 1.1, scheduled for release early this year, will fix many of these problems. New Java VMs and development tools are in the works, too. Java is evolving so rapidly it's like the weather in some places — if you don't like it, wait an hour. The Java Platform Even if Java becomes nothing but a popular development language, Sun will have scored a big hit. However, Sun — and others — have grander things in mind. Could Java, as a platform, be a Windows killer? Probably not. But it doesn't have to be. It's important to realize how Java can supersede Windows without killing Windows — or any other platform, for that matter. Java is a stealth platform that propagates entirely in software and coexists peacefully with the native OS. Other platforms are tied to specific hardware. For every installed copy of Windows, there must be a Windows-compatible PC to run it on. Likewise for the Mac OS, OS/2, Unix, and so forth. There's a little overlap due to emulators, such as SoftWindows and PCs with dual-boot OSes. For the most part, however, the leading platforms add to their installed bases only when someone plunks down a few thousand dollars for a machine. This is not the case with Java. It's a platform implemented in software that runs on practically any machine, and software spreads much faster than hardware. If you've installed a Java-compatible Web browser, such as Sun's HotJava, Netscape Navigator 3.0, or Microsoft Internet Explorer 3.0, the Java run-time environment is already on your computer. You can also download JDK for free off the Web to make your system a Java platform. Java development tools come with a VM, too. Java isn't self-replicating like a virus, but it's nearly as contagious. Apple, IBM, Microsoft, Novell, Silicon Graphics, and Sun are paradoxically accelerating the process by integrating the Java run-time environment into their OSes. All of them say their OSes will be Java-enabled within a year. They recognize Java's popularity and potential, and that offering a superior Java run-time environment will give them a competitive advantage. It's good for users because each new Java-enabled application you install won't have to clutter your system with its own VM. "We think it's critical to establish a good, stable, standard Java VM on the Mac platform," explains Mike Zivkovic, product manager for Apple's Mac OS Java run-time environment. "We are concentrating on stability, stability, stability. That's what software developers tell us they want more than anything right now." By the end of this year, there will be Java VMs for Windows 95, Windows NT, Windows 3.1, the Mac OS, most flavors of Unix, OS/2, NetWare, and Apple's Pippin and Newton OSes. IBM is even porting Java to the AS/400 and MVS, which manage an estimated 70 percent of the world's corporate data. This is why it's not crazy to predict that by the turn of the century, there will be more copies of the Java VM in the world than any of the OSes that host it. Note that Java will not replace any of those OSes. Indeed, the Java VM is a benign parasite that cannot run without a host OS. (Sun has a special Java OS, but it's for dedicated Java devices, not conventional PCs.) Far from being a Windows killer, Java actually needs Windows to spread itself on the massive installed base of PCs. Things will get really interesting if that happens. Sheer numbers will make Java the world's most widespread software platform. Every Java VM will run every Java program that has ever been written or will be written, without porting or recompiling. How will this affect the software balance of power? It could work to the advantage of minority platforms that currently don't attract as much software development as Windows. Today, developers justify Windows-centricity by explaining that it's simply good business to target the largest installed base. If Java becomes the largest installed base, and developers gradually shift their focus away from Windows, the minority platforms will get much more software. On the other hand, Java could also hurt the minority platforms by robbing them of the special development they receive now — the kind of support that makes them unique and justifies their existence. This is not just a puzzle for sales-conscious commercial developers. Cost-conscious corporate developers must weigh the benefits of writing for a universal platform, too. David Gee, Java marketing manager of IBM's Internet Division, says Java will revolutionize the deployment of enterprise applications in heterogeneous environments. "It doesn't matter what the server is, it doesn't matter what the client is, it doesn't matter what the network is. That's huge." Five Reasons to Snub Java With an upside this big, there has to be a downside. Although it's possible Java will someday be the most populous platform, it won't necessarily be the most popular platform for new software development. Despite Java's benefits, there will still be reasons why a developer might "go native" by writing for the foundation OS: 1. A native OS might offer features that Java can't use without sacrificing cross-platform compatibility. 2. Interpreted Java byte code doesn't run as fast as compiled native code. 3. If a program must interact with legacy code or data, a more established tool or language might work better. (This is an especially important consideration for corporate developers.) 4. A developer may have superior tools for another language or may be more productive using a familiar tool or language. 5. A developer may not want to change, even if it costs money and customers. It's important that most of the reasons are technical, subject to technological progress — and technological roadblocks. Take the first reason. To a great extent, you can measure Java's maturity by its ability to take advantage of platform-specific features. Today, Java is definitely immature. It can access native features in two ways. The most desirable way is to encapsulate the native service in a Java class file, because it preserves cross-platform compatibility (assuming other platforms offer a similar service). The other way is to access the native features by calling their native code directly; this sacrifices cross-platform compatibility. For example, Java has a class called Button that displays a push button on-screen. Push buttons are common to all GUIs. When a Java program instantiates a Button object, Java creates an intermediate peer object that maps the button to a corresponding routine in the native OS's API. On a Windows PC, Java calls the button routine in the Win16 or Win32 API. On a Mac, Java calls the button routine in the Toolbox. On a Unix system, Java might call the button routine in Motif. This abstraction gives you a Java button that looks like a native button on screen, even when you run the same class file on different systems. Java's Abstract Windowing Toolkit (AWT) is a standard class library that encapsulates a large number of these basic GUI components. Additional libraries encapsulate other native services. But they don't include them all. There's no support in the current JDK (1.02) for drag-and-drop editing, the playback of QuickTime movies, and numerous other advanced services. New class libraries will address many of these shortcomings. JDK 1.1 will include a more complete AWT, and JavaSoft is working on a slew of libraries to fill in the remaining gaps. Also coming this year are classes to support richer multimedia (including 3-D graphics and audio/video playback), more flexible security, on-line commerce, telephony, network management, enterprise interoperability, cross-platform components, and server-side Java processes (called servlets). JavaSoft is releasing these libraries in stages, preceded by specs that introduce programmers to the new classes and methods. For instance, some of the enterprise classes are available now, letting Java programs access corporate databases through Java Database Connectivity (JDBC) interfaces. There are also gateways to Common Object Request Broker Architecture (CORBA) components and remote method invocations (RMIs). Sun and JavaSoft aren't working on this alone. Java has broad industry support. Examples include Symantec's dbAnywhere, which provides the middleware and Open Database Connectivity (ODBC) drivers to connect Java programs to Oracle, Sybase SQL Server, Microsoft SQL Server, Microsoft Access, and numerous other databases. Centura Software (formerly Gupta) sells Centura Web Developer, which lets corporations build Java programs that simultaneously connect to multiple databases via IBM's Customer Information Control System (CICS), a transaction-processing monitor. Corporate developers who need to make Java applications fit with legacy code are encountering fewer roadblocks. However, if a developer absolutely needs a native service that Java doesn't support, Java has a method modifier (native) that lets a Java application directly call a native executable file, such as a DLL or an OS API. This also delivers native performance. Unfortunately, native methods have two major drawbacks. Java applets (programs that run in a Web browser) currently are not allowed to call native methods, for obvious security reasons. Sun is developing a new security model that will let users and administrators selectively change this restriction, as well as other security rules. (See the sidebar, "Plugs for Java's Security Holes.") More seriously, native methods undercut Java's cross-platform compatibility. A Java program that relies on native methods would need a similar method on every supported platform. Sun's new component architecture, JavaBeans, will accelerate Java's encapsulation of native features by bringing more third-party developers into the fray. Beans are easier to write than Microsoft's ActiveX objects or Component Integration Laboratories' OpenDoc Live Objects, yet they can interact with those component architectures (see the sidebar "JavaBeans: Cross-Platform Components"). Speed Limits Developers who need maximum performance have a good reason for avoiding Java: They can write a compiled program in C or C++ that runs at least 10 times faster than an interpreted Java program. For many applications, this isn't important. Tools such as Visual Basic and PowerBuilder are popular because they're fast enough. But when performance does matter, there's no denying that interpreted Java byte code is slow. To some degree, this problem will solve itself as computers get faster. Of course, native code will run faster on those new computers, too, so this won't eliminate the performance gap. However, the gap does not have to close altogether for Java to succeed. Compiled C/C++ code doesn't run as fast as expertly written code in assembly language, yet few developers are using assembly language these days for anything but optimizing critical routines. C/C++ rules because it's more portable and it helps programmers work more productively — the same advantages that Java offers over C/C++. Nevertheless, programmers and toolmakers are striving to improve Java's performance. Programmers can write inline code (see "Better Java Programming," September 1996 BYTE). Sun Microelectronics and International Meta Systems are designing microprocessors that will execute Java byte code directly. Perhaps the most promising solution is just-in-time (JIT) compilers. Like Java interpreters, they convert byte code into native code on the fly, but they cache the converted code in memory while the program runs. JIT compilers can be completely transparent to users. Java programs that run through a JIT compiler can achieve up to 50 percent of the speed of native code, and the technology is steadily improving. Netscape plans to bundle a JIT compiler with Navigator 4.0, and Microsoft, IBM, and Apple plan to integrate JIT compilers with their Java run-time environments. Another option is static compilation. Silicon Graphics Inc. (SGI) technology translates byte code into Mips Rx000 native code, links the resulting binaries to the Java class files, and adds a second entry point to the Java method block. Java programs, running on SGI's specially modified VM, check the method block to see if there's a pointer to a translated method. If so, the program executes the translated method instead of the byte code version. Combined with inline coding, this allows Java to approach the performance of C++, according to David Henke, engineering manager of SGI's Web Products Division. As with native methods, however, SGI's technology limits cross-platform compatibility — the translated code runs only on a Mips CPU. It offers two advantages. Developers can easily separate the translated code from the byte code to regain portability, and programmers can write an entire project in Java instead of writing native methods in another language. There's no reason why SGI or someone else couldn't adapt this technology to other CPU architectures. Java applets will probably always exist as platform-neutral byte code, because they're embedded in Web pages that must run on any browser. However, stand-alone Java applications that need top performance will almost certainly rely on some kind of JIT or static compiler. The performance boost is significant, and it doesn't have to interfere with the cross-platform compatibility that is Java's greatest strength. Higher Abstraction In the long run, none of the technical problems that might deter today's developers are likely to pose an insurmountable obstacle for Java. As both a language and a platform, Java is evolving at an unprecedented pace. We can speculate on Java's course because it's consistent with historical trends in computing. The most important trend is toward higher levels of software abstraction above the hardware. The more tightly that software is intertwined with hardware, the bigger the headaches for developers and users. Programmers get more performance by writing to the metal, but the code is hard to maintain and even harder to port. And code lives longer than anyone plans. That's why the computer industry is spending billions of dollars rewriting ancient code that can't handle the year 2000. That's why the U.S. air-traffic-control system is still running on antiquated machinery from the 1960s. That's why the Social Security Administration is patching a program from the 1970s that has been underpaying retirees for two decades. Put bluntly, it's negligent for software developers to ignore the possibility that their code may live for 10 or 20 years. Java carries software abstraction to the next level because it abstracts everything below the VM. It's designed for a world in which the OS and CPU are interchangeable parts that can be replaced without breaking applications. It's designed for an age of diversity in which PCs and other smart devices can use any CPU or OS that delivers the best performance, the lowest cost, the most efficient power consumption, the lightest weight, or any other parameter that becomes important. Java's success isn't inextricably tied to network computers, PDAs, and smart appliances, but Java is ideal for devices that expand today's narrow definition of a PC. Unix and NT offer some hardware abstraction, but they're multiplatform, not cross-platform. Users still have to replace or recompile all their software if they switch CPUs, and not all software is available for all CPUs. Also, these OSes still chain you to an OS. Java can run on just about any OS or CPU. Gambling on Java So a developer's decision about adopting Java depends on three questions. First, can Java handle the job? It should be clear by now that Java is suitable for a wide range of applications and is gaining ground fast. Still, it can't do everything, and the tools need to get a lot better. Second, does cross-platform compatibility matter? If you believe the computers of tomorrow will be basically the same as the computers of today, only with more megabytes and megahertz, Java isn't the best choice. Other languages and tools are more refined and deliver better performance on traditional hardware. If, however, you'd like to write code that runs on any hardware, the final question is whether Java is the best cross-platform option. The answer depends on the maturity of Java, which changes almost daily. Certainly you can do a lot with Hypertext Markup Language (HTML), JavaScript, VB Script, Perl, and other cross-platform solutions, especially if Microsoft delivers on its promises for ActiveX. But it's hard to bet wrong on Java. History shows that those who gamble correctly on an emerging platform win big, and those who gamble wrong end up with dead code. Even if Java fails to conquer the world as a platform, you'll still end up with code that runs on whatever platform rules the kingdom. For developers, the risks are minimal. For users, Java could bring a new freedom to change OSes and CPUs without breaking software — a freedom they've never had before. Sidebars:
Java ResourcesGamelan: http://www.gamelan.com/index.shtmlThis on-line directory can point you to thousands of Java applets and applications, Java development tools, and links to hundreds of other Java-related Web sites. The Java Difference Tom R. Halfhill is a BYTE senior editor based in San Mateo, California. You can reach him on the Internet at thalfhill@bix.com. Inbox / April 1997On JavaFirst, you claim that Scott McNealy (Interview, January Bits) said that Java "is not object-oriented," but "object-based." I cannot believe he said that. Java has at least two important flaws, but a lack of object orientation is not one of them. "Today the Web, Tomorrow the World" (January Cover Story) also misses the main point. The Java virtual machine (VM) is not terribly important. People have been building VMs for around 30 years. The important thing about Java as a development platform: OS-independent API calls. The question will be how many of the facilities of the underlying OSes are accessible in an OS-independent manner. Perhaps the programs will have to be written against an API that implements the intersection of the features on the various OSes. This might not be a bad thing, but it would tend to produce a Java look and feel rather than a Windows, Motif, or Mac look and feel. In this sense, there is some justification for your cover headline "Can Java Replace Windows?," even though one is a language and the other an OS. Once the Java APIs have been invented, you can use them with any language — you just have to redo the interfaces. Taken by itself, the article is a good report on the current state of Java. Taken with the cover headline, it is less than adequate. David L. Moore dlmoore@ix.netcom.com Scott McNealy merely meant that Sun designed Java to be an object language from the ground up; it's not a retrofit like C++. You are correct that many VMs and attempts at universal platforms preceded Java. That's one reason why I believe the concept will eventually take hold, even if Java fails: It has too many advantages for users and developers. Although Java abstracts the CPU and OS, it does not substitute its own look and feel. Java programs look like Windows programs when they're running on Windows, Mac programs on the Mac, and so on — without porting or even recompiling any code. Indeed, the big challenge is how many native features Java supports among the OSes it runs on. It doesn't have to support them all, however, to succeed as a "metaplatform" alongside the popular native platforms. —Tom R. Halfhill, senior editor Ada Speaks Java Your generally excellent article "Today the Web, Tomorrow the World" should have mentioned that using the Java interpreter, just-in-time compilers, and environment does not require you to use the Java language. In fact, the comment that "it's negligent...to ignore the possibility that...code may live for 10 or 20 years" suggests that today's rapidly evolving Java might not even be the best language for Java applications. An alternative, which uses a well-tested ISO-standard language designed for security and safety, is the Ada-to-Java bytecode compiler offered by Intermetrics (http://www.appletmagic.com/appletmagic.html). Tom Moran tmoran@bix.com This is an excellent point that I didn't have room to cover in my January story: Other languages can target Java bytecode. You can think of bytecode as a platform-neutral mechanism for delivering software.—Tom R. Halfhill, senior editor Inbox / May 1997Java for C++I agree with your point that though Java may be the largest installed software platform in the world, it still can't displace the OS that supports its run-time environment ("Today the Web, Tomorrow the World," January). Why isn't the industry trying to develop a Java-like run-time environment for C or C++? This would offer the stability of an established language along with the portability that is the hallmark of Java. A substantial portion of the huge installed base of C/C++ software could become available across a range of platforms — provided it isn't tied to OS-specific features. Of course, C/C++ compilers would have to be modified to generate something analogous to Java bytecode that can run in their own run-time environment or a C++ virtual machine. Balaji Raghunathan braghuna@stratacom.com C/C++ programs, as you point out, often use OS- or CPU-specific features. Existing C/C++ software written to APIs and GUIs such as Win16, Win32, the Mac Toolbox, OS/2 Presentation Manager, or Unix Motif would have to be extensively rewritten. C/C++ by nature is a statically linked and compiled language. References to methods, for example, are resolved at link and compile time by a C/C++ compiler-linker. With Java, those references are not resolved until run time because Java programs load classes dynamically. It would take major reengineering to make C/C++ work like Java. Someone would have to write C/C++ virtual machines to run on all the major platforms, as well as develop a standard set of class libraries to abstract the OS-specific features of those platforms — as Sun did for Java. Imagine the infighting over this evolution among the major vendors. Sun had the luxury of defining a new language from scratch. There is an alternative: Other languages can target Java bytecode when they compile. Think of bytecode as the native instruction set of the Java virtual machine. It's already been done for Ada, and there have been experiments with a Smalltalk compiler. James Gosling, the father of Java, says that even Visual Basic could target bytecode. This opens up exciting possibilities.— Tom R. Halfhill, senior editor Copyright 1994-1998 BYTE |