MAY/JUNE 1997 (Vol. 17, No. 3) pp. 10-13
0272-1732/97/$31.00 © 1997 IEEE
Published by the IEEE Computer Society
Published by the IEEE Computer Society
Guest Editor's Introduction: Java's Open Future
|Java: open or closed?|
|The open development process|
|Example: JDBC API|
|Open, barrier-free specifications|
|The open road ahead|
PDFs Require Adobe Acrobat
It seems impossible to talk about the Internet, corporate intranets, networked devices, or even consumer electronics without talking about Java. Seemingly overnight, Java has established itself as the de facto standard platform for building networked applications.
Vendors have adopted the Java programming language more quickly than any other programming language in history. Industry, government, and academia recognize the Java Platform as a key technology for supporting platform-independent access to a wide range of information resources.
There are several reasons for this success. First and foremost are the Java technologies themselves. Almost as important are 1) the open development and evolution process that allows anyone to contribute to the future of the Java Platform, and 2) the open Java specifications that encourage both competition and innovation in the marketplace.
While a lot has been written about the Java technologies, the open development process and open specifications have received considerably less attention. Since they are major reasons for Java's success now and in the future, they deserve careful explanation.
When we speak of Java, we typically mean the Java Platform. It consists of three distinct parts: the language, the Java Virtual Machine, and the class files that implement the Java application programming interfaces (APIs).
Sun Microsystems, Inc., first released the Java Platform on March 27, 1995, when it made available an alpha Java version for free downloading at its public Web site. Sun formally announced Java at SunWorld 95 that May. As developers downloaded and experimented with successive alpha and beta releases of the software, interest in Java grew.
The following three months saw major corporations—Netscape, IBM, Mitsubishi Electonics, Oracle, and Microsoft—license the Java technologies from Sun. In January 1996, Sun released Version 1.0 of the Java Development Kit (JDK). By the April 1996 JavaOne developers' conference, it was clear that these technologies had created a huge new marketplace for software developers. Java allowed users to potentially create only one version of their software, and then see it run reliably on virtually all hardware and operating system combinations.
The technical reasons for Java's popularity are easy to understand. First, Java uses a simple model of network computing that is easy to understand and program. It also executes code on remote hosts in a secure way (a critical requirement by many organizations).
Second, Java is a powerful, general-purpose programming language suitable for building a variety of applications that do not necessarily depend on network features. Java's ease of programming, combined with its built-in safety features, helps produce debugged code quickly. Common programming errors like memory leaks, dangling pointers, and incompatible object assignment don't occur, because Java uses automatic garbage collection and type-safe references. Multithreading allows applications to attend to multiple tasks simultaneously, and Java's exception-handling mechanisms provide a model for dealing with runtime errors quickly and efficiently. In addition, the Java language itself is simple, allowing programmers to readily become proficient.
Perhaps the most important aspect of the new Java technology is the promise that it holds for significantly reducing the time and cost of developing software applications. Java was specifically designed to have as few implementation dependencies as possible. For example, the integer data type, int, is a 32-bit, signed, two's-complement integer in all Java implementations (regardless of the CPU and hardware environment executing the Java program). Java defines as much as possible about the language, APIs, and runtime environment. So a program written in pure Java should run the same way, and produce the same results, on every combination of operating system and computer hardware. A developer should be able to write a program once, test it on only one platform, and then rest assured that it will run everywhere.
Java: open or closed?
While Sun probably could have made Java proprietary, it chose to keep with its long tradition as an open systems company and took quite a different approach.
First, it implemented an open process that allowed anyone to actively participate in the development and evolution of the Java Platform. This process has been in place since the release of JDK 1.0 and has proven very successful in achieving broad industry consensus for changes and additions to the Java Platform.
Second, Sun opened up the Java marketplace to competition by declaring its Java specifications to be free of barriers for use and implementation. Over the summer of 1996, Addison-Wesley began to publish a series of books called The Java Series...from the Source. Written by people who have been intimately involved in the development of Java, these books provide detailed interface specifications for Version 1.0.2 of Java. The books contain a short and simple licensing agreement whereby Sun grants the purchaser the right to create and distribute clean-room implementations of the specifications in their entirety.
These books, along with their bound-in license agreements, give readers the complete, detailed interface specifications for the Java Platform. There are no hidden interfaces. Nothing has been deliberately obscured or left out. Readers may implement these specifications in products without legal consequences, provided the entire Java Platform is implemented with no subsetting.
The requirement to implement the entire specification ensures compatibility and interoperability among all such implementations.
These two decisions by Sun resulted in Java's quick acceptance in industry and academia. The ability to write only one version of a program held wide appeal due to the potentially tremendous savings in both program development time and project cost. As of May 1997, there were over 150 major licensees of Java, and it has been ported to most high-volume operating system and hardware combinations. Many companies have made large investments in the Java technologies. Several universities now use Java to teach the principles of computer science to the next generation of software engineers.
The open development process
In conjunction with the release of Version 1.0 of the Java Platform in 1996, Sun implemented a new process to guide the development and evolution of Java specifications. The process is similar to that found within industry consortia and standards bodies, and has been very successful in achieving rapid and broad industry consensus. It allows users of Java specifications to quickly and effectively respond to changing market demands in an industry-neutral way.
While this process has been applied to all aspects of Sun's Java technologies, it is perhaps best understood when cast in terms of Java API developments.
An API usually starts out as a rough outline containing requirements gathered from companies, researchers, and experts with an interest in the API. One or more Sun engineers then turn the rough outline into a draft specification. Sun improves the specification by circulating it for review (possibly under nondisclosure) to a wider range of companies and consultants that have expertise and/or a commercial interest in the API.
After the first review period, Sun works to resolve all comments subject to the need to keep the API cross-platform, industry neutral, and interoperable with all other Java APIs.
Once the second draft is complete, Sun distributes it to all Java licensees for review. Licensees have an excellent working knowledge of the Java Platform and can provide invaluable insights into how the new API might interact with existing and planned APIs. Many licensees, including Microsoft, IBM, Netscape, Novell, and Fujitsu, have provided comments and suggestions for improvement.
Following the resolution of comments from this third round of review, Sun opens the API to public review by posting it for free downloading at java.sun.com. The public can comment by electronic mail and in writing to make it easy for everyone to participate. Anyone can access the latest API specifications open for review at java.sun.com/products/api/index.html.
Example: JDBC API
This process of reaching consensus on API development and evolution has proven extremely successful in practice. It has allowed Sun to rapidly develop usable APIs that have wide appeal. Consider the development of the industry-endorsed JDBC (Java Database Connectivity) API.
In late 1995, two Sun engineers perceived a market need for Java database connectivity. After initial consultation with industry leaders Visigenics and Oracle, the engineers settled on a model similar to ODBC (open database connectivity). They created a rough outline (with requirements) for the JDBC API and completed it on January 1, 1996. During January and February 1996, they worked with industry experts and then the Java licensees to refine and improve the specification. The public review period ran from March to June 1996. After incorporating suggested changes, Sun released the beta version of the specification for public comment in July 1996.
Sun released the final JDBC API specification in September 1996. It met with immediate industry endorsement and acceptance.
Open, barrier-free specifications
Sun has always been publicly committed to barrier-free specifications, and this is certainly true for its Java technologies. As mentioned earlier, barrier-free specifications meet two important criteria: The specification is free of barriers for use by others, and it is free of barriers for implementation by others.
To be considered free of barriers for use, the specifications must have no cost associated with writing applications that program to the interface associated with the specification. That is, there are no royalties or fees for use. Further, the entire interface must be fully disclosed and well documented. This means that specification authors cannot deliberately keep secret or intentionally obscure portions of the interface.
Many industry APIs meet this condition today. Users don't have to pay the vendor if their application calls any of the methods or functions defined by that vendor's API. Also, the documentation provided by the vendor fully describes the methods and functions that make up the API.
The second condition is much harder to satisfy because it involves allowing open competition. To be considered free of barriers to implementation, there must be no cost associated with a third party creating its own implementation of the interface described by the specification. The only exception is possibly the cost of purchasing a (reasonably priced) copy of that specification.
Thus, a barrier-free specification means that a company must 1) fully disclose the interface specification (and not charge anyone who programs to that interface); and 2) the company must also allow others to build and sell implementations free of charge. In effect, the original company must willingly allow others to compete against it in the marketplace on a level playing field.
The open road ahead
The Java Platform has been an international success for two main reasons. It provides innovative technologies, and Sun provides an open development and evolution process for Java and barrier-free Java specifications. Together, these guidelines form a strong foundation that will ensure the continued growth and international acceptance of Java now and in the future.
I've dedicated this special issue of IEEE Micro to the Java Platform. It celebrates Java's remarkable, two-year ascent from a little-known research project inside Sun Microsystems to an integral part of the computer industry and a de facto standard for building networked applications. I thank each of the authors for generously agreeing to contribute to this special issue.
As I was seeking prospective authors, I found that almost everyone in the industry with an interesting story to tell about Java was either deeply engaged in Java development work, racing to get a product to market, or busy preparing for the 1997 JavaOne developers conference. This was certainly a testament to Java's popularity and its growing importance in the software development community. However, it made it very difficult for many authors to complete their articles by the publication deadline. You should look forward to seeing those articles in future issues of IEEE Micro as part of the special Java track that is being established.
Ken Urquhart is a member of the Office of the Vice-President, Technology and Architecture at JavaSoft (a Sun Microsystems business). Previously, he was the senior scientist at ComVista Internet Solutions, a research scientist at Alaska Airlines, and the head of Academic Distributed Computing at Simon Fraser University. His research interests include object-oriented databases, programming languages, digital image manipulation, the growth and characterization of ultra-thin films, and ferromagnetic resonance in the ultra-anomalous limit.Urquhart received his PhD in physics from Simon Fraser University. He has authored or coauthored over 40 publications in physics and computer science, and carried out research at the University of Tokyo and Japan's National Laboratory for High Energy Physics. He is a member of the ACM and the IEEE.