Please feel free to forward this newsletter to as many friends as possible. I have a personal goal of having one million readers. I can achieve it with your help.

the Software View: Java is dead ... Long live Java!

Welcome back, gentle readers. Your intrepid reporter and faithful correspondent has traveled across the Atlantic Ocean. All in an effort to bring you excellent content.

You may be asking yourself, "Who is this person? And why is he sharing the stage with representatives from Bloor Research, BEA Systems, Intel, IBM, and Progress Software?"

Please allow me to have the privilege of an introduction. My name is Mark Kuharich. I currently serve as a software design engineer specializing in Java software technologies working in the United States of America, across the drink, across the pond, across the Atlantic Ocean, and far removed from this wonderful Paragon Hotel. I achieved a Bachelor's of Science degree in Computer Science from the United States Military Academy at West Point, New York. At one time, I formerly served as a full-time employee for Microsoft Corporation in Redmond, Washington. I helped them ship the Internet Explorer web browser version 4.0. Now, I spend all of my time learning and using Sun Microsystems' Java software technology platform.

I am also the Editor-in-Chief and Publisher of the Software View, a free, no cost, e-mail and web-based newsletter with articles, commentary, and my views of developments in the software world. I have a personal goal of having one million readers.

For those of you with Internet and World Wide Web access and a Netscape Navigator web browser, please point your browser to:
http://www.softwareview.com/
Scroll down the page and you will spy a link entitled, "Current views web log (fresh news daily! Click reload, clear the browser cache)" The daily news page is also known as a "web log". It is en vogue and the fashion of these days to call it that. Click on the link, click "reload" on your browser or clear your browser cache to ensure that you always receive the freshest, hottest daily news concerning Java, Linux, XML, and the software industry! The link never changes, but I will be updating the HTML file page behind it every day. Please, do take a gander at it every day.

Also, some important news, gentle readers. the Software View is now an Associate Internet World Wide Web site of Amazon.com. I would like to extend my sincere, heartfelt gratitude and thanks for your patronage. I am offering links to books, et cetera that you can purchase from my web site. I would greatly appreciate it if you would purchase software industry books from my web site. Help support my newsletter and web site by purchasing items from Amazon.com from my web site. Here is the URL (Uniform Resource Locator):
Click here

Now, dear readers, on with this week's episode of the Software View!

I had to travel all the way to London, England to give this keynote address. It was a good feeling to be returning to "Ol' Blighty". As a service to my readers, I would like to offer you a British (Cockney) to Yankee American dictionary/translator. Andrew Rookley was generous enough to e-mail me a third column. So, without further ado, I present to you a British (Cockney)/Yankee American/Canuck dictionary/translator. If you would like to submit any corrections or additions, please send an e-mail to thesoftwareview-owner@west-point.org.

Now that the software design engineers at Sun Microsystems' Java Software Division have not only shipped the Java 2 Enterprise Edition version 1.2 but they have also shipped the new Java HotSpot virtual machine technology, I asked them what they were doing now. Here is their list:

• We are going to DisneyLand!
• Evangelizing open systems versus proprietary solutions.
• Designing and development for a long life-cycle system.
• Hard-core production headless remote system management from a distance.
• Nerf weaponry: open discussion.
• Discussing how to manage upper management.
• Bug-tracking: as if they write buggy code!
• Sleep: myth or necessity?

Now, dear readers, on with this week's episode of the Software View!

My talk this afternoon is entitled, "Java is dead ... Long live Java!"

Java is a software technology platform invented at Sun Microsystems, Incorporated and created by Doctor James A. Gosling. It consists of not only the Java programming language itself, but also of the Java virtual machine and its associated core Java Class files and applications programming interfaces, or API's.

Java has the potential of becoming the de facto programming language for the Internet and World Wide Web, and the standard for cross-platform executable content. Its mantra is "Write once, run anywhere". Java annihilates the switching costs associated with portability between operating systems for software applications.

But, I did not come here today in praise of Java. I came here to bury it. Java is dead. Java is whistling past the graveyard. Here are the reasons why Java is dead. But, the Java emperor has no clothes. Here are the reasons why Java has no clothes. You can put a fork in Java because it is finished.

Java lacks true platform independence. This is a myth. The only two platforms that Sun targets for the latest, major releases of the Java Development Kit (JDK) are Sun Solaris and Windows. Sun leaves Java implementation upon other platforms to its partners. As a result, there is always a significant lag time between Sun Solaris versions of key Java software technology and versions for other operating system platforms like Linux, the Macintosh, and HP-UX. Java's client-side story is a joke. I have personally attempted to create cross-browser and cross-platform client-side Java applets. I wanted to ensure that the applets, housed upon different versions of Internet browsers and different versions of operating system platforms, all returned a uniform look, feel, and behavior. The frustration involved to perform this Herculean endeavor made me want to pull my hair out.

