Millions of developers worldwide use Java. The Java platform powers thousands of applications, from small hobby projects to large mission-critical enterprise systems.
Java owes its success to numerous organizations and committers that drive the platform forward. But did you know that you can contribute to your favorite programming language, too?
Contributing to OpenJDK isn’t only for language designers. Whether you want to fix a small bug, improve performance, enhance documentation, or even propose new features, there’s a place for you in the OpenJDK community.
In this guide, we will show you how OpenJDK development works under the hood and how you can contribute. We will also describe steps the proposal must go through before it becomes part of Java SE, using BellSoft’s recent API contribution to the OpenJDK as an example.
If you’ve ever wanted to leave your mark on Java, this is your chance!
Table of Contents
Key Areas of OpenJDK Contributions
OpenJDK is a centralized place that unites work on the open-source implementation of Java Standard Edition and the related projects. OpenJDK is an extensive project, whose maintenance and development necessitate a great deal of effort from hundreds of developers. As such, all kinds of help are appreciated.
So, if you are not ready to propose a brand-new Java feature, there’re plenty of other ways you can contribute to Java:
Test the latest OpenJDK builds to find bugs
The larger the codebase, the higher the risk of bugs introduced by changes. The OpenJDK project contains more than 12 million lines of code, and it is challenging to make sure that no fix or enhancement introduces a small bug somewhere in the farthest corner of the project.
Therefore, you can download the current OpenJDK build and set off to a bug hunt. Test the builds on your Java projects and report the bugs if any. This information will help the platform developers to resolve compatibility issues and preserve the reliability of OpenJDK.
Propose a fix to the existing bug
You can fix a known bug. Browse the JDK Bug System, and if you find an issue that you feel you are capable of solving, start working on the solution. You can investigate the root cause, write a fix, and submit a patch for review. Submitting a bug fix not only improves the experience of Java developers worldwide but also helps you build your reputation in the community.
Review the new code
Proposed changes to the Java code are evaluated by Reviewers. But even if you are not an official OpenJDK Reviewer, you can provide feedback on code clarity, correctness, or potential performance improvements or regressions. You can also review the tests and find corner cases that lack test coverage.
By engaging in reviews, you not only help maintain Java’s high-quality standards but also learn best practices from seasoned OpenJDK contributors. Reviewing code is a great way to get familiar with the development process before submitting your own changes.
Improve documentation
You can contribute by fixing outdated JavaDoc comments, enhancing API documentation, or adding missing explanations in OpenJDK guides. Even small changes such as clarifying method behavior or improving examples can make a big impact.
Offer a new Java Enhancement Proposal (JEP)
If you have an idea for a significant improvement to Java, you can propose a JEP (Java Enhancement Proposal). JEPs are used for major changes that may involve changing several parts of JDK and solicit cooperation with several OpenJDK Project teams. Therefore, a JEP must go through a rigorous evaluation process, including feasibility studies and discussions with the Java community.
Contributing a JEP is a long-term commitment, but it’s how groundbreaking features like Records, Virtual Threads, and Pattern Matching have become part of Java.
Submit code to the existing JEP currently under development
Not every contribution has to start from scratch. You can join the work on the active JEP. Besides, OpenJDK projects like Leyden and Valhalla always need developers to write code, optimize performance, or test new features.
By contributing to an existing JEP, you get a chance to work with experienced OpenJDK developers and participate in Java’s evolution.
Blog about Java’s new features and releases
OpenJDK Contributions are not only about code. You can blog about new Java features, showcasing how they helped you with your project. You can also write tutorials as many developers need good guides to understand how to use Java’s capabilities to the maximum. By explaining Java’s recent improvements, providing real-world examples, or breaking down complex topics, you can make Java more accessible to everyone.
You can also spread the word about the newest Java releases to help drive the adoption of the newest Java versions forward.
Criteria for Contribution Acceptance
Not all proposals will be accepted, and this is not because OpenJDK maintainers are cantankerous or haughty. On the contrary, they work hard to preserve the stability of the platform used by millions of people and make sure that the introduced changes do not adversely affect the OpenJDK codebase, now or potentially in the future.
Consequently, the maintainers take several factors into consideration when evaluating proposed changes:
- The stability of the JDK builds must be preserved. Any change, even the smallest one, may introduce bugs or regressions, so the risk/benefit ratio is always carefully assessed.
- The changes introduced to OpenJDK will remain there for many years ahead, so they must not pose challenges to the future code maintainers.
- In the complex OpenJDK code, all features interact with each other. As a result, a new feature may cause a negative rippling effect that will be hard to deal with.
- All changes must adhere to the existing specifications such as the Java Language Specification, the Java Virtual Machine Specification, and the Java API Specification.
Therefore, before plunging into coding, make sure that your improvement corresponds to the following criteria:
- Correctness: The change must be technically sound and not introduce regressions.
- Evaluated performance impact: Any impact on performance must be evaluated and justified.
- Compatibility: Changes should not break backward compatibility unless explicitly intended.
- Tests and documentation: Contributions must include test cases and documentation updates.
How to Get Started
So how do you get started with Java contributions?
First of all, set up your environment. Download the OpenJDK source code, install necessary build tools and compile the code on your machine.
Secondly, study the OpenJDK Developer’s Guide. It contains essential information on established development processes, tooling, review policies, and so on.
Thirdly, browse the mailing lists. They will help you understand the inner workings of the OpenJDK development and the culture. In addition, Before starting work on the improvement, it is recommended to join or start a discussion on the mailing list. This will help you gain validation on your proposal, sparing you the unnecessary effort if it is deemed as incomplete or unpromising.
If you want to start with fixing bugs, find an issue to work on. Browse the JDK Bug System for open issues that range from beginner-friendly small fixes or complex feature enhancements.
The Contribution Workflow
As mentioned above, any contribution must go through the established development process that includes discussions, reviews, rigorous testing, and approval. Let’s look at one workflow scenario using one of our recent customer cases that evolved into a brand new API in OpenJDK as an example. We’ll need to set up our environment by forking the OpenJDK project. I already have it for the purpose of checking the enhancements and verifying that the OpenJDK tests pass in the GHA workflow.
Towards a New Method in Java
This particular contribution spawned from a peculiar issue. In the case if a Windows host had a fully numerical name like 000000123456789, this name were treated by the existing Java API InetAddress#getByName()in a specific way. In particular, the resulting InetAddress object sometimes pointed to an nonexistent IP address, although the conversion was made strictly in accordance with the Java specification. The observable behavior was that some of the host names produced valid InetAddress objects pointing to actual IP addresses, some produced invalid objects, and the criteria was unclear.
The problem was that the InetAddress API was obsolete and didn’t meet the modern requirements. Namely, the lack of transparency on what’s been passed to the underlying low level OS API (POSIX getaddrinfo in particular), that could lead to blocking calls to Name Resolution system with unpredictable delays while simply parsing a textual IP address and deriving an InetAddress object from it. Also the API didn’t support the textual API address formats defined by POSIX inet_addr API supported by all major browsers and network utilities, that have decimal, octal and hexadecimal address segments. The “healthy” host names turned to be “invalid IP address literals” that went through name resolution, while the others were “valid IP address literals” that have been converted directly to the binary form. Also some of the “invalid” literals in Java were actually valid - in POSIX standard.
The first enhancement being developed around that time by Alexei Efimov was JDK-8272215 that introduced a new method InetAddress#ofLiteral() that didn’t cause any blocking calls to the network, and parsed textual addresses in the old style Java dotted-decimal format. The idea was to extend that new API to add the support for POSIX inet_addr-compatible address segments, so as to make Java interoperable with external networking tools and configurations.
Initial bug report was filed under JDK-8315767 in September 2023 with the description of the issue. After thorough discussion, the conclusion was to extend the InetAddress API, and the bug was upgraded to ‘Enhancement.’
A Pull Request was proposed with the initial version of the enhancement in March 2024. Upon the subsequent review and discussions it was decided that the Compatibility & Specification Review (CSR) was needed because the improvement necessitated changes to the API.
Consequently, a CSR issue was filed the same month. In April 2024, the Pull Request was marked as ‘Ready for Review.’
The further development was on improving and finalizing the new API and related JavaDoc comments as part of the PR.
Finally, the CSR was approved and integrated in May 2024. The new method Inet4Address#ofPosixLiteral() was included into JDK 23 released in September 2024.
As a result of integrating this API, Java can now do what any modern browser can, namely parsing the textual API addresses using InetAddress#ofPosixLiteral() API according to the POSIX Standard.
Conclusion
Contributing to OpenJDK means shaping the future of Java. Whatever you decide to do: fix a small bug, improve documentation, or help review code, every contribution makes a difference. The process may seem complex at first, but with persistence and engagement, you’ll gain valuable experience and become part of a community that drives Java forward.
So, go ahead and set up your environment, explore the JDK Bug System, and take your first step toward becoming an OpenJDK contributor!
