COLLECTED BY
Collection:Save Page Now Outlinks
TIMESTAMPS
This page describes the sponsored-contribution process for theJDK andJDK Updates Projects. OtherProjects may follow these conventionsor may establish their own; please consult the appropriate Projectpages for details.
This process is intended for developers who already have theskills required to work on the JDK but who do not yet have fullCommitter rights. It allows suchdevelopers to demonstrate their abilities by submitting meaningfulcontributions in the form of patches and by pairing them withsponsors,i.e., existingCommitters for the Project who can offer advice, helpthem become familiar with the JDK development process, andeventually push their patches into the appropriateMercurial repository. Over time,it's expected that skilledContributors will eventually earn fullcommit rights forthemselves.
This page focuses on the contributing side of the process; acompanion page describeshow to sponsor acontribution.
Like many other open-source communities, the OpenJDK CommunityrequiresContributors to jointlyassign their copyright on contributed code. If you haven't yetsigned theOracleContributor Agreement (OCA) then please do so at theOCA web site. Please makesure to specify OpenJDK as the project you'd like to contribute toso that we can process and store your OCA. Allow at least two weeksfor processing. If your request is urgent contact the appropriateProject Lead.
The OCA gives Oracle and the Contributor joint copyrightinterests in the code. The Contributor retains copyrights whilealso granting those rights to Oracle as the Community's sponsor.You only need to sign the OCA once in order to cover all changesthat you might contribute to any Oracle-sponsored open-sourcecommunity including not just OpenJDK but also, for example,GlassFish,NetBeans, andMySQL. If you've already signed the OCA orthe former SCA (Sun Contributor Agreement) for any Oracle-sponsoredopen-source community, then you do not need to sign it again inorder to contribute to OpenJDK. Please note that you donotneed to sign an OCA if you work at Oracle or a company which hasnegotiated an equivalent agreement. (You can learn more about theOCA by consulting itsFAQ.)
The most obvious thing to work on is a bug or enhancement (RFE)about which you are passionate. Please check the "JDK" Project ofthebug database to seeif your idea is already described there, and if so then use thatbug/RFE's id number when writing about your work. If there's noexisting bug or RFE then that's fine too; we just ask that you usea relevant id for tracking purposes, if one exists.
If you're interested in a particular area but don't have anyspecific ideas about what to do then feel free to post a query tothe appropriate Group or Projectdevelopment list to ask forsuggestions that match your skills and knowledge. A list of all theGroups andProjects may be found at the left-hand sideof this page; you are more than welcome tosubscribe to any of theirmailing lists. A complete list of all of the Groups, Projects,people and their roles may be found in thecensus.
Before you invest significant time working on a change it may beworth discussing what you're trying to do with other engineersworking on the same code. They're likely to be able to offercomments and suggestions that will result in a higher-qualitychange and a smoother submission process. Announcing that you'reworking on a particular item can also help to avoid wasted effortin case someone else is already working on it.
If you're thinking of working on an existing bug or RFE that'salready tracked in thebugdatabase then the best way to start such a discussion is topost a message to the appropriate development list with a subjectline of the form
6543210:Myfavorite bug
where6543210 is replaced with the actualOpenJDK bug or RFE id number andMy favoritebug is replaced with the bug or RFE's synopsis.
Your patch must be built and tested on all relevant platformsbefore submission. Refer to the mainline build and testinstructions for the JDK here:build,test.For JDK Update projects, see the respective repository. If you haveproblems building, you may send your questions to theBuild Group'smailinglist. Note that a full build against recently synchronizedsources with only your applied patch is required for each submittedchange.
When your change is ready, send a message to the appropriatedevelopment list with a subject line of the form
[PATCH]6543210:My favorite bug
where6543210 andMyfavorite bug are replaced as above. If no existing bug or RFEdescribes your change then omit the id number and one will becreated and assigned.
The message should contain three things, either directly, or inthe body as attachments:
A description of the change, including a rationale for yourapproach and a discussion of any alternative approaches that wereconsidered, if relevant. If no existing bug or RFE describes yourchange then also include a description of the problem that itsolves or the need that it addresses.
The code change itself, relative to an existing changeset in theappropriate Mercurial repository. The preferred form is generatedby Mercurial'shg export command, with the-g option so that file renames are tracked correctly. Theoutput ofhg diff -g is also acceptable, and inthe worst case traditionalunified diffs (-u) are okay too, at least for simplechanges.
A unit test, written for thejtreg testharness, that validates your change. The test should fail when runagainst a build without the change and succeed when run against abuild with the change. Unit tests aren't always practical,especially for changes such as performance improvements or fixes tobugs that are highly platform-dependent, but if practical then aunit test is required.
If an existingJDK orJDK Updates Committer decides tosponsor your proposed change then that person will take ownershipof your bug.
Your sponsor will evaluate your patch for correctness,compatibility, stability, performance, coding style, and overallappropriateness to the current phase of the intended Project'sdevelopment. Your sponsor will work with you to address anyremaining deficiencies and then guide you through the rest of thedevelopment process, navigating the relevant internal Oracleengineering processes on your behalf and ultimately, if all goeswell, pushing your patch into the appropriate Mercurialrepository.
Only the best patches submitted will actually make it all theway into a JDK code base. The goal is not to take in the maximumnumber of contributions possible, but rather to accept only thehighest-quality contributions. The JDK is used daily by millions ofpeople and thousands of businesses, often in mission-criticalapplications, and so we can't afford to accept anything less thanthe very best.
If you're relatively new to the Java platform then we recommendthat you gain more experience writing Java applications before youattempt to work on the JDK itself. The purpose of thesponsored-contribution process is to bring developers who alreadyhave the skills required to work on the JDK into the existingdevelopment community. The members of that community have neitherthe time nor the patience required to teach basic Java programmingskills or platform implementation techniques. (Oracle offersformal training if that's what you're looking for.)
The feature releases currently under development are in theJDK Project. Most development work isfocused on the newest release, so generally you should be workingagainst the latest JDKsources rather than theJDK Updates sources. Fixesfor critical bugs may eventually be backported, but only after they"soak" in JDK for at least one full test cycle (about sixweeks).
