Java: The Legend

Chapter 4. Java Developers and the Ecosystem

Don’t listen to Hollywood. That’s good advice under most circumstances, but when thinking about technology it’s particularly true. The movies would have you believing that tech is all about individual intellectual endeavor.

In fact, the practice of technology has always been a social activity. Even before mass adoption of free and open-source software, the sharing of code and ideas was already a central feature of technology culture.

So it comes as no surprise that any sufficiently advanced technology tends to develop an ecosystem and community alongside it. Once again, Java is both unexceptional, in that a developer ecosystem grew up around it, and exceptional, because that ecosystem evolved into something quite unlike any other language and platform community.

Overview of the Java Ecosystem

Java’s reach encompasses, by most estimates, at least 10 million programmers. This gives it one of the largest and most important developer communities of all. Only the Web/Javascript communities (and arguably C/C++) come near to the size of the Java community.

For serious, safe application development, Java is pretty close to being the only game in town. It’s a robust and stable platform, but despite its size and reputation for solidity, Java does, at times, suffer from an image problem. Being a competent, practical language does not necessarily endear the language to people who are used to working with it all day, every day.

Another issue is that Sun’s early marketing material tended to be overly optimistic in promising benefits for the developer in some areas. The Java developers who’ve been around since the early days are sometimes a little cynical about the platform, and may have battle scars from working with early versions of the platform.

It’s also worth remembering that Java is unashamedly pitched at business and enterprise development. This isn’t necessarily the same cohort of freestyling open-source enthusiasts that are sometimes found in other languages. At the risk of some stereotyping, Java developers are more likely to be the people who code during the day and go home to their families, rather than those who rush off to a hackday in the evening.

This can mean that commentators overlook the open-source parts of the Java ecosystem. On the other hand, even if Java developers are less likely to get involved in after-hours development, the sheer size of the Java community means that there are still a large number of developers engaged in open-source work in Java.

The Java Community Process

Developer uptake was good in the early years after Java’s release, but Sun had bigger ambitions. They wanted Java to become a widespread standard set of technologies, but didn’t have the resources to develop and support all of the integrations and components that would be required by such a broad push. As a result, Sun needed adoption of Java by larger corporations (such as IBM, Fujitsu, and HP).

Many of these companies were concerned by the rise of Microsoft, and Java technology potentially offered an opportunity to hedge that risk. Sun didn’t want to cede control of Java, as it saw huge potential in the technology, and so created an industry body that resembled a standards body. The idea was that standardization would prevent the migration (followed by lock-in) of Sun’s customers to Java technology stacks produced by other vendors.

Founded in 1998, the JCP is a way of formalising and standardising Java technologies. The JCP uses Java Specification Requests (JSRs), which are official working groups, led by a Specification Lead, that produce a specification document, testing kit, and a reference implementation.

The JCP is fairly unique in that it includes a patent and intellectual property regime that protects end users and participants. To participate in the JCP, corporations are required to provide a license of their patents if they are to form part of the standards.

A JSR has a defined lifecycle, whereby the technology standard is worked upon and guided through stages of maturity until it has reached the point where it is ready for widespread developer use. This should ensure that only technologies that are widely adopted enough, and have achieved a degree of acceptance and stability are targeted for standardization.

This has resulted in a process where several different classes of JSR exist. For example, each new version of Java SE, EE, and ME has an “umbrella” JSR that covers the content of the platform release. The most recent release of Java SE was version 8, and the corresponding umbrella JSR was JSR 337. However, these umbrellas usually just bring together JSRs under which major new language features have been developed. JSR 337 therefore included JSR 308 (type annotations), JSR 310 (new date and time libraries), and JSR 335 (lambda expressions).

In addition to the umbrella JSRs, and the JSRs dealing with major new features, there are also JSRs corresponding to major libraries, such as XML parsing (JSR 5) and servlets (various, latest JSR 369). There are also more niche JSRs, that cater to a particular style of programming, such as the real-time specification for Java (JSR 1). Finally, the processes of the JCP itself are specified as JSRs, so occasionally JSRs are filed to modify or update the JSR workflow or practices of the JCP.

The Independent Java Ecosystem

Java has always had an ecosystem of enthusiasts outside of Sun (and later Oracle). In the early years, developers wanted to tinker and explore the limitations of the platform, as is so often the case with open-source hackers. By bumping up the edge of the possible, developers exposed missing features that could be added into future releases, making Java even stronger.

In time, a number of independent projects evolved, and even after the open-sourcing of the platform, many developers chose to continue working outside of the official projects, such as OpenJDK.

Eclipse

IBM had been working to produce an IDE for Java, based on their VisualAge product. This led to the creation of a Java-based IDE for Java, which became known as Eclipse. In late 2001, IBM released this as open-source code, and brought together a consortium of companies to steward the technology. This led to the creation of an independent foundation, the Eclipse Foundation, in 2004.

Although the IDE product remains the principal project for which Eclipse is known, the Foundation actually hosts over 200 other software projects, covering such areas as rich client development and business intelligence and reporting.

In recent years the Eclipse Foundation has continued to grow and diversify, including to technologies unrelated to Java. It also now hosts a major project related to the emerging software technology known as the Internet of Things (IoT).

Apache

The Apache Foundation predates Java. In fact, its initial focus was the Apache web server, httpd. Over the years, Apache expanded outwards from the runaway success of the web server, and became a broad, language-agnostic foundation. The projects hosted under the banner of the Apache Foundation cover almost every aspect of technology where open-source code could play a role.

