In-Depth

Java soft spots

• By Chris Laffra
• July 20, 2001

Java is one of the coolest new software technologies. While none of the elements in the Java environment are unique, Java combines these elements into one cohesive package.

The key elements in the Java environment include platform independence through a virtual machine, powerful object-oriented abstractions through classes and interfaces, multiple threads, garbage collection, exception handling, late binding, type checking, security and the applet/browser download model. Sun, the originator of Java, chose to deliver the appealing package free of charge initially and distribute the source code under license. The strategy was a key to its early success. Later Sun created the "Javasoft" subsidiary to focus on Java deployment. Early adoption by influential vendors, such as Netscape Communications Corp., Mountain View, Calif., also helped in the spread of Java. Unprecedented media coverage, sometimes hyping Java as the "silver bullet" solution to all software problems, also helped spread the news. Add a growing concern for the "complexities" of C++ and an increasing interest in distributed systems, and Java turned into the proverbial unstoppable train.

While the train may be unstoppable, the track still has some bumps. This feature first examines the obvious Java benefits and then looks at the "soft spots" in the language and environment that can threaten early corporate development projects. This story will look at the problem areas in detail, put them in perspective, identify what is being done about them, and labels when these issues are expected to be addressed. It is up to I/S managers to weigh the risks to specific projects against the potential of Java.

Reasons for using Java
Platform independence

Java programs are more than "portable," they are platform-independent in a more fundamental way. A Java program is written and debugged on one platform and then can run on any platform that supports Java. Here, a "platform" is not limited to hardware; Java can be hosted on a wide variety of operating systems. A Java program can run unmodified on these systems from a single, compiled binary form.

A Java program is compiled into Java bytecodes. (See Fig. 1.) The Java bytecodes are shipped over the network. When the bytecodes reach the destination, a virtual machine (VM) loads and executes them. The virtual machine shields the Java program from the underlying operating system, and translates the various forms of system calls into a common Java-based view of the hardware.

In some virtual machines the bytecodes are "interpreted," meaning that the virtual machine program branches internally for each bytecode in each Java method (Java lingo for functions or subroutines). For better performance, a so-called Just-In-Time (JIT) compiler may translate bytecodes into local executable code, so that method bodies are no longer interpreted. Executing code natively versus interpreting the bytecodes increases the performance of the VM, dramatically for code with expensive loops. Alternatively, for server-side Java applications, the entire application may be compiled into an executable directly, bypassing the need for an interpreter.

In addition to the runtime system, Java supplies standard class libraries to all applications. Libraries exist for graphics, networking, data structures and so on. These libraries are sufficient for base support of most applications and are available on all Java platforms. Thus, the same Java code will work on all target platforms.

Internet programming

Platform independence would be an advantage for any mixed-platform project. Java's popularity, however, came as the industry's interest in the Internet reached its peak. So Java could use its Internet distribution model. Further, Java has excellent support for network programming. It comes with special classes to open a socket connection to a server and classes that make it easy to parse network data or to send full Java objects on the wire. Thus, Java's platform independence goes beyond moving code between machines into helping multi-machine systems to be built. Java is quickly becoming the Internet language of choice.

Ease of development

Java is a relatively simple language. Although Java contains many advanced development paradigms, it is fairly easy to understand the ground rules: objects are created from classes, methods are called to do something, and state is saved in fields. Java has great namespace separation, putting all "global" variables and functions inside classes. There is only one way to reference a Java object, with an object reference, not with automatic variables, references and pointers as in C++.

Java is also a "safer" language than C++. Java's type-checking is even stronger than C++ so that the compiler will detect invalid assignments and casts. In Java, array boundaries are checked at runtime and pointer-arithmetic is not allowed; the associated bugs are a thing of the past. Memory management is also trivial. Objects are garbage collected after they become unreachable, eliminating another class of bugs.

Java platform-independent execution model

A Java program is compiled into Java bytecodes, which are shipped over the network. When the bytecodes reach the destination, a virtual machine (VM) loads and executes them.

Fig. 1

Source: IBM T.J. Watson Research Center

