Now you’ve got a direct line to the Open Ecosystem at Intel: Arun Gupta, VP and GM, holds live monthly Twitter Spaces conversations with changemakers in the open source community. Follow him on Twitter for reminders on the next one and to ask your questions live.
In the first event, Arun Gupta talks to Simon Ritter, Deputy CTO at Azul Systems*, who has been working with Java since its beginning, joining Sun Microsystems in 1996 around the launch of JDK 1.0. He later worked for Oracle for five years before joining Azul in 2015. Throughout his career, he’s been dedicated to promoting and driving the adoption of Java through developer relations and advocacy.
They talk about why the “blue-collar” language has survived the shifts in tech, the history of OpenJDK and how you can get involved. Their conversation has been edited and condensed for brevity and clarity.
Arun Gupta: Seeing Java evolve over 25 years has been absolutely amazing. You’ve been with Java from the very first version, has Java always been open source?
Simon Ritter: Java was originally developed as proprietary technology by Sun in the mid-90s. As the community started using Java, they requested an open standard and eventually an open source version. The Java community process was created in 1997 to establish that standard. Sun later made the decision to make Java open source in 2006, creating OpenJDK. It took about 10-11 years from its launch for Java to become open source.
Inside the Java Community Process
Arun Gupta: I remember back in 2006 when, Rich Green, the VP of Java software, announced that Java would become open source. He discussed the concept of a Java standard and emphasized the importance of creating a standard to accompany open source. So Sun actually made a standard, which is what led to the Java Community Process. How does that work?
Simon Ritter: The Java Community Process (JCP) works to create standards for different aspects of Java. The JCP used to cover all standards for Java Enterprise Edition, which have since moved to the Eclipse Foundation*. Each version of Java has a Java Specification Request (JSR) that includes three components: Specification, reference implementation, and technology compatibility kit (TCK). The Java language specification covers the syntax of the language, the Java virtual machine specification defines its functionality, and the standard class libraries definition offers standard functionality. OpenJDK is the reference implementation for Java SE. The TCK tests over 100,000 components to verify that an implementation matches the standard. So OpenJDK is closely linked to the JCP standards, offering a conforming implementation of the standard.
Arun Gupta: Got it. So the JCP, the Java community process creates the JSRs, Java specification request which defines the language, the specs, the specification, what the API is going to look like. Then there’s a reference implementation (RI) element of it, which is the OpenJDK and 122,000 tests in the compatibility kit because OpenJDK is a reference implementation. What do you need for that compatibility kit, is it because has multiple vendors of OpenJDK? How does that work?
Simon Ritter: Two things: First, people can create their own implementation of a standard using the specification, like IBM did with a clean implementation for J9. Secondly, using Technology Compatibility Kit (TCK) tests, different distributions of OpenJDK can be verified to be functionally identical to the specifications, making it easy for users to switch without changing or recompiling their code. It means their applications run exactly the same way in terms of their behavior, but there’s different non-functional behavior, meaning performance such as lower latency or faster throughput, etc…
Arun Gupta: That's pretty awesome. But TCK isn’t something customers run, it assures them that the application they run using OpenJDK if they want to switch to Azul JDK is compatible because it's passes the TCK. What I'm getting is, because of those non-functional requirements, maybe they get a better performance, better garbage collection or whatever those features are right?
Simon Ritter: So it's like a seal of approval, if you like, that people can look at and say, "Yes, if it's TCK tested, then I've got a very high level of assurance that when I install it and run my applications, they'll behave in exactly the same way."
Who Contributes to OpenJDK
Arun Gupta: Now, who contributes to OpenJDK? OpenJDK isn’t a one-vendor show, it's a truly open source. How does that work?
Simon Ritter: It’s truly open source with a wide number of contributors, from individuals to employees of big organizations such as Oracle*, IBM*, and Red Hat*. While Oracle contributes the most engineering resources due to their stewardship of the platform through the acquisition of Sun Microsystems, other companies like SAP* and Microsoft* are also heavily involved. Microsoft's involvement in the open source Java ecosystem is particularly surprising, given their past conflicts with Sun Microsystems and incompatibilities in their versions of Java. Microsoft now offers their own distribution of the OpenJDK for running Java applications in the Azure cloud.
Arun Gupta: That’s really cool. I remember when we worked at Sun Microsystems and had disagreements with Microsoft…It's great to see that even companies like Amazon*, where I also used to work, contribute and have their own distribution called Amazon Corretto*.
At Intel, our customers rely on open source projects like OpenJDK to run efficiently on our silicon, so we have a dedicated team contributing regularly.
The Scoop on Java Release Cycles
Arun Gupta: Let's discuss OpenJDK and its ability to keep up with evolving programming models, such as Project Panama, aimed at improving Java's connections to non-Java code, such as C and C++. Despite previous criticism about Java's slow evolution, OpenJDK has undergone significant changes.
Simon Ritter: Java’s evolution was glacial before Oracle's decision in 2018 to switch to a time-based release model, where new features are added every six months. This has allowed for a faster pace of evolution, introduction of preview features and incubator modules, and a more controlled way of evolving the platform. The introduction of bigger projects like Valhalla*, Loom*, and Panama* has focused on specific sections of how Java works and allowed for simpler interaction with native code. Project Amber* covers recent changes in language syntax like pattern matching and sealed types. Overall, the entire OpenJDK process and governance is evolving to meet the needs of Java developers.
Arun Gupta: Let’s take some audience questions. The first question is: “Why do companies create their own implementations of OpenJDK?” That could be a huge task.
Simon Ritter: Creating a new JDK from scratch is a huge, daunting task. For instance, JDK 8 has around 7.5 million lines of code, so very few people attempt it. IBM's clean-room implementation, which dates back to the early Java days, was necessary because they couldn't use the open source version. At Azul, we take OpenJDK and focus only on sections where we can make improvements instead of rewriting everything. Given the amount of work involved, the likelihood of someone creating a completely new JDK from scratch is slim.
Arun Gupta: Another person asked: “Does theme being slow in making stuff on time or you did just decide to move to a timed-release cycle?”
Simon Ritter: Moving to a time-release cycle meant faster introduction of features and a more agile approach to development, which aligns with the overall trend in software development towards iterative processes. However, some features still require multiple iterations and take longer to develop, such as the foreign function and memory APIs which are currently on their fourth iteration, at least. Nonetheless, the switch to a time-release cycle has allowed for a smoother development phase.
Arun Gupta: I like how Georges Saab compares it to a train - features are either on or not on and it doesn't matter if they miss a release because another one is coming. Getting an Early Access Preview is key to ensure developers can test it before it's fully released. Another question by Vicki Gao, "For a while, the guidance for getting off of Java 8 was to migrate up to 11, now that Java 17 is also in the picture. Is the new guidance to go straight to Java 17 from 11?”
Simon Ritter: JDK 8 was a popular release due to its functional style of programming. With the new six-month release cadence, it's not feasible to provide extended support for every release. Long-term support releases are selected instead, with JDK 8 being the first and JDK 21 set to release in September. Choosing a new version of Java now gives three options: JDK 11, JDK 17, or waiting for JDK 21. The jump from JDK 8 to 11 is significant due to the switch to the Java platform module system, which introduced changes to internal APIs.
How to get involved
Arun Gupta: How can people become an OpenJDK maintainer? Do I just jump in and say, “Hey, I'm gonna contribute code?” How do people get started?
Simon Ritter: Java is an open source project with multiple contributors, but caution is taken to avoid instability. The governance for OpenJDK has different levels of roles, allowing for careful consideration of changes before they are committed. Inclusivity is encouraged, with participants, contributors, reviewers, and project leads. Starting small and building credibility is crucial. Following the various mailing lists is a good way to begin and ask questions. Start small, then work up to bigger changes and contributions. Brian Goetz, the Java Language Architect at Oracle, is responsive and explains decisions thoroughly.
How to find a mentor
Arun Gupta: That's an approach we can take in general in open source. If you want to change the underlying plumbing, you've got to understand the need to build credibility in the open source project. Start by being a participant, contributor, reviewer, commit a project lead. And who knows?
OpenJDK is a very inclusive community but you might need a mentor to guide you through that process and how would you find one?
Simon Ritter: Start by following the OpenJDK project's mailing lists, which cover different areas such as JDK development, language side of things, and libraries. Reading and participating in these discussions is a great way to learn and get answers to questions. Mailing lists are the best place to begin. If you've got comments, if you've got ideas, that's a great place to start because people are very responsive.
The Secret to Java’s Survival
Arun Gupta: Another question from Twitter: What’s Java's magic ingredient for surviving? So much has come along, like .net*, Ruby on Rails*, JavaScript*, TypeScript* , etc? What about Rust? Kotlin*? And a follow up question: How did it adapt to the changes in architectural styles and what hurdles do you see on the horizon?
Simon Ritter: Java's popularity is due to two reasons: the real gem of the platform is the Java virtual machine (JVM), which allows scalability of applications, and the language and libraries which have evolved to match developer requirements. Netflix is a great example: They run their applications on Java and AWS* and they can scale to the number of users they need for that kind of environment.
Going back to JDK 8, the inclusion of lambdas and streams offers a more functional style of programming we didn’t have before. The fact that we've seen all these changes over the last few years means adapting the language to match what people want to do, helps maintain that level of popularity. James Gosling (the “father” of Java) always described Java as a “blue-collar language.” It was all about getting the job done. It's not an academic exercise proving this is the best possible language ever. It's about how do we get the job done and help developers to be productive…
Challenges now include adapting to a cloud world (microservices, containers, Kubernetes*), and Azul is working on making JVMs more efficient in that environment, like decoupling the Just-In-Time (JIT) compiler from the JVM itself and centralizing it for more efficient use of resources.
How to bring more diversity to Java
Arun Gupta: What can we do to improve diversity in open source and Java? It’s a topic very near and dear to my heart.
Simon Ritter: We should prioritize promoting diversity in tech and leverage existing organizations like Women Who Code and Jade Duchesses. Visiting and spreading the word through Java user groups globally is also important; Jugs (JUGs) are available everywhere except Antarctica. I don't know how many JUGs I've presented to, but I did count that I’ve presented on Java in something like 54 different countries.
How to get started in open source
Arun Gupta: What advice do you have for recent college graduates who want to get started in open source?
Simon Ritter: My top advice is to simply participate in open source projects. After university, it can be challenging to showcase your skills to potential employers. Open source allows you to demonstrate your abilities by contributing to various projects. Find the appropriate area of interest, whether it’s Java, the Java platform, or one of the ancillary parts like JakartaEE, enterprise Java or artificial intelligence. Find what interests you, start small, and work your way up. Don’t hesitate to take the lead and start your own project on platforms like GitHub*. Employers will appreciate seeing what you have accomplished and can offer.
Follow Arun Gupta on Twitter for monthly Twitter Spaces live sessions with changemakers in the open source community.