Not only that, but the open-source license written by the Apache Foundation was enthusiastically adopted by a large number of projects that were not part of, or governed by the Apache Foundation. It’s therefore important to distinguish between “an Apache project,” one that has been officially onboarded as part of the Apache Foundation, and simply “an Apache-licensed project,” which just uses the Apache license.

As Java expanded into many areas of enterprise development and beyond, it was inevitable that some Apache projects would end up being written in Java. However, at least at first, this led to the strange situation of numerous open-source libraries being written for a non-open-source platform. Even after OpenJDK became a reality, the Apache license and the GPL license used by OpenJDK remained irreconcilably incompatible.

The response of the Apache Foundation to these licensing concerns was to begin a complete compatible rewrite of the Java class libraries—Harmony. Despite being a qualified technical success, Harmony was plagued with legal problems, as discussed in Chapter 1.

This culminated in Oracle’s refusal to grant a TCK licence for Harmony. Apache resigned from the JCP Executive Committee in protest in December 2010, and mothballed Harmony a few months later.

Today, the relationship between Apache and Oracle is at a near standstill. Java library projects still thrive and proliferate, both as Apache-licensed and Apache Foundation projects. However, there has been no direct rapprochement between the two sides, and the scars from the Harmony dispute are still painfully visible.

Spring

Sun had invested heavily in a bet on the rise of Java as an enterprise language and platform. The scope of the vision was quite ambitious, aiming to largely or completely free the ordinary developer of business applications of low-level concerns.

The first few versions of the Enterprise Java vision were plagued by problems. The most fundamental of these was that the problem space was simply not understood well enough at first. Separating business logic concerns from infrastructure, and separating both from configuration and deployment is a worthy goal. However, the correct positioning of the dividing lines between these concerns is somewhat more subtle than it seems at first glance.

As a result, while Java’s footprint in the enterprise continued to grow, teams were looking for ways to simplify complexity and still provide more powerful techniques to define, configure, and deploy their applications.

Against this backdrop, alternatives to the official enterprise Java stacks began to emerge. One of the best known and most powerful, was the Spring framework. This was originally created by Rod Johnson and first released as open-source software in 2003.

The initial idea behind the Spring framework was to provide a much more lightweight way of configuring and executing applications than was possible within the orthodoxy of “pure” enterprise Java. By separating out the core concern of configuration, Spring frees the container from this responsibility. The design of Spring allows the application developer to chose a container that fits the needs of the application (including not requiring a container at all).

Like any successful technology, as users became familiar with it, they started to discover use cases that were not catered for, and missing features. Over time, Spring became a larger collection of semi-related interoperable technologies that provide a full-featured framework of comparable capability to Java EE. Of course, catering to a larger set of features and concerns has its price. Spring is now no longer any smaller or less complex than the technology stack that it was originally started in response to.

The Spring community has flourished as the technology has matured, and there are now numerous Spring developers that usually, or exclusively, take the Spring stack as their baseline for any new Java development. Outside of this, Spring has permeated throughout the Java ecosystem, and most working Java programmers will have encountered some Spring technologies at some point during their career.

The Java Community Now

Today’s Java community is the result of widespread developer adoption, corporate politics, global economic forces, and more than a measure of blind luck. Software development is increasingly globalized, but the simplicity and relatively small cognitive footprint of Java have meant that the platform has travelled well and prospered as the industry has expanded.

In this section, we’ll look at some of the more prominent features of the global Java community.

JUGs

Java User Groups (JUGs) are informal groups of Java programmers who have chosen to organize into a loose association in order to share experience and knowledge, network, and enhance each other’s professional development.

Oracle does not enforce any particular rules on JUGs. Instead, Oracle simply asks that when a new JUG forms, they register with Oracle’s community staff. The company maintains a list of groups, and offers support and promotion to them.

JUGs are a great way to meet new people, hear about new technology, expand your skills, get involved in open-source, and even find new career opportunities. Some of the largest and most influential groups include SouJava (Brazil) and the London Java Community (UK), but there are JUGs of all sizes all over the world.

One of the original maxims of free and open-source software is that all it takes is for a single developer to sit down and decide to scratch their own technical itch, and decide to share their work freely.

Developers who come from a more corporate background may not have been exposed to this philosophy as much. So they may be surprised by the small amount of work that’s required to set up a JUG, collect a few Java developers together, and start making a difference.

One of the ways in which JUGs have started trying to improve the ecosystem is through the Adopt programs. These are JUG-led global programs founded by the London Java Community, and are designed to provide ways for ordinary Java developers to contribute to the development of new Java standards (JSRs) and to the reference implementation (OpenJDK). Even a single, isolated developer is welcome to participate, and can make a useful contribution (https://java.net/projects/adoptopenjdk).

Java Champions

The Java Champions program was started by Sun to recognize and encourage Java professionals working outside of Sun. While there’s no precise definition, the core values are that a Champion should be a leader, technology luminary (both in technical stature and involvement with exciting tech), and be influential, independent, and credible to other developers.

The Java Champions are an exclusive group of passionate Java technology and community leaders who are community-nominated and selected under a project sponsored by Oracle.

Oracle

The program contains only a few hundred expert developers worldwide, and they are a diverse group, both geographically and in every other regard. They form an informal leadership group (along with the JUG leaders) for Java as it is practised in industry.

The landscape of Java developers is complex, but remains healthy. The vast majority of Java programmers leave their work behind when they finish for the day, of course. Fortunately, the overall pool of developers is so big, that the enthusiast, or person who wants to enhance their career should find plenty of ways to engage.