Although most reports are still anecdotal, Java seems much easier to work with than C++. The C++ language is extremely flexible, with constructs such as templates and overloaded operators. Java is a more limited instrument, but the limitations allow more focus on development.

Easy to switch from C++

The step from C++ to Java is very easy. In fact, many C++ programmers report that Java can be learned in one night, using a copy of "Java in a Nutshell" or "Hooked on Java." Practically all programmers attending a two-day course on Java end up with a multithreaded, nicely animated applet that can execute in the context of a Java-enabled browser such as Microsoft's Internet Explorer or Netscape Communicator.

"Java is fun"

Java also provides a number of other advantages. These include simple dynamic loading of code, a comprehensive built-in class library, a compact binary form and a model for class evolution. Mixed together, the advantages combine to create an exciting new technology -- summarized by techies as "Java is Fun!" At first glance, "fun" should not be an argument for choosing Java as a strategic programming language. However, Java is hot and programmers jump at the opportunity to join a Java project. When programmers use a language described as "fun," they are more productive and creative. If an I/S strategy includes producing innovative systems, Java can help attract talented programmers. All told, Java is clearly poised to become the dominant implementation language for modern computing systems.

Soft spots in Java

After hearing the numerous advantages of Java, many of which are repeated and overexposed in the media, a corporation may be ready to jump on the Java bandwagon for its next project. Of course, nothing is perfect in software. The following list describes a few problem areas in Java. Each soft spot is described briefly, followed by what is being done about the particular problem area, and when a solution is expected.

Soft spot #1:
Java Development Environments

JavaSoft freely distributes the Java Development Kit (JDK), which can be downloaded from the Javasoft Web site. It includes a Java VM, a Java to bytecode compiler and a debugger. With an off-the-shelf editor (like Emacs), this environment alone is sufficient to do basic Java development.

Further, a couple of Java development environments were directly retrofitted from existing C++ interactive development environments (IDEs). The similarity between C++ and Java allowed Symantec Corp., Cupertino, Calif., to deliver their Java-based Cafe development environment in an incredibly short time. Microsoft quickly delivered a similar environment based on Visual C++. Neither are written in Java, but in a mix of the more mature C and C++.

A more ambitious project is SunSoft's Java Workshop. The goal is to have a Java development environment (editor, compiler and debugger) all written in Java. In fact, Java Workshop uses the browser metaphor and integration with HTML documentation is seamless. The SunSoft product faces some serious early-adoption challenges, being one of the first major Java projects.

VisualAge for Java from IBM takes a different tack by building a Java environment in the Smalltalk model. The tool supports the direct interactive method execution in the IDE and the Envy development system.

As far as compilation of Java source code is concerned, both Symantec and Microsoft use Java compilers written in C or C++. IBM provides Jikes!, a fast compiler that naturally complements the JDK with a much faster compiler than "javac," while at the same time producing better diagnostics and error messages.

Limitations of current Java IDEs

All the development environments mentioned are basically immature copies of C++ environments. Operationally, each offers the similar compile-edit cycle, but the simpler nature of the Java language and the small size of current Java projects tends to make recompilation much faster. Moreover, each of these environments still concentrates on Java as a programming language, giving much less attention to issues like team-based development (including version control); connection to databases; linking with legacy code through native methods; Framingham, Mass.-based Object Management Group (OMG) Common Object Request Broker Architecture (Corba)-based services; separation of a Java program in separate communicating processes; and analysis of Java code for performance or synchronization errors. Current Java projects must find distinct ways to solve such problems, which requires sophisticated developers or limited design goals.

Databases and Corba support

In addition to the major IDEs, many Java tools are available that can provide access to databases through the Java database connectivity (JDBC) layer. By 1998, however, most Java development tools should progress to supporting full scale multitier application development and tuning (similar to the interesting but more proprietary environment of Forté Software, Oakland, Calif.). The first step will be to make the development environments Corba-aware and, later allow developers to consider issues like load balancing of clients and servers.

The future of Java IDEs

Rather than simply fixing problems with the current IDEs, the next generation of Java development environments will concentrate on JavaBeans rather than just make programmers enter Java source code and compile it. JavaBeans are Java components -- Java classes written with specific methods for run-time component interaction. A JavaBeans application is composed of Java components adhering to a common method protocol. JavaBeans can be written completely in Java, and are therefore as portable as Java.