Jim Frost writes, "Like a good Merlot wine, Java has been improving with age - but it is still young, and its youth shows. Yes, you can produce a single executable file that runs pretty much anywhere, but usually you cannot just write the code once and be done with it. You write the code, test it everywhere, tweak it for platforms where it does not work and repeat until you have something that works everywhere you care about. This has led some developers to joke and quip that Java is "write once, debug everywhere." What is worse is that what you gain in development time you lose many times over in testing costs because you have to test on every Java Virtual Machine (JVM) on every operating system platform - potentially dozens of JVM's on Microsoft Windows alone.

In practice, Java applications tend to be so robust that beta testing becomes much more difficult: Most exceptions in graphical user interface (GUI)-based applications are caught by the GUI package - the Abstract Windowing Toolkit (AWT) or Swing, allowing the application to continue operating (albeit with reduced functionality). Often this means that a button or menu item simply does not seem to respond, behavior that is generally not seen as being as serious as dumping the core or locking up the entire machine.

Java's performance is too slow. Java is an interpreted language, rather than one being compiled natively. Java is universally castigated for its poor performance relative to C++. These criticisms are well-deserved. Java achieves barely half the performance of C++ across a typical code base, and Java's GUI libraries are rarely accused of being too efficient. Who is not familiar with the experience of visiting an Internet or World Wide Web site that has a Java applet embedded within it, and waiting interminably for your local web browser's JVM to load and display the applet?

Some of the popular opinion of Java's poor performance is the result of Sun's exploitation of the exploding Internet Web browser market as a Java launching pad and platform. While this got Java into the hands of thousands of developers and millions of users, applets highlight the worst parts of Java (AWT, code and run-time size and raw performance). The ploy worked as a means of reaching critical mass but it totally destroyed any chance of achieving high degrees of stability anytime soon, owing to the mass adoption of very immature Java applet technology. Most Java runtime environments on user systems today are still based on JDK 1.0.2 technology that is more than two years out-of-date, and the dependency upon the Internet web browser vendors to update their technology has seriously impeded the influx of features in newer releases.

The mark-and-sweep garbage collection algorithm used by Sun's existing JVM's is essentially the same as the one used in the first LISP interpreters - it is mid-1960's technology."

Java lacks sufficient development tools. The newness of Java ensures that its development tools are relatively immature and weak. A case in point: Sun's Java Development Kit (JDK) continues to consist of crusty, command-line driven utilities. Java tools and run times used by most developers are primitive and/or buggy. In contrast, Microsoft's Visual Studio development suite is a tool that C++ software developers love. It has been honed through years of experience in learning from C++ programmers and discovering their needs.

There are not enough existing JavaBean software components. The paucity and scarcity of JavaBean components in relation to the abundance of Microsoft VBX, OCX, ActiveX, and OLE components is glaringly obvious.

Java also has questions of database access. Does the Java Database Connectivity (JDBC) specification offer as speedy database access as native database drivers?

Java has questions of scalability. How many threads can you create safely with a Java applet before the JVM loses its mind? Most other multi-threading programming languages provide additional thread synchronization mechanisms, including the mutex and semaphore constructs. It is commonly considered a weakness in Java that it does not provide these synchronization objects.

Is Java even needed at all? Other technologies like Visual Basic, C++, and COM can meet your needs. Plus, it is absurd to ask users to rewrite all their software using Java. The reality is that we live in a heterogeneous world filled with pre-existing legacy software objects written in other languages.

There is also the question of Microsoft's stance concerning Java. The company that possesses the monopoly in the world's desktop personal computer operating systems is clearly not a good citizen within the Java community. The omnipresence of Windows (in one flavor or another) is the reality for developers. Ninety-five percent of desktop applications run under Windows. Microsoft has a ninety-five percent market share of desktop personal computer operating systems and a ninety-three percent market share of desktop personal productivity applications like spreadsheets or word processing. There are and will continue to be a very large number of applications written only for the Windows environment.

Java lacks conditional compilation and a preprocessor. Doug Bell writes, "eliminating conditional compilation actually makes it more difficult to maintain code since entirely separate files must be maintained. Conditional compilation has been useful for debugging code and/or assertions, performance profiling, feature enabling/disabling and demonstration versions, backward compatibility, and making complex changes to a working product."

William Pugh writes, "the Java memory model described in Chapter 17 of the Java Language Specification gives constraints on how threads interact through memory. The Java memory model is hard to interpret and poorly understood; it imposes constraints that prohibit common compiler optimizations and are expensive to implement on existing hardware. These issues are particularly important for high-performance Java applications, since they are more likely to use and need aggressive optimizing compilers and parallel processors. In addition, programming idioms used by some programmers and used within Sun's Java Development Kit are not guaranteed to be valid according the existing Java memory model.

