The Client Libraries Group


The Client Libraries Group is comprised of developers who participate in the design, implementation, and maintenence of the Java client libraries. It is a consolidation of the former 2D, AWT, Sound, and Swing Groups.

Archived documentation for each of the consolidated Groups may be found in the original Group pages:

These currently need some updates to remove obsolete information but there's still a lot of valid material there.


Source code

The Client Libraries Group is responsible for the JDK source in the following modules

Together these modules enable

Like much of the rest of the JDK as much as possible of the implementation is written using Java, but because of the nature of platform 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 libraries written in C or C++ for specialised functions such as font rasterisation and color management.


Additionally the Client Libraries Group maintains several demo applications. Not meant as an example of modern standard coding practice, but principally meant as named, to "demo" the functionality of the APIs : They are also useful for manual testing of this functionality and it is not unusual for a reviewer to suggest running them to verify a fix.


The jtreg tests for the Client Libraries Group code are somewhat scattered around, since the tests tend to be organised by package name and there are plenty of those. Many of the tests are automated, but also many are manual. An incomplete list of directories for these tests is

The ongoing work of the Client Libraries Group

There's no plan to do "large new features' for Swing, Java2D etc but

Recent, Current and Upcoming Projects/JEPs etc

Some client contributors also contribute to the OpenJFX Project - there's a more or less 100% overlap in the skill set !

Group Policies.

First, refer to the OpenJDK Developer's Guide for JDK-wide policies, processes and practices. However there are some extra considerations for the client area.

Proposing a change

Like most other groups in OpenJDK for anything that is more than a localised bug fix, we prefer to see issues raised and discussed before we see a PR which may reflect a different direction than we'd want. This is especially true if you are a new contributor. The list is the place to go for these discussions

"Drive-by" contributions - will get a hard look because we prefer folks who contribute to stick around and maintain those contributions.

There are additional challenges of contributing to the Client Libraries Group area compared to some other areas since so much of what we do is platform-specific that you may need access to multiple platforms and be prepared to do a lot of cross-platform and manual testing. Depending on your reviewers for that isn't likely to speed along your contribution.

Source code conventions

All source code should follow the standard Java source code conventions as well as jcheck rules. Some of the most common ones to remember are : Consult Code Conventions for the Java(TM) Programming Language for the full list.

Regression tests

Tests should be provided unless clearly infeasible. Automated tests are desirable. SQE rarely run manual tests. Nor will other developers. Don't give up easily. There are tests that render to a BufferedImage and analyse the resulting contents to see if they behaved correctly, so writing automated tests is possible in more cases than immediately apparent.

Code Reviews

Code reviews are one of the most important mechanisms we have for integrating and shipping good, solid, compatible code. Reviews are also an invaluable source of education for all of us, and a great mechanism for ensuring consistent code quality, as we all read and learn from reading each other's code.

The standard requirement in Java SE is for one (or more) reviewer prior to code freeze and two (or more) reviewers thereafter. The Java Client Library Group has standardized on two reviewers with few exceptions.

The choice of which people review the code is up to the individual engineer and depends upon each specific situation, but some general guidelines are:

It is the responsibility of the implementing engineer to respond to the reviewers, and their concerns, and make the final code adhere to changes agreed upon by the engineer and the reviewers.

It is the responsibility of the reviewers to provide timely reviews, and understand (to the extent possible) and agree to the changes that the engineer has implemented; when the code is putback to the repository, the reviewers are also taking responsibility for these changes. We can only have good reviews, and good resulting code, if the reviewers take their jobs seriously and review the changes thoroughly. Given the costs and hassles of maintaining backward-compatible code indefinitely, we cannot risk code going in that is only cursorily reviewed; it is far easier and cheaper to catch flaws in the review process than it is to fix them in bugs and escalations later on.

The most common exceptions to the two reviewer policy would be for