Relative cost of Java
instructions

Table 1

Source: IBM T.J. Watson Research Center

In addition to providing a common interaction model, JavaBeans support visual development. Developers can drag JavaBeans out of pallets and connect them visually. JavaBeans produce events, and JavaBean tools let programmers visually make connections to react to an event, without needing to write a single line of code. The environment generates the required Java code, compiles it and runs it for testing. In principle, a JavaBean-aware development tool allows for programmer productivity equal or better than Visual Basic, while at the same time rendering an application that is platform independent. These kind of environments can accelerate the adoption of Java to a broad population of developers; these tools constitute the real future of Java -- component-based programming.

Soft spot #2:
Performance

As I/S organizations move from embellishment applets in Web pages to enterprise Java applications, developers need to consider Java performance. This means learning the basic algorithmic tricks for Java, things like double buffering images, buffering IO and applying appropriate data structures. Then the organization needs to accumulate experience with the application style to be developed. Unfortunately, even after it is decided that Java performs adequately, the performance soft spot will come back from skeptics on the development team. Skeptics point out that Java is not designed to compete with Fortran and C in raw performance. The complaints are considered here as today's reality and for tomorrow's potential.

The novice

Some novice Java developers may complain that "Java is interpreted, so it's too slow." Of course Java does not need to be interpreted. A just-in-time (JIT) compiler can translate bytecodes into native machine instructions to make methods execute faster. JIT compilers are especially effective on medium-sized method bodies with simple C-like loop constructs -- they basically apply simple C optimization techniques. JITs are available for many platforms (Symantec, Microsoft, Sun, Hewlett-Packard and IBM), but are not a required part of a Java system.

Beyond JITs, there are environments that take Java source code and produce executable code directly; these include Supercede from Asymetrix Corp., Bellevue, Wash., and IBM's HPJC. These systems sacrifice binary portability, but apply more sophisticated optimizations than available in JIT compilers. Limited platform coverage and increased maintenance costs have to be traded against the performance improvements. Look at these solutions as part of a migration strategy.

The critic

A more knowledgeable developer may realize that Java can be compiled but still claim that "Java's too slow, even with a JIT." Most developers draw on experience from older compute intensive projects running on smaller, slower machines. For many modern applications, which emphasize user interaction, communications or time to deployment, today's Java performance is satisfactory. Moreover, modern systems can be built in multiple languages. Enterprise application architectures typically rely on distributed applications with computational complexity divided over multiple nodes in an Intranet. A common model deploys Java clients, perhaps as applets in a Web browser, connecting to various services through Corba using the IIOP protocol. In these systems, servers can remain in C++, while more interactive and rapidly evolving multi-platform clients can be written in Java.

Even the performance engines can benefit from Java over time: as development costs continue to rise and new demands on software projects arrive at frightening rates, developer productivity, not computer productivity, becomes the key to success. Even if Java runs somewhat slower, the benefits of easier language, broader standard, open architecture and platform independence grow over time. Eventually large segments of systems will be built in Java. Look for opportunities to segment servers into performance kernels coupled to more dynamic drivers with the latter written in Java.

The cynic

Finally, there exists the programmer who claims "Java will never run as fast as C++" and no argument can convince them that Java has a future. What if Java could be faster than C++!?! Drum-roll please: introducing the Hotspot virtual machine technology from Javasoft. Hotspot uses dynamic optimization of Java methods, concentrating on the most often executed parts of a Java program. Using the ultimate in performance analysis -- the end-user execution profile -- Hotspot gives the best tuning possible. The key Hotspot optimization, inlining, actually accelerates the C-like optimizations already employed in JIT compilers. The Hotspot technology came out of extensive experience in another Sun-sponsored project, the Self programming language, developed as a research project at Stanford University, Palo Alto, Calif. While there's no sense running out to rewrite large scale numerical computations in Java, neither does it make sense to prejudge Java's potential performance.

Soft spot #3:
Security