Inner classes were added to Java in version 1.1, in a way that was compatible with version 1.0 Java virtual machines. Given two classes A and B, if one is declared inside the other, or if both are declared inside another class, then A and B should have access to each other's private fields and methods. Since the Java virtual machine doesn't understand inner classes, the compiler produces a modified program in which the private protection of the fields and methods has been essentially eliminated."

At the 1996 JavaOne conference Tim Berners-Lee said, "There's a little worrying note I have that there's a namespace out there for Java classes and it's not an URL space, but it's a different namespace. Whereas in the Web, we have this rule that if you have a namespace or an address space, if it's a good one, then you think of a prefix for it, and you put the prefix and the colon on "my new namespace:-MNSP:" and then you can put whatever you like after it. And so we like to assume that everything about the system, the Java classes, objects that define everything about them, where you can get implementations and everything you can find out there, are listed like everything else. Now, if you look at the class namespace, if Sun.Java, or JavaSoft^TM, or .foo.bodobas is a class name, and that's a good namespace. Well, if that's a good namespace, people might ask: 'Can I put my ping image in it, please?' 'No, it's just for Java classes.' 'Oh, Java classes are different? You mean, they're not first class objects? Oh, they are first class objects. Everything else is second class objects. Sorry, oh yeah, they go in the Java namespace. So if you've got a namespace that only works on one sort of object, then can I put my class in the URL space? Can I put it in the HTTP space or the FTP space? No?' Why don't we just have a set of name and address spaces that you can use interchangeably, and we'll have a set of object types and all these object types we treat as much the same as possible."

There is also the question of whether or not Sun Microsystems can reliably release updates to the Java software technology platform in a regular and timely fashion. Sun's HotSpot JVM technology reminded me of sightings of either the Abominable Snowman, Big Foot, the Loch Ness Monster, or Sasquatch. There are rumors that these exist, but no one has either seen them or can confirm or prove that they exist.

Java does not currently support user-defined operator overloading and there are no signs that it will ever be incorporated into the language. One could speculate that this might change once the ISO standards process gets underway. Java also lacks support for concrete types and lacks support for sophisticated high performance numerical computing. Also, Java's floating-point arithmetic is blighted by five gratuitous mistakes.

Java has not succeeded as a platform both because there is no real demand for an alternative to Windows and because Java is not a platform, except by the widest definition of the term: programmers write to its API's, and applications run on it. From the beginning Sun's problems were its lack of pull with the market creators - that is, the software developers - and, more recently, Sun's waffling on how much of Java to release to independent standards bodies. The result is that standardization efforts have been sluggish.

Bjarne Stroustrup has said, "If users know what language you are using, there is something wrong. You shouldn't be able to tell. I have never liked proprietary languages. You cannot entrust one person or a corporation with the control of a language. You need an open forum for discussion. No matter how open a corporate language claims to be, it will inevitably exclude people who do not play by the same rules as the corporate owner - and those rules may not be in the best interest of the language's evolution.

Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. In 1995, Java had two hundred API method calls, today, it possesses over 1,600. The JDK 1.0 contained 212 Java Class libraries and interfaces in eight packages. Today, Java contains at least 2,000 Classes and interfaces in 98 packages. That is the way every commercially successful language has developed. Just look at any language you consider successful on a large scale. I know of no exceptions (Please pardon the pun!), and there are good reasons for this phenomenon."

Brett Glass writes, "Sun's Java strategy should focus on the JVM. Sun's problems are the result of three strategic mistakes that Sun made at the very outset. Together, these errors threaten to undermine Java fatally and seriously.

The first mistake, as is all too common when avowed technologists attempt to market new products, has been one of positioning. Instead of pushing Java's greatest strength, the "virtual machine" technology that allows an application run on nearly any operating system safely and without recompilation, Sun has cast Java more as a language that just so happens to be cross-platform. This does a disservice to the most important and least known feature of Java's technology: that it is possible to compile nearly any existing computer language - not just Java - to run on Java's run-time engine. By putting the cart before the horse, Sun has neglected what must be one of its primary goals: to enable users to choose its products despite the nearly complete Microsoft Windows monopoly.

Sun's second mistake, which follows directly from the first, is how it has chosen to name Java and its components. Sun gave the language a short and catchy name and called the engine by the much more awkward "Java Virtual Machine". This name perpetuates the illusion that the "Write once, run anywhere" aspect of the technology is secondary to the language. Opponents have capitalized on this tactical error by propagating the incorrect notion that Java is "just a language".

