Many people complain that something is missing in Java, something is buggy or slow. The good news is: you have the opportunity not to complain, but make Java better on your own. Java is almost completely open as an OpenJDK project. This project has its own peculiarities, but in general nothing prevents you from reporting problems yourself, correcting them, and even developing new functionality. In this article I will tell a little how to do this for a beginner.

How to report a bug?

The project OpenJDK has a bugtracker - JIRA . There you can search and check if your problem is known or it is new. However, a person from the street cannot register there and write there. The official way to report a problem in Java (or even suggest an improvement) is to use the Java Bug Report form. This form creates a ticket in JIRA with the prefix JI (Java Issue, ticket number will come to your specified e-mail). At the time of pre-moderation, your ticket is hidden from prying eyes. If the pre-moderation is successful, then your problem will be migrated to a public project (for example, with the prefix JDK), and everyone will be able to see it. The advantage of this form is that it is relatively simple, does not require registration and in general any personal data. The downside is that these forms are not viewed directly by Java developers, but by the special webbug group team. There is a risk that your message will hang out for a long time unreviewed (even if it is important from the point of view of developers). This is my month of ticket hanging in pre-moderation, until I asked a good friend from Oracle to help people up. It may even happen that due to an oversight, your ticket will be rejected altogether, as happened, for example, with my colleague here . The problem manifested itself only in the OpenJDK, but not in the OracleJDK, and the webbug group considered that the problem was not worth attention. Again, managed to figure out only thanks to a good friend.

It also happens that the ticket successfully passed the pre-moderation and got into a public project, but you were not informed about this. Therefore, you can occasionally check URLs like https://bugs.openjdk.java.net/browse/JI-xxxxxxx , signing at the end of the JI number that you have. If the pre-moderation is completed, you will be redirected to a public ticket, otherwise you will see an error message.

In any case, be sure to clearly describe the problem and give a minimal example that reproduces it. The simpler it will be, the greater the chance that attention will be paid to it.

Is there a better way?

As we see, there are problems with this form. It is often better to report the problem to the appropriate mailing-list. OpenJDK supports many mailing lists and you should definitely subscribe to lists in your area of ​​interest. Look through the archives of the lists to see if they are dead or not. For example, if you have some kind of problem with lambdas, you are unlikely to write to lambda-dev now , because the lambda project is completed with the release of Java-8 and the list is inactive. Most likely compiler-dev is right for you, since usually problems with lambdas are a Java compiler problem.

Anyone can subscribe to the list and write to it, there are no problems here. Just be careful with attachments: most file types are cut. For reliability, I do not send anything except *.txt and check through the archive whether the message is actually in the list (in a normal situation, it is displayed in the archive immediately after being sent). These lists are read by real developers, so if you encounter an interesting problem, the way to solve it will be shorter.

And more exotic ways?

An alternative may be a letter in person to some Java developer who, in your opinion, will be interested in your problem. Email addresses of many developers are easy to find in the same mailing list archives, but, of course, this method is risky and requires a sense of tact. Your letter can easily be ignored. However, I was able to offer a simple feature request to the JMH tool.

A more exotic option is to complain about your problem to StackOverflow . There are OpenJDK developers and even Oracle employees, but, of course, they don’t read everything and it’s quite possible that your message willn’t be noticed. And if they notice, they will not want to do it. It worked for me once and then only after the bounty announcement. I was answered by Brian Goetz , recognizing my problem as a bug. The developers themselves started the ticket and fixed it. Of course, relying on success in this case is not worth it.

An even more exotic option is to report a problem at a java conference. At the last JPoint cheremin talked about escape analysis and gave an example of an interesting case with Arrays.asList , where it breaks ( presentation , slides 69 and below). After listening to his report, I was not too lazy to fix this problem. Of course, success in this case, too, no one guarantees.

How to fix bugs?

Now you have many ways to report a bug. But what if itching to pee the code? First you need to deal with the infrastructure.

All OpenJDK projects are stored in Mercurial repositories available here . Jdk9 is being developed and you usually need the dev sub repository. There is a further selection from several separate repositories like jdk (class library), hotspot (virtual machine), etc. If the problem is found in the current version of Java (for example, in java8), but it remains in java9, then fix it first in java9, and then port to java8 updates (if the intended benefits of porting outweigh the risk of making changes). Most of the eight problems are only corrected in the nine, but they do not tolerate the eight. Download the repository you need and take the time to study its device. If you are going to fix the class library, you will need a path like /src/<jigsaw-module>/share/classes/ in the jdk9/dev/jdk .

