Are you ready for the Java backlash?

Industry publications and more than a few gurus are questioning how far Java has really come and how far it can go -- it's time to set them straight

Ouch. That hurts. If the quotation above were a single, random event it wouldn't hurt as badly. Unfortunately, it is one of many such opinions wending their way through cyberspace. The doubters have found their voices, and the volume is increasing.

Other recent articles on Java have used phrases like "hit a lull," "slowing down," and "not living up to its promise." In short, the naysayers have taken center stage and they plan to stay. What's going on? As the summer season reaches a crescendo in the Northern Hemisphere, we've entered what the press refers to as the silly season. Vacations beckon but deadlines loom. Even Internet time seems to slow a bit. Hard news is even harder to find. The stage is largely deserted and as a result, the masters of doom and gloom perform in the spotlight.

Still, these kinds of negative comments about Java must give one pause. In the middle of 1998, Java detractors are asking the same questions that have been prevalent for at least the last year. The answers are getting better, but the fact that the questions are still being asked is a concern in itself. The questions devolve to four basic issues:

  • When will Java performance (particularly on the server) be acceptable?

  • When will the reliability of the language and JVM be acceptable?

  • When will there be a standard Java upon which major development efforts can depend?

  • Is Java ready to be a major database language?


As discussed in June's column ("Java in Wonderland") performance is still a real issue for the Java language, but new virtual machines, enhanced compilers, and a wide variety of programming "best practices" are addressing this shortcoming.

One of the many interesting developments on the performance front is the recent announcement by Intel and Novell that they are collaborating on an enhanced Java virtual machine. In mid-June the two companies announced a partnership to create a fast VM (NetFire) for the Intel platform. As a result of this agreement, Novell licensed Intel source code that will enable the company to tune performance for both Intel's 32-bit and 64-bit architectures. While NetFire won't ship until next year, Novell already has one of the fastest VMs for Unix and Windows NT and has demonstrated this performance with the popular VolanoMark benchmarks. In short, Java performance is improving rapidly. It's not yet at the level of C or C++, but both performance enhancements over the next year and the distributed nature of most Java applications will make any remaining performance differential a moot point.

Reliability and security

As the above quote from PC Week Labs illustrates, there still are some reliability issues around Java, particularly with larger, server-based applications. Most observers would agree that these issues are more a result of Sun's hectic (and sometimes, it seems, erratic) software development and delivery policies than any inherent problem with the language. In general, Sun's releases have been too frequent, too incompatible, and too obviously focused on features, not on reliability. While many companies can help to improve Java's performance, Sun needs to work on reliability.

On the security front, the story is much better. There have been several (perhaps many is a better word) successful attacks on the Java environment. To their credit, Sun and Microsoft both have responded rapidly to every attack. Whatever its flaws, Java is the industry's most secure environment. There are now sufficient architectural constructs in the language and the environment to guarantee the high level of security required by serious corporate and government developers. But is Java totally bulletproof? Of course not. It is, however, the best thing going. In fact, it's much better than the alternatives.

The challenge with security in the real world has as much to do with continuous verification and rapid response as it does architecture. Recently, the International Computer Security Association formed a Malicious Mobile Code Consortium to address the security issues relating to both Java and ActiveX. The aim of this consortium is to help companies protect themselves from both deliberate and accidental attacks over the network. This kind of organization holds real promise in working through the practical issues of security.


Okay. Trying to see a real industry-wide implementation of write-once, run-anywhere requires binoculars -- maybe even a telescope. Microsoft has successfully remade the Java virtual machine in its own image. Its recent victory in federal court eliminates any pressing legal issues that limit its ability to bundle Internet Explorer (with the Microsoft VM) with every copy of Windows.

Again, if there were only a bifurcation in the Java roadmap, real hopes for a rapid convergence would be reasonable. However, as Hewlett-Packard, IBM, and others invest in their own JVMs, the realization of this dream is not imminent. Even when a JVM is developed for 100 percent compliance with the Sun standard, added features and divergent code bases still generate concerns.

When reality diverges from vision, it's time to rethink the vision.

How far can Java go with incompatibilities in the runtime environment and class libraries? As far as SQL? It seems reasonable to expect that Java can go at least that far. (SQL has come a long way as a standard interface to relational databases. While there are many variants and extensions to the language, it is, in fact, a standard.) But that really isn't far enough. Browser technology provides a better comparison. The two most popular browsers, Navigator and Internet Explorer, provide a common set of HTML and Java features even though they differ -- at times significantly. Can corporations write applications efficiently that must execute in both Netscape and Microsoft browsers? Yes, they can and they are. Is this the ideal situation? No, not really.

What is true with browsers is true with Java overall. As long as there are a very small number of JVMs (namely, two), developers can still write code that is fairly portable. Supporting three or more Java environments, however, is just not practical in the corporate world. The compelling economic advantage of code portability is lost. write-twice, run-anywhere is a major improvement over other options, but smart companies and developers will continue to push for complete portability. Perhaps -- just perhaps -- the legal systems of the U.S. and Europe will make the original write-once, run-anywhere Java vision a reality.

Database integration

When JDBC drivers and JDBC/ODBC bridges began shipping last year, Java began to become accepted as a database programming language. However, announcements over the last few months from the database companies take Java center stage. Of particular interest is the announcement this month by Oracle of enhancements to its database server scheduled for shipment at the end of the year. Oracle 8.1 (code named Emerald) includes a number of enhancements designed to make it a better platform for data warehousing, e-commerce, and Internet computing. Foremost among these new database features is an integral Java virtual machine.

With the Oracle 8.1, JVM database developers will be able to write stored procedures and database triggers in Java and have them execute in the database server. Integral JVM support also will allow applications to maintain direct connections from a browser to a database server without making calls to an HTTP server. Emerald also includes integral support for Enterprise JavaBeans, allowing corporate developers to centralize and reuse server-side business logic.

At the same time, object database vendors are providing a range of products for direct storage and retrieval of Java objects. While its standard enterprise databases have supported Java for some time, Object Design is also providing portable database software for the embedded market. Its ObjectStore PSE (persistent storage engine) and PSE Pro are written in Java and provide a simple API for making objects persistent (by storing both objects and relationships). Besides making it easier to make Java objects persistent, these storage engines also dramatically improve the performance of navigating through information without doing relational joins.

At the same time, IBM is retooling its CICS transaction server for the Web with a series of upgrades over the next year that will give the server complete support for Java. CICS TS 1.3 -- due for customer shipment next year -- will allow developers to write directly in Java (and CICS JavaBeans and Enterprise JavaBeans) as well as wrap code in Cobol with Java. IBM's largest competitor in this area, BEA Systems already supports Java in its BEA Jolt development environment and is creating a platform for server-side Java in its Tuxedo transaction processing system.


While the naysayers opine about the "lull" in the Java marketplace, their complaints are being rapidly addressed. In security and database integration Java has come a long way and is beginning to be a major competitor in the corporate world. On the other hand, much remains to be done in performance and reliability. Many hardware and software vendors are addressing the former, but only Sun can address the latter. Clearly, Sun needs to focus on reliability; right now features can wait. Will the vision of write-once, run-anywhere portability see the light of day? In a previous column ("Predictions for the millennium"), I predicted that this would happen by the year 2000. I'll let that stand, but in the meantime, the number of Java "standard" environments should be limited to just two -- and that is something every company and developer should support.

William Blundon is executive vice president and co-founder of The Extraprise Group (, a leading provider of application development, training, and strategic advisory services for e-business. His focus in the last nine years has been on distributed object environments and the Internet. He is a former director of the Object Management Group.