But Sun's most telling error has been its failure to keep complete control of the virtual machine. With legions of programmers and plenty of cash to hire more, Sun should not have lazily allowed other vendors to implement the cross-platform engine. Netscape, Hewlett-Packard, and others should never have been entrusted with this all-important component. Had Sun implemented the virtual machine itself for all the important operating system platforms (as it has now begun to do, belatedly, with its Activator Plug-In technology), it would have had a hot product to license or even sell directly to end users for an immediate gain. (Sun's Java Software Division, which is responsible for Java, has yet to turn a profit.)

What is more, were Sun the sole author (or nearly so) of Java virtual machines, 100 Percent Pure cross-platform compatibility would be easier to achieve, and divergence of the language would be a non issue. Java the language could be released to standards committees with no negative effect on the platform's viability, eliminating the most strenuous objections to Java as a whole. Any language or compiler that created a program for Sun's virtual machines would automatically be able to run on any system, allowing users to choose alternative hardware platforms and operating systems - including Sun's - with confidence."

Sun has done a very poor job of leading and holding the Java movement together as a coalition. Examples of fractures and tears in the seams include: Transvirtual Technologies Incorporated's Kaffe virtual machine, the Hungry programmers' Japhar virtual machine, Cygnus Solutions' Project Mauve, Hewlett-Packard's Chai technology and their movements concerning hard real-time Java, IBM's lack of support for Jini, and Microsoft's complete and total lack of support for Java itself. These are widely viewed as symptoms of disaffection with Sun over its handling of Java licensing, and its dual role as keeper of the Java standard and a profit-making company.

"Sun was way too scared of Microsoft, and as a result they created a contract that didn't help them. Java is in the die-back stage - it's going into niche markets." No less a software industry luminary than Linux creator Linus Torvalds spoke the above quote at the Oracle Open World conference on November 11, 1998. Torvalds is the very personification of the open-source software movement. And his quote bespeaks a damning and profound question: Did Sun Microsystems' tight grip upon and control of Java prevent the software technology platform from achieving success? Though Sun has recently taken some steps toward open-source with Java, GNU Public License (GPL) purists and proponents of BSD type licensing argue that Sun has not gone far enough. Sun still retains tight control over Java. And if you ever contribute Java bug fixes to Sun, there is no guarantee that your fixes will be redistributed to the entire Java community.

For some other Java blemishes,
Click here

Long live Java! Luddites and nay sayers continue to insist upon writing Java's epitaph. As Mark Twain would paraphrase, "The rumours of Java's demise have been greatly exaggerated."

Java is an elegant, modern software technology platform ideally suited for network applications. Java occupies a strong middle ground between the lower-level, performance-oriented languages used by a lot of commercial software, and the high-level languages favored for quick and dirty (for example, departmental) applications. It is easier to use than C++ for enterprise application development and less of a headache than languages such as Visual Basic. Java shares a lineage with other interpreted languages (remember UCSD Pascal?), but it has a couple of things going for it that none of its predecessors had - vast distribution of its core code and runtime engine, thanks to Web browsers, and a serendipitously excellent object-oriented architecture for the needs of distributed computing.

Java was designed for creating applets and applications for the Internet, intranets, and any other heterogeneous, distributed network. Java is simple. The Java automatic garbage collection feature reduces bugs by automatically freeing unused memory. Java simplifies programming by eliminating pointers and automating memory management. These features make Java easier to learn than C++. Java's automatic memory management and simplified structure (no pointers) have made it twice as productive as C++ in many shops. Still, Java has semantic power that rivals C++. And Java is more comprehensive than the various SQL derivatives.

Java is small. Doctor James A. Gosling originally designed Java to run on television set-top boxes. Java is object-oriented. Java employs object-oriented concepts to support reuse of software modules, which will reduce the costs of software application development. The Java language is designed to support distributed dynamic object systems. Java is network-ready versus Windows which grew up on stand alone desktop personal computers. Java was designed from the ground up to build applications that run on networks. The language's semantics address network behavior and multi-threaded execution, a first among widely used programming languages.

Java is robust. Java eliminates problems early by requiring declarations, using static typing, having the compiler perform type checks, and not supporting pointers, which can result in overwriting memory or corrupting data.

Java is secure. Because there are no pointers, Java applications can't access data structures or private data that they don't have access to. This prevents most viruses from taking hold. Applets, when run within a web browser on a local desktop personal computer, can not read or write to the disk, execute programs on this computer, or connect to any other computers except the web server from which they were downloaded. This is called the "sandbox" model.

Java is architecture-neutral and portable. The Java compiler generates an architecture-neutral object file format and bytecode instructions, so Java code can run on any computer that has a Java runtime system. Bytecodes are instructions that are similar to machine code, but are not platform-specific. During execution, the Java virtual machine either interprets the bytecodes or converts them to machine code. Creating separate applications for different computer platforms is no longer an issue.

Java is high-performance. Java bytecodes can be translated on the fly to native machine instructions - for example, by a Java enabled browser. Linking is faster than for C or C++. Once the Java bytecodes are converted to machine code by a JIT compiler in a Java virtual machine, the performance is comparable to that of C or C++.

