CINXE.COM

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /><title>Client Libraries</title><link rel="shortcut icon" href="../../images/nanoduke.ico" /><link rel="stylesheet" type="text/css" href="../../page.css" /><script type="text/javascript" src="../../page.js"><noscript></noscript></script><script src="https://cdn.usefathom.com/script.js" data-site="KCYJJPZX" defer="yes"></script></head><body><div id="main"> <h1>The Client Libraries Group</h1> <h2>Introduction</h2> <p>The Client Libraries <a href="/groups/index.html">Group</a> is comprised of developers who participate in the design, implementation, and maintenence of the Java client libraries. It is a <a href="https://mail.openjdk.org/pipermail/gb-discuss/2021-June/000358.html"> consolidation</a> of the former <a href="/groups/2d/">2D</a>, <a href="/groups/awt/">AWT</a>, <a href="/groups/sound/">Sound</a>, and <a href="/groups/swing/">Swing</a> Groups.</p> <p>Archived documentation for each of the consolidated Groups may be found in the original Group pages:</p> <ul> <li><a href="/groups/2d/">2D</a></li> <li><a href="/groups/awt/">AWT</a></li> <li><a href="/groups/sound/">Sound</a></li> <li><a href="/groups/swing/">Swing</a></li> </ul> These currently need some updates to remove obsolete information but there's still a lot of valid material there. <h2>Community</h2> <ul> <li><strong>Mailing Lists</strong> <ul> <li><a href="https://mail.openjdk.org/mailman/listinfo/client-libs-dev">client-libs-dev</a> (<a href="https://mail.openjdk.org/pipermail/client-libs-dev/">archives</a>)</li> <li> <a href="https://mail.openjdk.org/mailman/listinfo/2d-dev">2d-dev</a> (<a href="https://mail.openjdk.org/pipermail/2d-dev/">archives</a>)</li> <li> <a href="https://mail.openjdk.org/mailman/listinfo/awt-dev">awt-dev</a> (<a href="https://mail.openjdk.org/pipermail/awt-dev/">archives</a>)</li> <li> <a href="https://mail.openjdk.org/mailman/listinfo/beans-dev">beans-dev</a> (<a href="https://mail.openjdk.org/pipermail/beans-dev/">archives</a>)</li> <li> <a href="https://mail.openjdk.org/mailman/listinfo/sound-dev">sound-dev</a> (<a href="https://mail.openjdk.org/pipermail/sound-dev/">archives</a>)</li> <li> <a href="https://mail.openjdk.org/mailman/listinfo/swing-dev">swing-dev</a> (<a href="https://mail.openjdk.org/pipermail/swing-dev/">archives</a>)</li> </ul> </li> <li><strong><a href="https://openjdk.org/census#client-libs">Members</a></strong><br /> Like all "areas" the members of the group are not the entireity of those contributing. <p>We hope to be able to invite additional long time contributors to the group on an ongoing basis, reflecting people who have had continual involvement and expect to remain involved in the future.</p> </li> </ul> <h3>Source code</h3> The Client Libraries Group is responsible for the JDK source in the following modules <ul> <li><b>java.desktop</b> <a href="https://github.com/openjdk/jdk/tree/master/src/java.desktop">https://github.com/openjdk/jdk/tree/master/src/java.desktop</a> and <a href="https://github.com/openjdk/jdk/tree/master/make/modules/java.desktop"> https://github.com/openjdk/jdk/tree/master/make/modules/java.desktop</a><br /> this is the vast majority of the code for creating desktop clients as well as headless rendering support</li> <li><b>java.datatransfer</b> <a href="https://github.com/openjdk/jdk/tree/master/src/java.datatransfer">https://github.com/openjdk/jdk/tree/master/src/java.datatransfer</a> and <a href="https://github.com/openjdk/jdk/tree/master/make/modules/java.datatransfer"> https://github.com/openjdk/jdk/tree/master/make/modules/java.datatransfer</a><br /> separated for use by code that does not need the entire desktop module</li> <li><b>jdk.accessibility</b> <a href="https://github.com/openjdk/jdk/tree/master/src/jdk.accessibility">https://github.com/openjdk/jdk/tree/master/src/jdk.accessibility</a> and <a href="https://github.com/openjdk/jdk/tree/master/make/modules/jdk.accessibility"> https://github.com/openjdk/jdk/tree/master/make/modules/jdk.accessibility</a><br /> support for the JavaAccessBridge for Windows used by Assistive Technologies (ATs)</li> <li><b>jdk.unsupported.desktop</b> <a href="https://github.com/openjdk/jdk/tree/master/src/jdk.unsupported.desktop"> https://github.com/openjdk/jdk/tree/master/src/jdk.unsupported.desktop</a> and <a href="https://github.com/openjdk/jdk/tree/master/make/modules/jdk.unsupported.desktop"> https://github.com/openjdk/jdk/tree/master/make/modules/jdk.unsupported.desktop</a><br /> a small number of non-standard APIs mostly for interop with OpenJFX</li> </ul> <p>Together these modules enable</p> <ul> <li>AWT applications - supporting integration with the desktop, display management, input events etc</li> <li>Swing applications, using Java and platform Look&Feels.</li> <li>creation of applications which conform to government and industry standards for ATs</li> <li>Java Sound applications</li> <li>Java Beans</li> <li>Accelerated 2D rendering via OpenGL/D3D/Metal</li> <li>Imaging, color management, sophisticated text APIs, geometry</li> <li>Printing - both user interactive and API controlled.</li> <li>Headless server support for software rendering of Java 2D to and from image formats</li> </ul> <p>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.</p> <h3>Demos</h3> 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 : <a href="https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc">https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc</a>. 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. <h3>Tests</h3> 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 <ul> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/com/sun/java">https://github.com/openjdk/jdk/tree/master/test/jdk/com/sun/java</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/demo/jfc">https://github.com/openjdk/jdk/tree/master/test/jdk/demo/jfc</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/java/awt">https://github.com/openjdk/jdk/tree/master/test/jdk/java/awt</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/java/beans">https://github.com/openjdk/jdk/tree/master/test/jdk/java/beans</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/javax/accessibility"> https://github.com/openjdk/jdk/tree/master/test/jdk/javax/accessibility</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/javax/print">https://github.com/openjdk/jdk/tree/master/test/jdk/javax/print</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/javax/sound">https://github.com/openjdk/jdk/tree/master/test/jdk/javax/sound</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/javax/swing">https://github.com/openjdk/jdk/tree/master/test/jdk/javax/swing</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/sanity/client"> https://github.com/openjdk/jdk/tree/master/test/jdk/sanity/client</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/sun/awt">https://github.com/openjdk/jdk/tree/master/test/jdk/sun/awt</a></li> <li><a href="https://github.com/openjdk/jdk/tree/master/test/jdk/sun/java2d">https://github.com/openjdk/jdk/tree/master/test/jdk/sun/java2d</a></li> </ul> <h2>The ongoing work of the Client Libraries Group</h2> There's no plan to do "large new features' for Swing, Java2D etc but <ul> <li>keeping it working well on all the new platform versions and API stacks is keeping us busy</li> <li>Enhancements (ie smaller features) are still happening</li> <li>JEPs that aren't just "maintenance" JEPs are not absolutely ruled out, but they do need to represent something that will be a long term benefit.</li> </ul> <h3>Recent, Current and Upcoming Projects/JEPs etc</h3> <ul> <li>Test stabilisation (JDK11->ongoing) - we have put a lot of effort into improving tests which fail for random reasons such as being timing sensitive and overall making tests more robust. This has enabled us to rely on automated tests much more than before to verify fixes. There's still a lot to do since many tests remain Problem Listed because they fail for such reasons - or in some cases product bugs we need to fix.</li> <li>Applet deprecation (JDK 17) - with the demise of Java Plugin the java.applet package is obsolete for most purposes. So all referneces to Applets in the Java API have been deprecated for removal. There are however lots of valuable tests written as Applets so we need to find an answer to that first.</li> <li>MacOS ARM (JDK 17) - internally the Apple JNF framework was used extensively and since this was not available on Apple Silicon we had to replace it.</li> <li>MacOS A11Y (ongoing) - the current macOS APIs used for A11Y have been deprecated for years and we need to migrate to the new ones before they are removed</li> <li>Metal for macOS (JDK17) - this was a 2 year effort that is now mostly complete to replace the OpenGL 2D rendering pipeline on macOS with a new one using Apple's Metal API</li> <li>Wayland (TBD) - a replacement for the X11 implementaton of AWT/2D on Linux</li> <li>Windows 11 (TBD) - not yet scoped - hopefully it is mostly a case of verification</li> </ul> <p>Some client contributors also contribute to the OpenJFX Project - there's a more or less 100% overlap in the skill set !</p> <h2 class="p2"><br /> Group Policies.</h2> First, refer to the <a href="https://openjdk.org/guide/">OpenJDK Developer's Guide</a> for JDK-wide policies, processes and practices. However there are some extra considerations for the client area. <h3>Proposing a change</h3> 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 client-libs-dev@openjdk.org list is the place to go for these discussions <p>"Drive-by" contributions - will get a hard look because we prefer folks who contribute to stick around and maintain those contributions.</p> <p>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.</p> <h3>Guidelines on what kinds of changes we would like to see - or not see.</h3> <h4>Preamble</h4> <p>Every change in JDK code carries risk of changes in behaviour which adversely affect applications. Generally we are looking to improve the functionality and capability and sometimes performance of the platform without that negative consequence. We do have many thousands of tests, but they are inevitably incomplete in coverage. So we need to ask ourselves, whether each change is worthwhile and some may not be no matter how well intentioned.</p> <p>A lot of proposed changes may be broadly categorised as "internal code only" changes. This includes more than moving files and functions around. If a change being proposed is just a "code clean up", or "optimization" it may be of low value relative to the costs and risks. It is perhaps most succinctly characterised as any change that changes the JDK product source code without making things perceptibly better for applications. There isn't an agreed on single term for all of this, "refactoring" covers some of it, and all of the abovall of the above is the intended reading of that term when used in this doc.</p> <p>So the guidelines that follow are something that should be read by developers before spending a lot of time on a proposed fix.</p> <p>And is important to ensure that even a "cleanup" code change has been exercised by a test, so see <a href="#testing-a-change">Testing a Change</a></p> <h4>Guidelines and criteria that relate to changes we DO want</h4> These do not automatically guarantee a change will be accepted, but if one of these is the focus of a change, it is much more likely to be accepted. <ol> <li>Correctness changes are welcome.<br /> If there's something that affects program correctness, that's important. And to broaden this, what is most valuable is fixing of all kinds bugs that really make things better for applications in ways they can detect. i.e functional bugs</li> <li>Making the JDK code "more robust" for applications.<br /> Such changes are probably good, where "more robust" means say using some new platform API which is newer.</li> <li>Changes which make the platform more secure.<br /> Changes which are intended to increase the overall security of the platform following secure coding practices and using appropriate platform APIs for that are usually welcome. The exception might be if it is a potentially destabilising change in code where there is only a theoretical problem. NOTE: if you think you found a real security bug that might compromise the platform, then you should follow the process <a href="/groups/vulnerability/">here</a></li> </ol> <h4>Guidelines and criteria that might cause changes to be less likely to be accepted</h4> These do not automatically disqualify a change, but if any of these characterise a proposed change without some benefit from the above list, you should think twice, and be ready to justify it, and perhaps for it ultimately not to be accepted. <ol> <li>Stable code is not a good candidate for refactoring.<br /> Much of the code in java.desktop has been stable for a long time, and if it is stable, perhaps it has few bugs or need for change. So changes in stable code naturally have a higher risk to reward ratio.</li> <li>Performance changes need to really matter<br /> Can you demonstrate a user perceptible change ?<br /> If you can't measure the change, or you measure it and is small and perhaps once per VM then maybe it isn't worth it.<br /> Some API may be more performant than another but in UI applications the CPU is often just waiting for the user. Collection class "A" may be faster than class "B" as demonstrated in some benchmarks, but if that's when there are 10,000 entries and client code never has more than 100 and the CPU can traverse the collection faster than the user can move a mouse one pixel .. what have you added ?</li> <li>Modernising API usage needs to be more than for its own sake.<br /> "There's a cool new feature in JDK 17/C++ 20/etc", is not enough if you need to update stable code to use it, and there's no other benefit.</li> <li>Be a subject matter expert, not just a language expert.<br /> Fixes that say "this is a better way of writing this code" are not guaranteed to be safe, no matter how much the submitter writes claims like "safe, simple, more clear". A change of behaviour is always possible and unless you understand the code you are changing at more than the core language/API level, and have looked into appropriate tests and can speak to the risks, then you should first find a subject matter expert to discuss it with.</li> <li>Large changes - whether by complexity or volume - are more risky.<br /> For volume, you may think of this as no different than proposing 10 individual small unrelated changes but what happens in practice is there's a focus on say 5-6 of these and no one really looks hard at the other 4-5. For complexity, even small changes that are hard to understand and test may be risky.</li> <li>Backports may be more costly in refactored code.<br /> This is perhaps less a guideline than a warning. If some file in mainline has been refactored and there's then an important functional bug found that needs to be fixed and backported, then the more similar the code across releases then the more straightforward the backport. Refactoring means a backport may be almost a new bug fix. So this is another added cost to weigh against the benefit of the change.</li> <li>There is no such thing as a zero risk change.<br /> Once you start changing product code, its very hard to prove otherwise. Supposedly equivalent APIs may not be the drop in replacement you thought. Even removing dead code (!) has mysteriously caused performance regressions - but yes in general removing dead code is a good thing.</li> </ol> <h4>Finally</h4> The area lead will always have discretion to evolve these guidelines, and if there's a PR that falls between the lines, to decide which side it falls. Amendments to these guidelines may follow such cases. <p><br /></p> <h3>Source code conventions</h3> 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 : <ul> <li>All lines <= 80 chars</li> <li>No tabs, indents are always 4 spaces.</li> <li>if blocks should use { .. } even for one line</li> </ul> Consult <a href="http://www.oracle.com/technetwork/java/codeconvtoc-136057.html">Code Conventions for the Java(TM) Programming Language</a> for the full list.<br /> <a name="testing-a-change" id="testing-a-change"></a> <h3>Testing a change</h3> <p>Do not overlook testing. Test before even submitting your PR.</p> <ul> <li>Run all available tests on all applicable platforms. <ul> <li>For client this means the jtreg "jdk_desktop" test group - at a minimum.</li> <li>Do NOT rely on github actions for testing.</li> <li>Do NOT think that "tier1 + tier2 + tier3" gives you the needed coverage of client tests.</li> </ul> </li> <li>Make sure your changes are touched by some test.</li> <li>If you can, write a test that directly passes or fails based on the changes (see <i>Regression tests</i> below).</li> <li>This is often not possible for "cleanup" fixes without digging into JDK internals So if not possible try to write a new test that at least exercises this code.</li> </ul> <h3>Regression tests</h3> <p>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.</p> <h3>Code Reviews</h3> <p>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.</p> <p>The standard requirement in the JDK project is for one reviewer to approve the fix. The Java Client Library Group has always standardized on two approvals - where at least one must have the Reviewer role. Historically this was addressed entirely by social conventions but today the tooling plays a role - and the JDK project is set up to mark a PR as ready for integration after a single approval by a person with the Reviewer role - which is not consistent with the Client Libraries policy. The tooling cannot automatically enforce this on a per-module basis and it is not reasonable to expect others to add "/reviewers 2" to every PR. The fixer therefore needs to understand the policies and wait for a second approval.</p> <p>Note that there may sometimes be confusion between the terms "reviewers" and "approvers". The tooling tends to use the word review/reviewer where it really means "Approval by someone with the Reviewer role". Anyone with an OpenJDK github role can "review" a fix - meaning make comments, and even add an Approval. And indeed we encourage non-Reviewers to actively review PRs. So really you only have two "reviews" when you have two "approvals". If more than one person has expressed a viewpoint on a fix, and say one has approved and the other made substantive comments, without expressly approving, then they are active in reviewing that fix. So you need to take the nature of their comments into consideration, and allow them reasonable time (let's say 24 hrs during the work week for non-urgent fixes) to respond to any written answers or code updates and add their approval before pushing. This is both for courtesy, and so that someone who has spent time on the review may be credited in the commit, and to ensure that they have at least a chance to agree you've addressed their concerns. . Fixers who are not also Reviewers for the client area should consult a client Reviewer to determine if one reviewer is enough. Potential reasons for granting that exception are enumerated below.</p> <p>The choice of which people review the code is not usually up to the fixing engineer and and who should review it depends upon each specific situation, but some general guidelines are:</p> <ul> <li>At least one reviewer should have some familiarity with this technology and/or area of the code</li> <li>Two reviewers should be looking at everything, so if one reviewer is chosen for only a segment of any particular change, you should get other reviewers to review the sections that are left with only one reviewer.</li> </ul> <p>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.</p> <p>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, <strong>the reviewers are also taking responsibility for these changes</strong>. 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.</p> <p>The most common exceptions to the two reviewer policy would be for</p> <ul> <li>Documentation updates that do not affect the specification</li> <li>Identical backports previously reviewed by two reviewers</li> <li>Trivial test only changes.</li> <li>Time critical, simple changes such as backing out a build breakage.</li> <li>Extra discretion is granted to the most experienced reviewers in the area to say if one reviewer is enough or even that three reviewers are needed.</li> </ul> </div><div id="sidebar"><div id="openjdk-sidebar-logo"><a href="/"><img alt="OpenJDK logo" src="../../images/openjdk-small.png" /></a></div><div class="links"><div class="link"><a href="/install/">Installing</a></div><div class="link"><a href="/guide/#contributing-to-an-openjdk-project">Contributing</a></div><div class="link"><a href="/guide/#reviewing-and-sponsoring-a-change">Sponsoring</a></div><div class="link"><a href="/guide/">Developers' Guide</a></div><div class="link"><a href="/groups/vulnerability/report">Vulnerabilities</a></div><div class="link"><a href="https://jdk.java.net">JDK GA/EA Builds</a></div></div><div class="links"><div class="links"><a href="https://mail.openjdk.org">Mailing lists</a></div><div class="link"><a href="https://wiki.openjdk.org">Wiki</a> · <a href="/irc">IRC</a></div></div><div class="links"><div class="links"><a href="/bylaws">Bylaws</a> · <a href="/census">Census</a></div><div class="link"><a href="/legal/">Legal</a></div></div><div class="links"><div class="links"><a href="/workshop"><b>Workshop</b></a></div></div><div class="links"><div class="links"><a href="/jeps/0"><b>JEP Process</b></a></div></div><div class="links"><div class="about">Source code</div><div class="link"><a href="https://github.com/openjdk/">GitHub</a></div><div class="link"><a href="https://hg.openjdk.org">Mercurial</a></div></div><div class="links"><div class="about">Tools</div><div class="link"><a href="http://git-scm.org/">Git</a></div><div class="link"><a href="/jtreg/">jtreg harness</a></div></div><div class="links"><div class="about">Groups</div><div class="link"><a href="/groups/">(overview)</a></div><div class="link"><a href="/groups/adoption">Adoption</a></div><div class="link"><a href="/groups/build">Build</a></div><div class="link"><a href="/groups/client-libs">Client Libraries</a></div><div class="link"><a href="/groups/csr">Compatibility & Specification Review</a></div><div class="link"><a href="/groups/compiler">Compiler</a></div><div class="link"><a href="/groups/conformance">Conformance</a></div><div class="link"><a href="/groups/core-libs">Core Libraries</a></div><div class="link"><a href="/groups/gb">Governing Board</a></div><div class="link"><a href="/groups/hotspot">HotSpot</a></div><div class="link"><a href="/groups/ide-support">IDE Tooling & Support</a></div><div class="link"><a href="/groups/i18n">Internationalization</a></div><div class="link"><a href="/groups/jmx">JMX</a></div><div class="link"><a href="/groups/members">Members</a></div><div class="link"><a href="/groups/net">Networking</a></div><div class="link"><a href="/groups/porters">Porters</a></div><div class="link"><a href="/groups/quality">Quality</a></div><div class="link"><a href="/groups/security">Security</a></div><div class="link"><a href="/groups/serviceability">Serviceability</a></div><div class="link"><a href="/groups/vulnerability">Vulnerability</a></div><div class="link"><a href="/groups/web">Web</a></div></div><div class="links"><div class="about">Projects</div><div class="link">(<a href="/projects/">overview</a>, <a href="/projects/archive">archive</a>)</div><div class="link"><a href="/projects/amber">Amber</a></div><div class="link"><a href="/projects/babylon">Babylon</a></div><div class="link"><a href="/projects/crac">CRaC</a></div><div class="link"><a href="/projects/code-tools">Code Tools</a></div><div class="link"><a href="/projects/coin">Coin</a></div><div class="link"><a href="/projects/cvmi">Common VM Interface</a></div><div class="link"><a href="/projects/guide">Developers' Guide</a></div><div class="link"><a href="/projects/dio">Device I/O</a></div><div class="link"><a href="/projects/duke">Duke</a></div><div class="link"><a href="/projects/galahad">Galahad</a></div><div class="link"><a href="/projects/graal">Graal</a></div><div class="link"><a href="/projects/icedtea">IcedTea</a></div><div class="link"><a href="/projects/jdk7">JDK 7</a></div><div class="link"><a href="/projects/jdk8">JDK 8</a></div><div class="link"><a href="/projects/jdk8u">JDK 8 Updates</a></div><div class="link"><a href="/projects/jdk9">JDK 9</a></div><div class="link"><a href="/projects/jdk">JDK</a> (…, <a href="/projects/jdk/22">22</a>, <a href="/projects/jdk/23">23</a>, <a href="/projects/jdk/24">24</a>)</div><div class="link"><a href="/projects/jdk-updates">JDK Updates</a></div><div class="link"><a href="/projects/jigsaw">Jigsaw</a></div><div class="link"><a href="/projects/kona">Kona</a></div><div class="link"><a href="/projects/kulla">Kulla</a></div><div class="link"><a href="/projects/lanai">Lanai</a></div><div class="link"><a href="/projects/leyden">Leyden</a></div><div class="link"><a href="/projects/lilliput">Lilliput</a></div><div class="link"><a href="/projects/locale-enhancement">Locale Enhancement</a></div><div class="link"><a href="/projects/loom">Loom</a></div><div class="link"><a href="/projects/jmm">Memory Model Update</a></div><div class="link"><a href="/projects/metropolis">Metropolis</a></div><div class="link"><a href="/projects/jmc">Mission Control</a></div><div class="link"><a href="/projects/mlvm">Multi-Language VM</a></div><div class="link"><a href="/projects/nashorn">Nashorn</a></div><div class="link"><a href="/projects/nio">New I/O</a></div><div class="link"><a href="/projects/openjfx">OpenJFX</a></div><div class="link"><a href="/projects/panama">Panama</a></div><div class="link"><a href="/projects/penrose">Penrose</a></div><div class="link"><a href="/projects/aarch32-port">Port: AArch32</a></div><div class="link"><a href="/projects/aarch64-port">Port: AArch64</a></div><div class="link"><a href="/projects/bsd-port">Port: BSD</a></div><div class="link"><a href="/projects/haiku-port">Port: Haiku</a></div><div class="link"><a href="/projects/macosx-port">Port: Mac OS X</a></div><div class="link"><a href="/projects/mips-port">Port: MIPS</a></div><div class="link"><a href="/projects/mobile">Port: Mobile</a></div><div class="link"><a href="/projects/ppc-aix-port">Port: PowerPC/AIX</a></div><div class="link"><a href="/projects/riscv-port">Port: RISC-V</a></div><div class="link"><a href="/projects/s390x-port">Port: s390x</a></div><div class="link"><a href="/projects/sctp">SCTP</a></div><div class="link"><a href="/projects/shenandoah">Shenandoah</a></div><div class="link"><a href="/projects/skara">Skara</a></div><div class="link"><a href="/projects/sumatra">Sumatra</a></div><div class="link"><a href="/projects/tsan">Tsan</a></div><div class="link"><a href="/projects/valhalla">Valhalla</a></div><div class="link"><a href="/projects/verona">Verona</a></div><div class="link"><a href="/projects/visualvm">VisualVM</a></div><div class="link"><a href="/projects/wakefield">Wakefield</a></div><div class="link"><a href="/projects/zero">Zero</a></div><div class="link"><a href="/projects/zgc">ZGC</a></div></div><div class="buttons"><a href="https://oracle.com"><img alt="Oracle logo" src="../../images/oracle.png" /></a></div></div><div id="footer"> © 2024 Oracle Corporation and/or its affiliates <br /><a href="/legal/tou/">Terms of Use</a> · License: <a href="/legal/gplv2+ce.html">GPLv2</a> · <a href="https://www.oracle.com/us/legal/privacy/">Privacy</a> · <a href="https://openjdk.org/legal/openjdk-trademark-notice.html">Trademarks</a></div><script type="text/javascript" src="/ZNBVQquKRCmTkFz_W96h/9wuJJcNVt9p4/MClz/FjZHVw1/zC0Q"></script></body></html>