Java: The Legend

Chapter 1. History and Retrospective

The first public release of Java was May 23, 1995, as an alpha available only on Sun Microsystem’s Solaris operating system. Since that first release, Java has developed into one of the world’s most widely deployed programming environments. It has gained traction and market share in essentially every programming environment, especially enterprise software, server-side Web development, and mobile phone programming.

Java is a blue collar language. It’s not PhD thesis material but a language for a job.

James Gosling

It has been a long journey with many surprises along the way. That journey started in the early days with James Gosling and his team, who were sure that developers wanted advanced productivity features (such as object orientation and garbage collection), but felt that many engineers were scared off by the complexity of the languages that implemented them.

The High-Level Design of Java

In language design terms, Java has always been based on a number of deliberate, opinionated design decisions with specific goals in mind. The Java platform’s initial primary goals can be summed up as:

• To provide a container for simple execution of object-oriented application code

• To remove tedious bookkeeping from the hands of developers and make the platform responsible for accounting for memory

• To remove C/C++ platform security vulnerabilities wherever possible

• To allow cross-platform execution

Notably, these goals were pursued even at the expense of low-level developer control and performance cost in the early years.

By almost completely eliminating the cost of porting, Java allowed developers to focus on solving business problems.

Georges Saab

The portability goal was enthusiastically referred to as “Write Once, Run Anywhere” (WORA). It represents the idea that Java class files could be moved from one execution platform to another and run unaltered. It relies on the existence and availability of a Java Virtual Machine (JVM) for the host platform. Porting Java to a new platform thus becomes a matter of implementing a JVM that will run on the new platform in accordance with the virtual machine specification (usually called the VMspec).

A Brief History of Java

The world that Java arrived into was very different to the one we live in today. Microsoft was counting down to their August release of Windows 95 (which would launch without a Web browser). Netscape was yet to go public (IPO) on the NASDAQ exchange, although its browser was steadily gaining in popularity. The Internet, as a whole, was yet to truly enter the public consciousness.

As a harbinger of things to come, Sun’s initial release of the Java language was accompanied by HotJava, a browser intended to compete with the then-dominant Mosaic browser, and to supercede it via the introduction of richer, dynamic applications using Java’s applet technology. Despite this, few could have predicted the impact that Java’s seemingly modest release would ultimately have.

Rapidly growing public interest in the Internet, fueled by Netscape’s IPO and other market events, produced conditions that kicked off a first wave of enthusiasm (and more than a little hype) for Java. This would ultimately lead to some surprising consequences, not least of which was the renaming of an unrelated scripting language to “Javascript” in order to cash in on the public profile of the Java ecosystem.

Since those early, heady days, Java has had a fairly conservative design philosophy and an often-mocked slow rate of change. These attributes, however, have an overlooked flip side—a conscious attempt to protect the investment of businesses that have adopted Java technology.

After the USENIX session in which James Gosling first talked publicly about Java, people were already dancing on Java’s grave.

Mike Loukides

Not only that, but Gosling’s vision has been more than vindicated—the design decisions of Java’s early days are now considered uncontroversial. This provides a clear example of the old software maxim that “the most hated programming languages are inevitably the most widely used.” In Java’s case, that extends to the plagiarism of Java’s ideas and design principles.

As one example, very few application developers would even try to defend the opinion that memory should be managed by hand these days. Even modern systems programming languages, such as Go and Rust, take it as a given that the runtime must manage memory on behalf of the programmer.

The Java language has undergone gradual, backwards-compatible revision but no complete rewrites. This means that some of Java’s original design choices, made out of expediency due to the restrictions and conventions of late 90s technology, are still constraining the platform today.

The early years of the 21st century saw the rise of Enterprise Java, pushed heavily by Sun (and later Oracle) as the future way to develop applications. Initial versions of the platform (known originally as J2EE, and more recently as Java EE) were criticized for performance and complexity problems. However, despite these issues, the use of Java in enterpises continuedcto grow at a rapid rate.

Eventually, more lightweight frameworks (e.g., Spring) emerged. As these challengers added features, they inevitably grew in size and complexity. At the same time, the Java EE standards progressed, shedding unecessary layers of configuration, and began to focus on the core needs of developers inside the enterprise.

Today, the enterprise space remains vibrant, with healthy competition between different frameworks and approaches to large-scale development. In the last 10 years, only Microsoft’s .NET framework has offered any serious competition to Java for enterprise development.