Java is multi threaded. Java can deal with multiple things happening at once with sophisticated synchronization primitives that are integrated into the language, which makes them easier to use and more robust. If I wanted to perform multi threading in COM, I would have to use some mechanism like a Windows message pump. Multi threading improves interactive responsiveness and real-time behavior, so is critical to high-performance Java applets because applet execution must continue while various image and binary files are being retrieved from one or more web servers. In addition, the ability to control the execution of multiple concurrent threads is crucial for deploying real-world web applications.

Java is dynamic. New packages or module plug-ins can be added to a Java application with minimal overhead. Java can look up a class definition at runtime from its name versus Windows where you must declare other modules in header files and then link in those modules at compile time. Java's runtime environment can load new software modules on the fly into a live environment. This results in applications that can respond to changeable conditions. Java's ability to load classes and components on the fly makes it flexible enough to cope with fluid application demands.

In the business world, Java makes sense for deployment in extranets. Java's cross-platform promise means that you can create applications to use with your customers and suppliers and not have to worry about not having control over the environments they're running. The fact that Java applets are downloaded on the fly eliminates the explicit software installation process and extends their reach. One no longer has to worry that errant DLL's will overwrite any others in the \winnnt\system32 directory.

Another compelling use for Java is in the middle tier logic of transaction-processing systems and database processing - not the servers or the clients but the "business logic" in the middle that actually describes the processes of filling an order or tracking a request. Java's platform neutrality means that you can write code once and have it run on any Java-enabled system. Having the flexibility to move from, say, a Microsoft Windows NT to a Sun Microsystems Solaris Unix server without rewriting code is very beneficial. Java will be the engine of commercial distributed systems. Java middle-tier servers will eliminate two sources of pain in enterprise systems today. First, most organizations are struggling to overcome the barriers between their accounting, customer records, inventory, sales, and other core business systems. The barriers between these systems exist because the applications were built at separate times by separate teams, and often with different technologies. Java will be employed to extend, integrate, and repair existing applications. The Java server will also be the primary request-handling service in the architecture. Java's dynamic nature makes it ideal for servicing a variety of unpredictable requests from users. Java's ability to support a variety of user interfaces will also be beneficial. Java application servers will play three roles:

1. Brokering user requests for services received via Internet protocols (often from the Internet itself). In most cases, the user requests are simple, but satisfying those requests is not.
2. Managing the invocation of application functions and the retrieval of information in response to user requests. Simple user requests require complex actions by databases and other back-end systems.
3. Running business logic that either performs calculations, integrates information, or executes business rules and policies.