Java's security model is an "all or nothing" approach. Java divides programs into applets under security control and applications under no control. Applet security is based on a sandbox model, where access to system resources is strictly limited. Applets are downloaded into an execution environment, and are free to play as they want as long as they stay within the sandbox. Only if the implementation of Java's security mechanism contains bugs can applets escape the sandbox. A couple of these bugs in early versions of Netscape's Java virtual machines lead to concerns about Java's security.

The Java applet security model has proven adequate but too constraining for some projects. On the other hand, applications does not have a security model. Enterprise-level projects have adopted the strict applet model. In these projects all input to and output from the client applet must flow back to the server that offers the applet. The risks here include poor performance and unreliable systems behavior because no local information systems can be used by the applet.

Applet security supports the use of Java in online advertising: it protects Web browsers from corrupt, erroneous or infected bytecodes. Applet security does not address online commerce -- the protection of data on the Internet -- or the security needs of collaborative computing systems -- allowing access to local machines. Ultimately, Java requires access to an encryption standard to protect data over a network, and a system for digital signatures to allow controlled local access. Encryption, as a key element in Internet commerce, will be available during the coming year. Digital signatures will take longer to be effective. Digital signatures have been added to Java archive files in JDK 1.1, allowing users to certify the source of an applet and to open the door to applets with selective access to the local machine (to save local files, for instance). Expect browsers to implement such features this winter, giving Java a "trustable" sandbox model that allows a continuum between total control and total freedom. Forging digital signatures is extremely difficult -- the technology is sound -- but the process of becoming known as trustworthy is difficult. There is little practical experience with systems of digital signatures to guide us. This is an exciting area, but it needs patience before success.

Soft spot #4:
Interaction with the environment

Java's early applets displayed animated characters or other kinds of standalone applications like scrolling ticker tapes. However, real applications require interaction with the environment, such as saving and loading data from relational databases, support for client/server architectures, and connections to existing software and infrastructures. All of these actions can be done with Java, but each requires an error-prone and labor-intensive process. Fortunately this is one of the fastest moving areas of Java and one with relatively low risk for early adopters.

SQL database access

To enable access to SQL databases, Java has been extended with the JDBC (Java Database Connectivity) layer. An "ODBC bridge" has been developed to access ODBC-compliant databases. JDBC is available and it is likely to receive extensive early testing, lowering the risks of leveraging existing investments in relational databases using Java. JavaSoft and its partners are also working on a transaction model, called [Java Transaction Services] (JTS) API, which is based on the OMG transaction model, and which has been proposed as a standard for doing transactions in Java. JTS, of course, will take longer to reach maturity.

Client/server architectures

To separate portions of an application into client and server parts, early Java applications had to resort to setting up a private socket connection between the client and the server and had to develop proprietary protocols. That is no longer necessary. If both client and server have been written in Java, the suggested communication mechanism is the Java remote method invocation (RMI) API. A special RMI compiler takes a Java class and quickly creates code for object proxies on both clients and servers. For heterogeneous environments (for instance, a client in Java and the server in C++), the OMG's Corba is a more appropriate route. With Corba, the interface is described using the Corba interface definition language (IDL). A special compiler tool translates the IDL into Java stubs. Both RMI and Corba are easy to use. RMI is part of JDK 1.1. A product version of JavaIDL is expected later this year. Of course, third-party products, such as OrbixWeb from Iona Technologies Inc., Cambridge, Mass., already work well. JavaSoft and OMG recently agreed to jointly upgrade Corba Internet Intra-Orb Protocol (IIOP) to support Java RMI-like advances.

Incorporating legacy code into a Java application

A Corba-based system with Java on one end and a legacy system on the other can be a solution to connecting Java to existing systems. When faced with a lot of legacy code that needs to be enhanced or extended with a Java interface, the code can also be accessed directly from a Java application through native methods, or methods in a Java class for which the method signature is specified in Java, but where the actual method body is written in C. The C code is compiled and supplied in executable format (typically in the form of a DLL). Because the native method is platform-specific, platform independence is lost (the applet can no longer automatically be executed simply anywhere, because access to the DLL is required). However, in cases where the existing code is large (and takes long to rewrite in Java), and the resulting Java application is expected to execute at a specific location, this approach may be acceptable.

