COLLECTED BY
Collection:Common Crawl
Web crawl data from Common Crawl.
TIMESTAMPS
The Client LibrariesGroup iscomprised of developers who participate in the design,implementation, and maintenence of the Java client libraries. It isaconsolidation of the former2D,AWT,Sound, andSwing Groups.
Archived documentation for each of the consolidated Groups maybe found in the original Group pages:
These currently need some updates to remove obsolete informationbut there's still a lot of valid material there.We hope to be able to invite additional long time contributorsto the group on an ongoing basis, reflecting people who have hadcontinual involvement and expect to remain involved in thefuture.
Together these modules enable
Like much of the rest of the JDK as much as possible of theimplementation is written using Java, but because of the nature ofplatform integration there is still a vast amount of native code,much of it platform-specific. The majority of shared(cross-platform) native code is widely used open source librarieswritten in C or C++ for specialised functions such as fontrasterisation and color management.
Some client contributors also contribute to the OpenJFX Project- there's a more or less 100% overlap in the skill set !
"Drive-by" contributions - will get a hard look because weprefer folks who contribute to stick around and maintain thosecontributions.
There are additional challenges of contributing to the ClientLibraries Group area compared to some other areas since so much ofwhat we do is platform-specific that you may need access tomultiple platforms and be prepared to do a lot of cross-platformand manual testing. Depending on your reviewers for that isn'tlikely to speed along your contribution.
Tests should be provided unless clearly infeasible. Automatedtests are desirable. SQE rarely run manual tests. Nor will otherdevelopers. Don't give up easily. There are tests that render to aBufferedImage and analyse the resulting contents to see if theybehaved correctly, so writing automated tests is possible in morecases than immediately apparent.
Code reviews are one of the most important mechanisms we havefor integrating and shipping good, solid, compatible code. Reviewsare also an invaluable source of education for all of us, and agreat mechanism for ensuring consistent code quality, as we allread and learn from reading each other's code.
The standard requirement in the JDK project is for one reviewerto approve the fix. The Java Client Library Group has alwaysstandardized on two approvals - where at least one must have theReviewer role. Historically this was addressed entirely by socialconventions but today the tooling plays a role - and the JDKproject is set up to mark a PR as ready for integration after asingle approval by a person with the Reviewer role - which is notconsistent with the Client Libraries policy. The tooling cannotautomatically enforce this on a per-module basis and it is notreasonable to expect others to add "/reviewers 2" to every PR. Thefixer therefore needs to understand the policies and wait for asecond approval.
Note that there may sometimes be confusion between the terms"reviewers" and "approvers". The tooling tends to use the wordreview/reviewer where it really means "Approval by someone with theReviewer role". Anyone with an OpenJDK github role can "review" afix - meaning make comments, and even add an Approval. And indeedwe encourage non-Reviewers to actively review PRs. So really youonly have two "reviews" when you have two "approvals". If more thanone person has expressed a viewpoint on a fix, and say one hasapproved and the other made substantive comments, without expresslyapproving, then they are active in reviewing that fix. So you needto take the nature of their comments into consideration, and allowthem reasonable time (let's say 24 hrs during the work week fornon-urgent fixes) to respond to any written answers or code updatesand add their approval before pushing. This is both for courtesy,and so that someone who has spent time on the review may becredited in the commit, and to ensure that they have at least achance to agree you've addressed their concerns. . Fixers who arenot also Reviewers for the client area should consult a clientReviewer to determine if one reviewer is enough. Potential reasonsfor granting that exception are enumerated below.
The choice of which people review the code is not usually up tothe fixing engineer and and who should review it depends upon eachspecific situation, but some general guidelines are:
It is the responsibility of the implementing engineer to respondto the reviewers, and their concerns, and make the final codeadhere to changes agreed upon by the engineer and thereviewers.
It is the responsibility of the reviewers to provide timelyreviews, and understand (to the extent possible) and agree to thechanges that the engineer has implemented; when the code is putbackto the repository,the reviewers are also takingresponsibility for these changes. We can only have goodreviews, and good resulting code, if the reviewers take their jobsseriously and review the changes thoroughly. Given the costs andhassles of maintaining backward-compatible code indefinitely, wecannot risk code going in that is only cursorily reviewed; it isfar easier and cheaper to catch flaws in the review process than itis to fix them in bugs and escalations later on.
The most common exceptions to the two reviewer policy would befor