Java's ability to load classes and components on the fly makes it flexible enough to cope with fluid application demands. Java will adopt a central role in corporate information processing. First, developers will use Java to build larger and more complex middle-tier applications than are typical today. Next, developers will use Java to manage data on the middle tier, in coordination with production databases. Finally, database developers will use Java to write stored procedures. The availability of Java for creation of logic on all tiers of an enterprise environment will give the skills of development shops leverage that they don't enjoy today. Currently, most shops have at least three groups of specialists, each of which works with a different language or tool. Most development shops build client code with one language (often Visual Basic), databases and database procedures using a second language (usually an SQL variant), and middle-tier logic using a third tool (often C++). Maintaining these three separate skill categories is more expensive than developing a staff with one set of language skills that is applicable to all tiers in an enterprise architecture. The Enterprise JavaBeans applications programming interfaces (API's) will key Java's evolution as a language for both middle-tier logic and database processing. The benefits await you.

Another place Java makes sense is in highly vertical, single-purpose applications that are essentially custom-developed front ends to transaction-processing systems, often as replacements for traditional "host" terminal applications. In these environments, a general-purpose desktop personal computer is unnecessary and even counterproductive.

What about embedded networked electronic devices? Java started out as a language for television set-top boxes. EmbeddedJava is designed specifically for severely resource constrained environments. EmbeddedJava is derived from the Java API, therefore EmbeddedJava applications are upward compatible to both PersonalJava and Java. Developers use EmbeddedJava to create a variety of products including mobile phones, pagers, process control, instrumentation, office peripherals, and networking routers and switches. EmbeddedJava applications run on real-time operating systems, and are optimized for the constraints of small memory footprints and diverse visual displays. EmbeddedJava enables manufacturers of devices to take advantage of the portability and flexibility of Java in their product software. TCI has signed a deal to use Java in its television set-top boxes, and Nokia and Motorola have signed a similar deal to use Java in cellular phones.

Cross-platform support was one of the main areas that Sun improved. They have added the Java look and feel, which provides a consistent GUI across all operating system platforms. Perhaps the most important and significant improvement on the cross-platform support front is the Java Plug In, a downloadable virtual machine browser plug-in. The Plug In ensures that clients using Netscape Navigator 3.x or Internet Explorer 3.x or greater can run Java 2 applications and guarantees consistent behavior from your Java applet or application across major web browsers and operating system platforms.

Java 2 (the software formerly known as the JDK 1.2) has better security features, new Java Foundation Classes (JFC), a Plug-In virtual machine architecture, and better support for the Common Object Request Broker Architecture (CORBA). Also a plus are improved graphics and printing and a new extensible architecture, which Sun dubs the "Java Extensions Framework."

For instance, Sun has refined Java 2's security features to include, for the first time, policy-based access control, as well as support for X.509 (V3) digital certificates. Java 2 is considerably faster. Several performance improvements make that so. One is native thread support for Sun's Solaris operating environment. Also added is memory compression for loaded classes and; therefore, faster memory allocation. Java 2 offers faster garbage collection, synchronized methods for smoother performance, native code libraries that leverage the JNI, just-in-time (JIT) compiler optimizations, and multi-threading support on Solaris. In addition, the JDK's new pluggable virtual machine architecture paves the way for future runtime engine updates.

For developers, long-awaited debugging and application profiling features, such as the new Java virtual machine debugger and profiler interfaces, provide much needed facilities to remotely debug code and monitor application performance. This helps programming teams identify and isolate application bottlenecks, which can then be analyzed and remedied through improved source code algorithms.

Graphics have also been improved in myriad ways. Sun has added an ease-of-development focus with GUI components in the JFC (Swing). Swing enables developers to drag and drop nifty - and standardized - GUI features, such as buttons and dialog boxes, into an application. The idea is to give Java applications a consistent GUI look across all operating system platforms. Java 3D is a standard Java extension that eases development of 3D graphics, applets, and applications, as well as deployment of these across distributed environments.

Java Naming and Directory Interface (JNDI) lets developers add directory-level services in their applications, such as sharing information about users, machines, and applications across a network. Everyone knows the importance of a Naming and Directory Service for distributed systems. JNDI is defined independent of any specific naming or directory service implementation. It therefore provides application portability using this kind of common API across different naming and directory services implementations.

The Java Messaging Service (JMS) specification provides developers with a standard Java API for enterprise Message Oriented Middleware (MOM) services, such as reliable queuing, publish and subscribe communication, and various aspects of push/pull technologies and Quality of Service (QOS). JMS supports the asynchronous exchange of data and events through a common API.

The Java Transaction Service (JTS) ensures that multi-vendor transaction processing solutions interoperate in a Java environment. The Java Transaction API specification consists of two parts: the first provides an API that Java client applications can use to define the demarcation of a logical unit of work or transaction that they want to control. The second part is important to those vendors that implement transaction management products (TP monitors) and resource managers (mostly DBMS and MOM products). It defines Java mapping to XA interfaces (The Open Group standard, which is based on the two-phase commit protocol).

The Java Management API (JMAPI) Service is a set of Java Classes and interfaces that build and deploy management applications. It can be used to build application and system management components at various levels. JMAPI also includes extensions to the AWT, providing pre-built, high-level GUI components like meters and charts that can accelerate the development of a management console for distributed Java applications. The specification also addresses how to instrument individual Java server objects and applets, as well as Enterprise JavaBean (EJB) containers for monitoring and management. Finally, it deals with the protocol that is required to communicate management events within the system management environment, including integration capabilities for SNMP.

The Java Servlet API eases development of server-side Java applications that will run on an Internet Web server. The JavaMail API is a platform-independent and protocol-independent method to build Java-based e-mail applications. The Java Media Framework (JMF) is an architecture that synchronizes and controls time-sensitive data, such as audio and video, used in Java applications.

Object management has been addressed via the Java Interface Definition Language (IDL) API. Java IDL includes an Object Request Broker (ORB) that can interoperate with the de facto standard of ORB's, the Object Management Group's CORBA. Java IDL maps Java to a CORBA-based ORB, which allows Java applications to interact with any CORBA ORB-based application.

Sun released the JDBC specification three years ago to provide a low-level, standard SQL database API in Java to a wide range of relational database management systems. JDBC is based on the X/Open SQL Call-Level Interface (CLI). With JDBC, a variety of DBMS-specific drivers can be accessed through a single interface. Java applications or applets communicate through the JDBC API to a JDBC Driver Manager which brokers requests between clients and database back ends. JDBC 2.0 is now quicker and more stable, thanks to the inclusion of scrollable cursors and support for SQL3 data types.

Java is shaping up to be a boon for visually impaired and physically challenged computer users who cannot easily navigate a traditional point-and-click GUI. Java 2 contains several additions that make it easier for developers to create alternate interfaces and enable Java programs to communicate with existing assistant devices such as screen readers. For example, the Java Swing interface components and Pluggable Look and Feel architecture enable developers to separate an application's GUI from the rest of the program. This permits users to specify different interface components, such as audio or large type, without requiring changes to the basic application. A new Java API - the Speech API - can be used to create a speech-driven interface. For users who want to use existing interface technologies, such as talking screen readers, braille terminals, screen magnifiers, and voice-recognition software, to communicate with Java programs, Sun also announced the Java Accessibility API and Accessibility Utilities.

Frost writes, "Why is Java still making a big splash? In a word, productivity. Java's feature set is such that most developers see a 200 to 300 percent improvement in time to completion versus C++, and much better code reliability to boot. In some cases, such as server-side applications, Java productivity is an order of magnitude better than C++. You can build a Java application two or more times as fast and beat a C++ competitor to market. Java product evolution proceeds on Internet time, a real business advantage.

Where does the improvement come from? Fred Brooks, in his book, The Mythical Man-Month, suggested that high-level languages were going to make big improvements in programmer productivity because "one avoids an entire level of exposure to error, a level on which one makes not only syntactic errors but semantic ones." Java takes the basic C++ language, already a huge improvement over raw assembly code, to another level by providing a number of safety nets for catching errors early and handling errors that make it into production code. The most often-cited Java reliability feature is automatic heap management. It is impossible in Java to accidentally free memory that is in use and it is much more difficult to leak memory. Indeed this may account for as much as half of the productivity improvement over C++, but it is not the only big improvement.

In addition to eliminating errors in heap management, Java requires that all possible exceptions must be explicitly handled or passed to the caller. This feature makes it much more difficult to ignore errors that ought to be caught and handled. As a result, first efforts are considerably more robust than is typically seen with C++. In terms of programmer support, Java's insistence on run-time error checking provides yet another big improvement over C++. Simple errors, such as off-by-one errors, are usually caught in the initial development stage. Even when errors make it beyond the initial development stage, the runtime error reporting includes enough information that a developer can often track down the error even without being able to reproduce it.

Another often-overlooked Java feature that significantly improves programmer productivity is incremental linking. With a halfway decent Make file or smart class builder, a typical Java compile-edit-debug cycle can be managed in a matter of a few seconds. In contrast, a large C++ application can take minutes just to link. This allows a Java programmer to make many more incremental changes to code over the course of a day. The combination of the above features provides a very significant (and much-needed) real-world improvement over C++.

Luckily, several developments since Java's introduction have largely mitigated the performance complaint. While just-in-time (JIT) compiler technology systems boosted Java code performance tremendously, Java has benefited even more from hardware performance improvements. Typical desktop hardware, for instance, is easily four times faster today than it was just three years ago and has four times as much memory. The combination of JIT systems and faster hardware has improved Java application performance by as much as two orders of magnitude, making Java practical across many more applications.

Clearly, we can expect more hardware performance improvements, but what about software? We stand at the brink of some big developments in that area as well. Over the past year or so, a number of native code Java compilers have hit the market, and more are on their way. This is the case where you create your application in portable, cross-platform Java code, and then, rather then remaining with cross-platform Java Classes, you compile your application down to a target platform binary executable file such as for Windows or Solaris. These provide a way for developers to choose performance and already rival the raw performance of C++. These should become far more prevalent in the future.

Sun's HotSpot JVM technology promises improved performance from four major technological enhancements: improved generational garbage collection algorithms, automatic profile-based optimization, look-ahead Java Class inlining, and stream-lined synchronization. HotSpot's hybrid garbage collection mechanism is modern technology that should behave much better that that found in any of the common JVM's, and synchronization improvements cannot do anything but improve the performance of many commonly used Java Classes (particularly the Collection Classes). Paul Tyma writes, "HotSpot is an enhanced JVM that offers an optimizing JIT compiler, fast thread synchronization, and a state-of-the-art memory system (with exact, generational garbage collection) all of which serve to significantly increase scalability and improve performance. The enhanced memory system is not just a state-of-the-art collector, it allocates memory in a flash as well. One of the most tantalizing features of this VM is its non-conservative garbage collector (GC), that is - it is "exact" or "precise". It knows exactly where all the objects in the system reside. The GC is also generational. The GC has two generations, each with their own GC algorithm. The younger generation uses semi-space (stop-and-copy) and the older generation uses mark-compact. It also has mixed-mode operation. That is, it does not always JIT compile code. It is fully capable of running heavily used code after it has been JIT compiled and branching into seldom-used code in interpreted mode. To top it off, it has the ability to optimize code for further performance enhancement. The JIT compiler implements several optimizations that offer a high return on your investment (either because they are easy to implement, have profound effects or both). The optimizations include method inlining, extended basic block-value numbering, common-sub expression elimination, array bounds-check elimination, and virtual-method inline caching.

There have not been a lot of Java performance complaints on the server. Java Servlets and EJB are quite speedy. When I look at Java performance problems on the client today, I am reminded of my days back in college. At that time, I installed a newly released software package called Windows 1.0 on my 80286 desktop personal computer. The performance was so horrible that I hastily un-installed and retreated back to speedy DOS. When I look at slow Java applets today, I see Windows 1.0. Java's performance on the client will improve with time.

Even without further performance improvements, the fact of the matter is that Java is usable for a lot of applications. Some of the most heavily visited sites on the Internet (including Sun's own) use Java technologies like Servlets for HTML page rendering. Performance cannot be too bad if Java Servlets can drive Web sites that handle tens of millions of hits per day - and they do.

The most interesting and potentially revolutionary technology present in Java today is the JavaBean software component architecture and model. EJB are widely supported by Internet Web application server vendors. A "JavaBean" is easily constructed and Java provides an extremely flexible set of tools for manipulating them - two things that, until recently, have been rare in component technologies. They can result in vastly better component reuse and much easier application construction." JavaBeans are geared toward application development and are focused more on the client side, while EJB is a model that deals with the issues surrounding the deployment and management of server-side components.

A JavaBean is a reusable software component that can be manipulated visually in a builder tool. While JavaBeans are focused on the development and application assembly aspects of Beans, the EJB specification addresses the issues that revolve around the execution environment that hosts a Java application. The goal of the EJB specification is to provide an execution environment that gives users all of the required services needed for mission-critical enterprise server applications, without forcing them into a proprietary solution. Server applications that are developed based upon EJB are portable across any implementation of the specification. Conceptually, Sun's Java Software division has focused on defining API's and left vendors to implement this interface.

Javadoc is the Sun Microsystems tool for generating API documentation in HTML format from doc comments in Java source code. It is attractive to be able to produce documentation that is more likely to be in correspondence with the source code and with the same look-and-feel as larger companies with more money would produce.

You may have heard the term, "self-deprecating humor". That is humor that minimizes your importance. A deprecated Java class or method is like that. It is no longer important. It is so unimportant, in fact, that it should no longer be used at all, as it will probably cease to exist in the future. The need for deprecation comes about because, as a Java class evolves, its API changes. Methods are renamed for consistency. New and better methods are added. Attributes change. But making such changes introduces a problem. You need to keep the old API around until people make the transition to the new one, but you do not want developers to continue programming to the old API. The ability to mark a Java class or method as "deprecated" solves the problem. Existing classes that use the old API continue to work, but the compiler can issue a warning when it finds references to deprecated items. Meanwhile, the API comments can warn the user against using the deprecated item and tell the user how to avoid doing so. I like the idea that Java is not afraid to break backward-compatibility when it is necessary to move forward and improve something.

Sun has been taking steps to move Java to an open-source model. A related aspect of the open-source movement is free. Well, first of all, the JDK is freely downloadable. The Java Runtime Environment (JRE) is freely available to be incorporated into any software product. Sun also supplies to universities, colleges, and primary/secondary schools at no charge, unlimited site licenses for many of Sun's most popular software products written in or using the Java software technology platform.

Sun has opened up the source code to its Jini spontaneous networking technology. Sun has also opened up the Java standardization process to non-licensees. Java non-licensees can help define new Java API's across the spectrum of Java Classes. Businesses can use and modify, without charge, the Java source code for commercial software development. Anyone is allowed to make enhancements to the Java source code without turning those enhancements over to Sun; thus, intellectual property rights are maintained. Businesses can modify and freely share compatible source code with other businesses. Sun also gives licensees the right to package Java platform class libraries with virtual machines from other licensees. Sun has also stopped collecting up-front licensing fees from companies that want to use Java. Sun is also allowing companies to make modifications to four base Java Class libraries: io, net, lang, and util. Sun has also announced the free licensing and public availability of source code for the award-winning Java WorkShop development environment. The above technologies, PersonalJava, and EmbeddedJava are all covered under an agreement called the Sun Community Software License (SCSL). It is also rumored that Sun is planning on making the source code to its Solaris computer operating environment freely available as open-source.

Bill Joy, Sun's Chief Scientist and Java's progenitor, champion, its inspiration, its muse, and its guiding spirit, has said, "Most of the bright people don't work for you - no matter who you are. You need a strategy that allows for innovation occurring elsewhere." Sun has made a play for ubiquity, and unleashed innovation within the Java community. By opening up the Java source code, Sun has enabled the next great garbage collection algorithm to possibly emerge from some teenager in Ireland, Japan, or elsewhere around the world.

Long live Java!

Sincerely,
Mark Kuharich

Join my free e-mail newsletter called the Software View by clicking here or sending mail to thesoftwareview-owner@west-point.org