Another combination can use Java RMI: a client could be written as an applet in pure Java, connecting via RMI to a Java server that uses native methods to access the underlying C and/or C++ code. This process avoids using native methods in clients (applets), directly avoiding the need to compile native code and to install the DLLs for each foreseeable client platform. It also moves all communications code into Java to simplify the creation of a distributed system.

Soft spot #5:
Applet download time

Java is a great language in which to write platform-independent code, which can be downloaded to a browser in the form of an applet. Downloading these applets over the Internet, however, can be a lengthy process. This section investigates some of these issues. A real-world example of the current applet downloading model is the Corel Office Suite for Java from Corel Corp., Ottawa, Ontario, Canada. The now free downloadable beta version contains about 2,000 Java class files, which add up to roughly 11Mb. With current network bandwidth, it is practical to only use the application on a high speed LAN. Of course, this environment was the design point for Corel, but a system that requires access over phone lines requires a more modest client.

Caching of Java bytecodes

Currently, browsers do not cache Java byte code files. Images and HTML pages are cached locally, so that a next hit to the same page is much faster. In contrast, when a page containing an applet is accessed multiple times in sequence, the applet is not cached, but is downloaded every time, even when the code hasn't changed. Applets quickly reach sizes in the hundreds of kilobytes, and multiple HTTP connections may need to be made by the browser to download the entire applet. On slow (modem) connections, this behavior becomes an issue. Expect browsers to implement caching in the winter of 1997.

Ziploading

Both Netscape Navigator and Microsoft's Internet Explorer support the mechanism of putting multiple class files for an applet into one package. Currently, Netscape Navigator supports non-compressed zip-files as an archive. Microsoft IE uses a different archive model, cabinet (CAB) files. CAB files are compressed, and therefore, are smaller than uncompressed zip-files. A different tag is used to specify the name of the archive file and applet writers need to support these conflicting models if they want their applet to download as fast as possible. JDK 1.1 contains the notion of Java archive (JAR) files, which is a specification for compressed zip-files. Both JAR and CAB files support digital signing and encryption. Expect to be able to download applets efficiently before the end of this year.

Only one archive tag per applet

The Java applet download model (really a policy shared with a browser), is that anything that an applet needs which is not in the set of core libraries needs to be downloaded before the applet can run. While class files are collected into an archive, current HTML tags allow the specification of only one archive file. That means the browser will have to download either nothing or everything. It would have been better to let the user specify a search path for the browser to find class files. The result would be that different applets could use the same reusable set of Java classes and they could load their own specific bytecodes from their own location. A second applet, using some shared common code downloaded by the first applet, will load much faster. Download times would improve. I am not aware of any plans to change the HTML tags to enable Java developers to specify multiple archive files; the closest effort is the expansion of the Java core libraries as one form of common code.

A different distribution model

An alternative, very promising software distribution model is Castanet from Marimba Inc., Palo Alto, Calif. A tuner is installed on the client's desktop and automatically downloads an application from a channel transmitted by a Castanet transmitter. Each component in the application is fully versioned, and at regular intervals the tuner checks with the transmitter to see if the application has released a new version. If any component of the application at the transmitter has been updated (either Java class files or data files), the tuner only downloads those that have changed and that are necessary to make the client's local copy up-to-date. As a result,Castanet upgrades applications automatically and incrementally. When downloaded, the application resides locally on the desktop, and can be run without a network connection, or even a browser. Downloads can happen at specific time intervals. Netscape Communicator (release 4.0), is equipped with NetCast, a distribution model partly based on Marimba technology.

The asynchronous Castanet download model looks very promising for downloading data. For instance, the daily online edition of the New York Times could be downloaded right after 4 a.m., so that it is available to be read commuting in to work on the train. But programs are another beast entirely: upgrades of the key productivity applications every day at 4 a.m. sounds like a nightmare of incompatibilities and bugs. This topic will be revisited in soft spot #8.

Soft spot #6:
Java decompilation

