![](https://www.azul.com/wp-content/uploads/dummies-page-hero-1-1.png)
Chapter 6
Choosing the Right Java Partner
Once an organization interested in migrating to OpenJDK fully understands the three-step migration process and the straightforward path to migration success, another concern can rise to the fore.
Enterprises want to know if they can trust their business-critical Java applications to the care of a new provider. Java’s rapid evolution has made it the language of choice for enterprise applications. It has also created a need for extensive knowledge and experience with Java that can be hard to find.
Creating a Java application is comparatively easy, but deep root cause analysis of issues affecting the JDK requires sophisticated knowledge of a highly complex, ever-changing system made up of seven million lines of code (and growing). Architectural changes, like the rise of microservices and serverless functions and containers, have created new performance challenges, too, and the move to the cloud has led to escalating costs — some of which can be reduced by faster code. Organizations that run on Java or maintain a significant Java footprint need more than a JDK help desk; they need a true Java partner. And, let’s face it, looking for a partner for any endeavor can be like going off on a quest for the holy grail. Luckily, there are signposts that point to a provider’s level of proficiency. We point these out in this chapter.
Evaluating a Track Record
Java is nearly 30 years old. Providers with real expertise have a track record of supporting the Java platform — and participating in the processes and standards bodies that move Java forward — extending back to the first complete release of OpenJDK’s source code in 2009. (You can read more about the history of OpenJDK in Appendix A.)
A key organization is the Java Community Process (JCP). Originally created by Sun Microsystems in 1998, the JCP develops and maintains Java technology standards. It was designed as an open, inclusive, and collaborative process consisting of working groups, expert groups, and an executive committee. The JCP’s executive committee is responsible for approving Java Specification Requests (JSRs) and reconciling discrepancies between specifications and test suites.
Organizations and individuals who serve on the JCP’s executive committee are actively involved in determining Java’s future. There are also a handful of individuals and organizations whose continuous involvement with Java over the years has created a knowledge base that is rich and deep. Over time, they’ve ensured that Java remained relevant even as software went through a step change and client–server architectures were supplanted by cloud-based architectures utilizing microservices. Gil Tene, Azul’s cofounder and chief technology officer (CTO), was first elected to the JCP in 2011. He is one of the longest-serving members and has been recognized as Member of the Year.
Other activities of note include participating in the OpenJDK Vulnerability Group and actively contributing security fixes. Active involvement in online communities like Friends of OpenJDK (Foojay) and the Adoptium Working Group can serve as further proof points.
Considering Customer References
A potential partner’s list of existing customers is a good place to start to find out if that organization is a fit for your own. It will help you determine the level of expertise they have in your particular industry and market. In addition, understanding the size and scope of existing support relationships will offer insight into whether a potential partner can handle the complexity of your own organizational needs.
Customer satisfaction is another component to pay attention to. It’s a leading indicator of a partner’s current level of service, and it can be a helpful macro data point when combined with testimonials and direct references.
Deciding on a Service Level
The services offered by commercial support providers for OpenJDK can vary quite a bit. Differences start with the breadth of Java versions and the associated platforms and underlying architectures that are supported, as well as the length of support. It’s also important to understand how a provider defines support and whether those services are covered by a service-level agreement (SLA).
Here are some differences in the delivery of OpenJDK support that you’ll want to consider:
» Basic help-desk support versus deep root-cause analysis, dedicated account managers, monthly strategy calls, best practice consulting, and quarterly security briefings.
» Quarterly updates delivered as a Patch Set Update (PSU) versus curated stabilized builds (which is what Oracle and Azul refer to as Critical Patch Updates [CPUs]).
» Updates that rely on “best effort” versus updates delivered on a strict SLA.
» OpenJDK builds with known issues around GNU Public License (GPL) contamination versus builds that are indemnified.
These differences add up to fundamentally different views of the relationship between the OpenJDK provider and customers who run their business on OpenJDK. A true partnership will focus on achieving the most business value from Java, starting with your migration and continuing through the life cycle of your Java Virtual Machines (JVMs).