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 plat
form 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 ha
rdware.
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 softwa
re 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 interface
s. 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 h
as 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 pione
ers 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 Wi
ndows. 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 ups
ide 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 reas
ons 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 cal
ls 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-pla
tform 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 Sys
tem (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. 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 encaps
ulation 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 comp
uting.
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 intercha
ngeable 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 applicati
ons 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 th
e 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.
Java Resources
Java Resources
Gamelan:
http://www.gamelan.com/index.shtml
This 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.
Today the Web, Tomorrow the World