"Write once, decompile and steal everywhere." When Java source code is translated into bytecodes, major aspects of the original structure are still available. Except for the names of local variables in a method, the names of classes, fields, and methods remain visible in the resulting bytecode. Although code fragments such as Java for-loops have no one-to-one equivalent in bytecode instructions, smart de-compilers are able to recognize common control-flow expression patterns, and are surprisingly successful at turning compiler-generated bytecodes back into Java source code. The risks here are often overblown, as few software technologies can be easily replicated. Nevertheless, Java systems are more exposed because they actively support the distribution of computing.

Available commercial tools

Naturally, compilers or post-processing tools can make it hard for decompilers. Step one would be to mangle all names in applications, renaming all classes, fields, and methods into random names. If that is not enough, common bytecode patterns can be obfuscated by moving statements around, inlining code, or even inserting dummy statements. Using one of those various commercial tools that can effectively protect the intellectual properties of a company can more than adequately resolve the Java decompilation issue.

Soft spot #7:
Language and API issues

The Java language constitutes a carefully balanced combination of many different modern programming language paradigms. Java borrows the best things from languages like C++, Objective C, and Smalltalk, while at the same time excluding the less used and more complex elements. That makes the language easy to learn for C++ and Smalltalk programmers, but the simple, logical structure also makes a short learning curve for newcomers.

A second component to the Java environment are the APIs. In this section issues/problems with the APIs will be discussed, which indicate that the Java libraries have some rough edges programmers should be aware of, as no imminent resolutions are expected.

Setting an element

Java has support for vector and strings, both of which allow the insertion of an element in a vector or a character change in a given string. The signature for the vector method is setElementAt(Object,int), while the string version is setCharAt(int,char). The difference is that the index sometimes is the first parameter, and other times is specified in the second parameter. This is inconsistent, and can lead to confusion and recompilation.

Getting the size of things

The three most often used elements in the Java languages happen to be very similar. They are vectors, strings and arrays. Each represents a sequence of elements, yet each has its own specific behavior and strengths. All three implement a mechanism for getting the current size. For the vector it is a method with signature int size(). The String class also uses a method, yet is called differently: int length(). Finally, arrays don't use a method, but have a field: int length. These dissimilarities are quite unnecessary.

All generic data structures, such as vectors, hashtables, and strings are threadsafe in Java. This means that designers of the generic classes decided to prevent potential problems by making all access methods synchronized. Thus different threads in an executing Java program cannot manipulate a vector or a string at the same time. Unfortunately, current implementations of the Java virtual machine control such access through expensive mechanisms. One approach is better synchronization mechanisms; new work is expected in this area in 1998. Another approach is illustrated by the Java Generic Libraries. Here the synchronization policy is left up to the programmer rather than enforced by the implementation of core data structures. This is a riskier model, but one likely to improve performance.

String manipulation

Strings are represented by objects, can be passed around, can be manipulated as objects, and are directly supported in Java. To give strings similar semantics to basic types when being passed to methods, they were designed immutable. That means that no methods exist that change the value of a string. Further, the class has been declared final, so that no subclass can be declared to make strings mutable either. Consequently, manipulation of strings involves creation of multiple objects, which can be expensive. This is again an issue of the Java design seeking a simple model that can address most cases.

Soft spot #8:
Version of the Web Week

Java's unprecedented rapid adoption combined with downloadable upgrades on the World-Wide Web opens another soft spot for Java -- version mismatch. Fortunately, the specification of the Java virtual machine bytecodes has proven stable since Java was released. The libraries and Java language specification are a different story, with significant changes between the 1.0 and 1.1 Java systems.

In its official guideline of how to write (JDK 1.0.2/1.1) compatible software, Javasoft admits: "Even when every browser sold supports 1.1, users will take a while to switch to the new browsers." One way to make JDK 1.1 applets work in an older JDK 1.0.2 environment is to use "try-catch" blocks around the code that uses 1.1 specific APIs. This code is difficult to build and maintain.

In a perfect world one can imagine that all users are instantly and simultaneously upgraded. The best there is in practice is JavaSoft's upgrade policy. Java licensees are obliged to implement the full Java specification within six months of the release of a new Java version. That means that in transition stages vendors have different production schedules and different versions of Java. Further, individual users (or I/S departments, for that matter) may not upgrade to the latest release or decide to skip an upgrade. In any case, multiple Java system versions will need to be supported. This is not just a matter of system maturity, but more a reflection of software development in a highly connected and evolving world. Java exists in the most fluid software arena.