If you fixed the code, it would be good to make sure that your patch works as it should. I honestly did not understand how to properly build OpenJDK from scratch. Instead, I install the latest ready-made Java-9 build from the Kenai project. I copy only the changed java-files into a separate directory and then compile them somehow (example for changes in the java/util from the java.base module):

 $ javac -Xmodule:java.base -d out/java.base src/java/util/*.java 

And then I launch some test application using this command:

 $ java -Xpatch:out MyTest.java 

The -Xmodule and -Xpatch appeared in the Jigsaw project . Prior to this, -Xbootclasspath/p: worked, in Java-9 this option is not available.

And how to write tests?

It would be nice, however, to write a normal unit test, right in the repository. To run tests in OpenJDK, the special tool jtreg is used . Unfortunately, ready-made assemblies have not been updated for half a year, and this is critical, because the changes associated with Jigsaw cause problems in older versions of jtreg. So you have to figure out how to build jtreg yourself.

In general, the tests themselves are usually written with the help of TestNG , but there are also junit, and many old tests, when a certain class is simply launched with a certain main method, which should not fall with the exception. The jtreg tool allows you to abstract the entire zoo and contains many useful settings.

Patch ready! Where to send?

If you do decide to contribute to Java, you get to the bottom of the OpenJDK hierarchy. On it, you can send extremely simple patches (say, a trivial typo in the documentation). To do this, you compile a patch file (for example, using hg diff -g ) and send it to the appropriate mailing list with the word [PATCH] in the subject. It is better to send a small patch directly in the body of the letter along with an explanation. If under your patch there is a ticket in JIRA, you must also indicate the ticket number in the subject. Then you should wait until one of the developers agrees to sponsor the patch. If you do not answer at all, you can politely kicking people every couple of weeks. You may have made a mistake with the mailing list, but then you will most likely be told where to actually send the patch.

If your patch is not completely trivial, you can go the same way, but it will not be able to commit until you sign the Oracle Contributor Agreement . Naturally, since a large corporation is behind the project, one cannot do without legal issues. You agree that you send the code of your personal authorship and transfer it to the Oracle co-ownership (but you do not lose the rights to it and you can do what you want with it, and Oracle will do what it wants). Print the agreement, read it (there is a little), sign, scan and send to the specified e-mail. Be prepared that the processing will take at least a week. If successful, you will be notified by e-mail, and your name will appear in a long list . At this point, you get the status of the OpenJDK Contributor, and your patches can sponsor.

How to become an eighty level elf?

When you successfully push through 2-3 not the most trivial patches, you can ask for the status of the OpenJDK Author. To do this, you write a letter to the project leader (in jdk9 this is Mark Reinhold) and list your patches with links to commits. If successful, you open up new opportunities. Firstly, sftp access to the cr.openjdk.java.net server (an SSh public key is required), where you can post requests for code review. Secondly, you finally get an account in JIRA. Now you can rejoice and forget about the first half of the article: you can report bugs normally, and not only in the component to which you sent patches. You can also vote for bugs, subscribe to notifications and so on. From this moment on your name will appear in this list . Here you can see the status of people in different projects.

However, at the OpenJDK Author level, you still need sponsors for your patches. Now you should not send the patch to the mailing list, but generate a special set of HTML- files using the webrev tool (this is a ksh script and I had to set up a virtual machine with Ubuntu for it, I couldn't pin it under Windows). It looks like this . By generating a webrev, you send a link to it to the mailing list for code-review and prepare for comments. Someone still has to agree to commit your code, but you will already be listed as the author of the commit.

The next level is OpenJDK Committer. To become one, you must be promoted to this title by some committer in the main project list (for example, jdk9-dev ). For this, as a rule, it is required to have at least 8 nontrivial changes in the project. Voting is very simple - no one should be against it. With this title you no longer need a sponsor. You can commit your own changes and even sponsor others. But, of course, this does not cancel the code review.

Finally, you can reach the level of OpenJDK Reviewer. It is about the same thing - promotion, voting, but the requirements are stricter. Only reviewers can nominate and vote; a minimum of three votes in favor is required if there are no votes against. This status will allow you to formally review other people's changes. More information about the status and order of their purchase can be found here .

Conclusion

Fixing bugs in Java is basically not very difficult, if you have enough patience and perseverance to deal with everything. It is much more difficult to promote new features that change the public API. Here your brilliant ideas can easily wrap up. To look more substantial, I recommend not to start with features, but to become at least the author on some simple bugs. You can just dig in open tickets in JIRA and find something that seems uncomplicated to you. This is quite a lot, advanced developers do not always have time to rake the little things. If you still offer a feature, do not be lazy to study the history of the issue: look in the archives of mailing lists. Perhaps it was discussed and for some reason decided not to do it. Think about whether you have new reasons.

Program with pleasure and make Java better!