Meanwhile, the core Java platform (the “Standard Edition,” or Java SE) was not standing still in the early part of the 2000s. Java 5, released in 2004, was a significant milestone, and introduced major changes to the core language. These included generic types, enumerated types, annotations, and autoboxing.

The standard library and core application programming interfaces (APIs) were also substantially upgraded—especially in the areas of concurrent programming and remote management (both for applications and for the JVM itself).

These changes were judged to be a huge step change in Java’s evolution, and no release until Java 8 would have the same impact on the Java world. Sun also finally dropped the “Java 1.X” naming scheme, and started using the major number instead, so that this release was Java 5.

The waves of change, from language changes in Java 5, to low-level technical upgrades such as on-demand or Just-In-Time (JIT) compilation (Java 1.3), through to procedural and standardisation structures, such as the Java Community Process, or the Java Language Specification, have carried Java forward as a language, platform, and ecosystem.

History of Open-Source Java

This can be seen through the evolution of Sun’s (and later Oracle’s) attitude to community and open-source. Despite declaring huge support for open-source, Sun proceeded cautiously where Java’s intellectual property was concerned.

The Java Community Process (JCP) was set up by Sun in 1998 as a way to bring other companies and interested parties into the development process for Java standards. Sun wanted to bring potential rivals “inside the tent,” but didn’t want to lose control of Java in the process. The result was an industry body that represented a compromise between competing companies that still had common cause.

Responding to pressure from the market and the wider community, Jonathon Schwartz (then CEO of Sun) announced the open-sourcing of Java live on stage at JavaOne 2006. Legend has it that this announcement was done without the full knowledge of his management team. This led to the creation of the OpenJDK (Open Java Development Kit) project in 2007, which is still responsible for the development of the reference implementation of the Java platform today.

Sun now had both a somewhat-open standards process, and an open-source reference implementation for Java. However, the path to an open Java was not completely smooth. The release train for Java 6 was already well underway, and it was felt to be too difficult to try to move Sun’s toolchain and development practice over to an open process. Instead, a drop of code from the in-development Sun proprietary JDK 7 was taken, scrubbed, and released as the seed for OpenJDK 6.

The release was further complicated by Sun’s decision to exempt certain components from the open-source release, citing problems in obtaining agreement from the copyright holders.

Due to this approach, OpenJDK 6 never had a release that precisely corresponded to a Sun JDK release. However, the release train for JDK 7 fixed this process, by quickly moving to an open process and by having all normal commits be made directly into the open repositories from then on. This process is still followed today.

Figure 1-1. The OpenJDK branching process

For some participants in the open Java community, Sun did not go far enough in open-sourcing the platform. For example, the Testing Compatibility Kit (TCK) was not opened, and remained proprietary software. This presented a hurdle for non-Sun implementations of Java, because an implementation must pass 100% of the TCK in order to be certified as a compatible implementation of Java.

The Apache Foundation started an open-source, cleanroom implementation of Java in May 2005, and by the autumn of 2006 it had become a top-level Apache project called Apache Harmony. When the project was underway, Apache approached Sun for a TCK. While not outright saying “No,” Sun dragged its heels over the request. This was particularly true with respect to the “Field of Use” restrictions that Sun had added to the Java SE TCK license, which prevented Java SE from being legally run on a mobile phone.

Finally, on April 10, 2007, the Apache Foundation sent an open letter to Sun demanding an open-source license for the testing kit that would be compatible with the Apache license, rather than the GNU Public License (GPL) that OpenJDK uses. Sun did not produce a suitable license, and the dispute rumbled on.

Harmony would go on to be used as the basis for Google’s Android application programming framework for mobile devices. As of 2015, it is still the primary standard library for Android developers.

After the release of Java 6 in December 2006, Sun embarked on an ambitious plan for Java 7, which was to grow as time passed, so that by late 2009 it included a proposal for some much looked-for major new features.

These included:

• Lambda expressions, and with them a slightly more functional style of programming

• A completely new system of modularising and packagaing Java classes to replace the aging Java Archive (JAR) format that was based upon ZIP files

• A new garbage collector called Garbage First (G1)

• Enhanced support for non-Java dynamic languages running on the JVM

Many in the community began to question when, if ever, version 7 would actually arrive. However, they were soon to discover that Sun (and Java with it) potentially had far bigger problems than just an endlessly slipping release date.

