Thank you for your kind introduction
ダゲーホー
Hello everyone
Thank you for joining me
This is the title of my presentation
Let me introduce myself
I'm Koichi, Koichi Sakata
I'm talking to you from Japan
I show my handle name at the bottom left of this slide
Follow me if you are interested
I'm a Java Champion
Last year I submitted some patches to OpenJDK, so I'm an OpenJDK Author now
I work at NTT Data
This chart shows issues fixed in JDK 17 per organization
Our company, including me, has contributed to OpenJDK since before
Today I will be taking about contributing to OpenJDK
How many of you want to contribute to OpenJDK?
Yes, I can see
All people in this room want to do so
As you can see, there are many ways of contributing
When you hear of the contribution to open source software, the first thing that you think of is writing code
But there are other ways to contribute
It's good to combine some ways
In this presentation, I will focus on the way of submitting patches
Because this is the thing that most people are interested in, I think
After this presentation, you will be able to submit patches to OpenJDK
Duke needs you for JDK development
Let's try to think about fixing bugs
The contribution process is almost the same as developments of popular open source software, such as spring framework, Jakarta EE, etc.
There are some steps to fix a bug
First, find.., then fix..., submit..., finally the patch is merged
I'll explain each step from now
The first step is to find a bug
As you know, OpenJDK works well in our applications almost always
Have you ever come across a new JDK bug?
We try to find bugs but failing to do so
What should we do?
Where are points to be fixed?
I tried some different ways.
As a result, I've found points to be fixed before.
I'll introduce them to you.
It's effective to build OpenJDK with new versions of tools
As you may know, OpenJDK has not only Java but also C++, especially JVM is written in C++
So we need tools for C++ to build it
For example we use GCC on Linux, Clang on macOS, Visual Studio on Windows
You can build it on WSL, Windows Subsystem for Linux
Errors or warnings might occur during the build.
If those occurs, it means you have found the point to be fixed.
Then you can try to resolve it
I've actually tried it before
I saw some warnings with GCC 10 immediately after it released
Those warnings didn't happened with GCC 9
What you can see at the bottom is one of the warnings
The details of the warning is out of this presentation
When you build with the new versions of tools, you might be able to see some errors or warnings as well
On the GCC website, I found those sentences in this slide
The warning was enhanced in GCC 10
I examined the warning further and tried to change the code to fix the warning
This is how I write a patch for warnings
I'll introduce another way to find points to be fixed
OpenJDK has the bug tracking system
We simply call it JBS
It's the bug tracking system
JBS is based on Atlassian JIRA
So you can operate JBS in the same way as JIRA.
Look at this screenshot
Each issue has detailed information
JBS is accessible for everyone with read-only
You can search issues on JBS
In this screenshot I used the query language to search issues that have starter label
Those are for beginners so good to address
I’ve fixed some issues that had the label before
Issues that have clean-up label are also good for beginners
OK, we can find the points now
Let's move on to the next step
Second step is fixing a bug
Assume that we've finished fixing code
Of course, we should run tests before sending a patch
Jtreg is the regression test harness
I'll show you a demo
This is the movie of running a jtreg test
I increased the playback speed
This code is a test class for the clhsdb tool in the jhsdb
I executed the make run-test command
It's running the test
Just a moment
What you can see here is the result of running a jtreg test
There is also gtest test code for the C++ part
Gtest is a Google C++ testing framework
Here is the result of running a gtest test.
So far, we become able to run tests
Go on to the next step
How do we submit our patch?
Is it OK to create pull requests to the OpenJDK repository in GitHub?
Instead of creating pull requests, it's better to send a mail to the suitable mailing lists.
In the mail, you write the details of the issue you found and paste the patch if you have written it already
When the issue is recognized, it is filed in JBS
After that, you can create the pull request to the repository
Mailing lists are important for the OpenJDK development.
I'm going to talk for a minute about them
Don't be surprised, OpenJDK has many mailing lists.
I took a count of them
There are 200 mailing lists
I'll introduce a few of them
hotspot-dev, compiler-dev... Each mailing list covers of the topic as described in this slide
It's good to subscribe those mailing lists to gather information
All mails are archived
We can read past communications on the web site
This is my first mail to the mailing list
As you can see, it's about GCC warnings I explained before
Yes, I understand how you feel now
Do we need to code to the public mailing list?
Everyone will feel uneasy to do
I used to be the same
But don't be afraid
People in the OpenJDK community are friendly and polite
Even if English is your second language, like me
So you can send the mail, too
When the issue is recognized, OpenJDK developers filed it in JBS
After that, you can create a pull request in GitHub.
OpenJDK has a repository in GitHub.
It used to use Mercurial
There is a relationship between JBS and GitHub
All issues need to be files in JBS
We have to write the issue number in the title of the pull request
Additionally, comments to the pull request are send to related mailing lists of OpenJDK and vice versa
Before creating a pull request, we have to sign OCA, that is Oracle Contribution Agreement
For more information see this link
Next, we create a pull request as usual
This screenshot is my pull request
We've submitting the patch
Next step is receiving reviews
Of course the pull request need to be reviewed
The only people who has a reviewer role can review and approve the code
Reviewer is one of the roles in OpenJDK Community
I'll give a short explanation of roles in OpenJDK
Everyone is a contributor at first
They don't have any privileges
After some contributions, you will be an Author
I have this role
I'll touch on what sponsoring means later
At present, there are over three hundred committers and reviewers
When you make many significant changes, you will become a committer or reviewer
Let's get back to the pull request
In this example, my pull request were reviewed by four reviewers
This is the last step
We can't merge our pull request by ourselves
After the review, Reviewer or committer can sponsor the pull request
The sponsor will merge it
If you don’t have any role, your name will be recorded as a contributor
In this screenshot, the sponsor run sponsor pull request command to merge this pull request
We did it!
I've explained all steps to fix a bug.
Let me summarize
Today I talked about contributing to OpenJDK
There are many steps
But don't be afraid
You can do it
Let's move OpenJDK forward together!
I guess that's all I wanted to say today
Thank you for your attention
Enjoy this conference!