Soft spot #9:
Inconsistent implementations of Java

The combination of Java's rich core libraries, portability, and support for Internet computing in today's volatile computing world exposes another soft spot: inconsistent implementations of Java. Ambiguous or inconsistent language and library definitions are inevitable in this environment. Currently, for example, browsers from Microsoft and Netscape have Java virtual machines that are subtly different, simply through different interpretation of the same virtual machine specification. Developers must learn to avoid dependencies on the differences.

Ultimately the solution for these problems is an international standard and a matching test suite, such as the one already started on by JavaSoft. On June 5, the US. Technical Advisory Group (TAG) to the International Standards Organization /International Electrotechnical Commission Joint Technical Committee 1 (ISO/IEC JTC 1) voted "No, with comments," on whether Sun Microsystems should be allowed to use the JTC 1 process designed to enable established technologies to be recognized as international standards. The vote included a comment that sums up the unrealized potential: "Standardized Java will open a huge range of possibilities for any organization that uses computers." In the meantime, JavaSoft does supply an initial test suite, the Java Compliance Kit which should help reduce implementation dependencies.

Soft spot #10:
AWT

The graphics library that accompanies the Java distribution, the Abstract Window Toolkit (AWT) uses a "peer" approach, meaning that Java GUI elements are implemented by native widgets. For instance, an AWT button is implemented as a Win32 button on Windows and as a Motif button on Unix. Because the peers behave differently on each platform, it is difficult to write an application that behaves exactly the same on all platforms. Furthermore, AWT only supports a limited number of widgets.

These problems have led some Java newsgroup flamers to claim that AWT is the "Awful Window Toolkit." While this needs to be balanced against AWT's obvious success as the Web's first graphics toolkit, it is indeed a challenge to write reliable, professional scope applications using AWT. Many developers resort to writing their own tab control, image buttons and scrollbars.

Javasoft has begun overcoming the limitations of AWT with the Java Foundation Classes (JFC). The classes began with Sun's "Swing-set" of lightweight widgets and pluggable look and feel, then grew through a joint-development project with Netscape, Lighthouse Design Ltd., San Mateo, Calif., and IBM. In JFC, elements like buttons are now emulated and drawn completely in Java, ensuring the same behavior on all platforms. Moreover, JFC includes more widgets than AWT. JFC will be part of JDK 1.2, due to ship this winter. JFC should be in all major Java-enabled browsers by the summer of 1998.

Soft spot #11:
Complexity

Finally, Java's deepest soft spot: it is enmeshed in this incredibly complex Internet world with myriad technologies that change daily (See Java checklist). To merge Java into this world and make it useful for corporate use, many new APIs were introduced in JDK 1.1. The additional Enterprise APIs make Java more powerful (almost turning it into the software version of the Swiss Army knife). However, this larger number of libraries drastically increases the learning curve, which used to be so easy to climb. It takes considerable study to learn and understand all APIs. Even David Flanagan's "Java in a Nutshell" no longer fits in a single volume.

Expect the "avalanche" of APIs to ease off by the end of the year with the release of JDK 1.2. After that, updates to Java will be targeted to fixing known bugs, making Java more efficient, and transforming more native code into Java itself. Furthermore, there is unnecessary replication of code in the implementation of RMI, reflection, and class loading. All these issues will be addressed while users get a change to catch up with the new capabilities of the language. This will make the Java development environment somewhat more stable, but nothing can fundamentally simplify the new Java world. The promise and excitement of ubiquitous network computing carries the price of learning wild new systems every day. The world is complicated: enjoy it!

Acknowledgments

This paper has benefited from the excellent suggestions from John Barton, Lee Nackman, and Jim Russell of the IBM T.J. Watson Research Center.

Chris Laffra's "Java-expert check-list"

This could serve as a check-list for persons claiming to know Java. Visit http://www.research.ibm.com/people/l/laffra/ for answers.

Which of the following 100 acronyms and keywords apply to Java?