The Age of Oracle

By 2009 it was clear that Sun’s revenue and profits were in serious trouble, and Sun’s Board began to seek buyers for the business. After talks with IBM (and allegedly HP) failed, Oracle emerged as a buyer, and made a substantial offer in the spring of 2009. Upon obtaining approval from the US and EU governments, the acquisition of Sun was completed on January 27, 2010.

The first few months following the acquisition contained a few upsets and high profile departures from Oracle (including James Gosling, the original inventor of Java). Outside of the Java space, Oracle fared badly, and was seriously criticized for its handling of some of the open-source technologies they had acquired from Sun.

In the Java space, trouble was to arrive late in 2010 when negotiations between Oracle and Google over licensing the Java technology used in Android broke down, and Oracle sued Google for copyright and patent infringement.

The ecosystem was to receive another shock, when Apache officially withdrew its membership of the JCP after Oracle refused to grant Apache a TCK license for Harmony under acceptable terms, despite having supported Apache against Sun in the original dispute. The Harmony project struggled on until November 2011 before finally choosing to disband, with Android being the only real inheritor of the technology.

Apache has not, as yet, returned to the JCP, but many of Apache’s projects are implemented in Java or other JVM languages. The Oracle/Google lawsuit was to rumble on until May 2012, when the judge found decisively in favor of Google (although some minor aspects of the case continue in the appeals courts).

With the effective end of the Oracle/Google lawsuit and the initial uncertainty regarding Oracle’s stewardship of Java fading, the Java platform seems to have settled into a period of relative calm.

On the engineering side, this has been seen in several places—most clearly in that the monolithic plan for Java 7 was cut into more manageable pieces. First, some relatively simple features and internal engineering work were shipped as Java 7 in July 2011. Next, the lambda expressions and functional programming support followed as part of Java 8 in March 2014. Finally, the long-delayed modularity support is intended to arrive as part of Java 9, which is expected to be released in September 2016.

Retrospective

To conclude this chapter, let’s try to put some of this history into context, remembering of course that hindsight is 20/20. Nowhere is this more apparent than with Moore’s law, the hypothesis made by Intel founder Gordon Moore to the effect that: “The number of transistors on a mass-produced chip roughly doubles every 2 years.”

This phenomenon, representing an exponential increase in computer capability since 1965, has had transformative effects on computing (and knock-on effects to human society). Java has been a particularly fortunate beneficiary of the availability of an increasing amount of computer power.

Software is eating the world.

Marc Andreessen

Long term bets in software have always been notoriously difficult. For example, the decisions made by many national governments to standardize on Microsoft in the early 90s proved to be exceptionally expensive, and provided a very powerful advantage to the vendor in winning additional work.

Java has benefited from some early design decisions, that could be seen either as prescient or very lucky. The WORA approach provided a platform-neutral approach at a time when few predicted that the Intel family of chip designs would become dominant across essentially the entire industry. It also protected Java from being locked in to a single operating system.

Moore’s law also aided Java by providing a free lunch in terms of computing capability. The processor intensive aspects of the modern Java platform, such as Profile Guided Optimization (PGO) and JIT compilation, are only possible because of the incredible growth in power of processors.

The Java design principle of backwards compatibility has also proved to be very helpful to Java. Large companies have felt confident about investing in Java as a platform in part because of the visible commitment to maintaining older versions and not breaking working code by platform upgrades.

Java has also been less fortunate in some areas, partially because of its early success. Many large, slow moving organizations (including more than a few governments) adopted Java applets as a standard technology for accessing systems over the Web.

Applets are a technology that are very much of their time, and they have not aged well. The technology proved to be very difficult to evolve, and so applets have not been considered to be a modern development platform for many years now. However, they doggedly persist due to some large early adopters being very resistant to change. The resulting effect to the ecosystem is that Java applets are still present in the platform, and are a major contributor to security problems.

As we reach Java’s 20th birthday, some observers have begun to talk of “the second age of Java.” Java’s high performance, stability, and large numbers of developers are making it an attractive choice for many software projects. Not only that, but many of the most interesting new languages (such as Clojure and Scala) are implemented on top of the JVM.

Will Java be around in a recognisable form for its 30th (or 40th) birthday? The future is, of course, uncertain, but on the current evidence, it seems entirely possible.