CINXE.COM
JEP 400: UTF-8 by Default
<!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>JEP 400: UTF-8 by Default</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><style type="text/css" xml:space="preserve"> TABLE { border-collapse: collapse; padding: 0px; margin: 1em 0 1em 2em; } TR:first-child TH, TR:first-child TD { padding-top: 0; } TH, TD { padding: 0px; padding-top: .5ex; vertical-align: baseline; text-align: left; } TD + TD, TH + TH { padding-left: 1em; } TD:first-child, TH:first-child, TD.jep { text-align: right; } TABLE.head TD:first-child { font-style: italic; padding-left: 2em; white-space: nowrap; } PRE { padding-left: 2em; margin: 1ex 0; font-size: inherit; } TABLE PRE { padding-left: 0; margin: 0; } TABLE.jeps TD:first-child + TD, TABLE.jeps TD:first-child + TD + TD { padding-left: .5em; } TABLE.jeps TD:first-child, TABLE.jeps TD:first-child + TD, TABLE.jeps TD:first-child + TD + TD { font-size: smaller; } TABLE.jeps TD.cl { font-size: smaller; padding-right: 0; text-align: right; } TABLE.jeps TD.cm { font-size: smaller; padding-left: .1em; padding-right: .1em; } TABLE.jeps TD.cr { font-size: smaller; padding-left: 0; } TABLE.jeps TD.z { padding-left: 0; padding-right: 0; } TABLE.head TD { padding-top: 0; } </style></head><body><div id="main"><h1>JEP 400: UTF-8 by Default</h1><table class="head"><tr><td>Authors</td><td>Alan Bateman, Naoto Sato</td></tr><tr><td>Owner</td><td>Naoto Sato</td></tr><tr><td>Type</td><td>Feature</td></tr><tr><td>Scope</td><td>SE</td></tr><tr><td>Status</td><td>Closed / Delivered</td></tr><tr><td>Release</td><td>18</td></tr><tr><td>Component</td><td>core-libs / java.nio.charsets</td></tr><tr><td>Discussion</td><td>core dash libs dash dev at openjdk dot java dot net</td></tr><tr><td>Effort</td><td>XS</td></tr><tr><td>Duration</td><td>XS</td></tr><tr><td>Reviewed by</td><td>Alex Buckley, Brian Goetz</td></tr><tr><td>Endorsed by</td><td>Brian Goetz</td></tr><tr><td>Created</td><td>2017/08/31 13:16</td></tr><tr><td>Updated</td><td>2023/06/12 13:46</td></tr><tr><td>Issue</td><td><a href="https://bugs.openjdk.org/browse/JDK-8187041">8187041</a></td></tr></table><div class="markdown"><h2 id="Summary">Summary</h2> <p>Specify UTF-8 as the default charset of the standard Java APIs. With this change, APIs that depend upon the default charset will behave consistently across all implementations, operating systems, locales, and configurations.</p> <h2 id="Goals">Goals</h2> <ul> <li> <p>Make Java programs more predictable and portable when their code relies on the default charset.</p> </li> <li> <p>Clarify where the standard Java API uses the default charset.</p> </li> <li> <p>Standardize on UTF-8 throughout the standard Java APIs, except for console I/O.</p> </li> </ul> <h2 id="Non-Goals">Non-Goals</h2> <ul> <li> <p>It is not a goal to define new standard Java APIs or supported JDK APIs, although this effort may identify opportunities where new convenience methods might make existing APIs more approachable or easier to use.</p> </li> <li> <p>There is no intent to deprecate or remove standard Java APIs that rely on the default charset rather than taking an explicit charset parameter.</p> </li> </ul> <h2 id="Motivation">Motivation</h2> <p>Standard Java APIs for reading and writing files and for processing text allow a <em>charset</em> to be passed as an argument. A charset governs the conversion between raw bytes and the 16-bit <code>char</code> values of the Java programming language. Supported charsets include, for example, US-ASCII, UTF-8, and ISO-8859-1.</p> <p>If a charset argument is not passed, then standard Java APIs typically use the <em>default charset</em>. The JDK chooses the default charset at startup based upon the run-time environment: the operating system, the user's locale, and other factors.</p> <p>Because the default charset is not the same everywhere, APIs that use the default charset pose many non-obvious hazards, even to experienced developers.</p> <p>Consider an application that creates a <code>java.io.FileWriter</code> without passing a charset, and then uses it to write some text to a file. The resulting file will contain a sequence of bytes encoded using the default charset of the JDK running the application. A second application, run on a different machine or by a different user on the same machine, creates a <code>java.io.FileReader</code> without passing a charset and uses it to read the bytes in that file. The resulting text contains a sequence of characters decoded using the default charset of the JDK running the second application. If the default charset differs between the JDK of the first application and the JDK of the second application then the resulting text may be silently corrupted or incomplete, since the <code>FileReader</code> cannot tell that it decoded the text using the <em>wrong</em> charset relative to the <code>FileWriter</code>. Here is an example of this hazard, where a Japanese text file encoded in <code>UTF-8</code> on macOS is corrupted when read on Windows in US-English or Japanese locales:</p> <pre><code>java.io.FileReader(“hello.txt”) -> “こんにちは” (macOS) java.io.FileReader(“hello.txt”) -> “ã?“ã‚“ã?«ã?¡ã? ” (Windows (en-US)) java.io.FileReader(“hello.txt”) -> “縺ォ縺。縺ッ” (Windows (ja-JP)</code></pre> <p>Developers familiar with such hazards can use methods and constructors that take a charset argument explicitly. However, having to pass an argument prevents methods and constructors from being used via method references (::) in stream pipelines.</p> <p>Developers sometimes attempt to configure the default charset by setting the system property <code>file.encoding</code> on the command line (i.e., <code>java -Dfile.encoding=...</code>), but this has never been supported. Furthermore, attempting to set the property programmatically (i.e., <code>System.setProperty(...)</code>) after the Java runtime has started does not work.</p> <p>Not all standard Java APIs defer to the JDK's choice of default charset. For example, the methods in <code>java.nio.file.Files</code> that read or write files without a <code>Charset</code> argument are specified to always use UTF-8. The fact that newer APIs default to using UTF-8 while older APIs default to using the default charset is a hazard for applications that use a mix of APIs.</p> <p>The entire Java ecosystem would benefit if the default charset were specified to be the same everywhere. Applications that are not concerned with portability will see little impact, while applications that embrace portability by passing charset arguments will see no impact. UTF-8 has <a href="https://en.wikipedia.org/wiki/Popularity_of_text_encodings#Popularity_on_the_World_Wide_Web">long been the most common charset on the World Wide Web</a>. UTF-8 is standard for the XML and JSON files processed by vast numbers of Java programs, and Java's own APIs increasingly favor UTF-8 in, e.g., the <a href="https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/nio/file/Files.html#readString(java.nio.file.Path)">NIO API</a> and for <a href="https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-5ED91AA9-B2E3-4E05-8E99-6A009D2B36AF">property files</a>. It therefore makes sense to specify UTF-8 as the default charset for all Java APIs.</p> <p>We recognize that this change could have a widespread compatibility impact on programs that migrate to JDK 18. For this reason, it will always be possible to recover the pre-JDK 18 behavior, where the default charset is environment-dependent.</p> <h2 id="Description">Description</h2> <p>In JDK 17 and earlier, the default charset is determined when the Java runtime starts. On macOS, it is UTF-8 except in the POSIX C locale. On other operating systems, it depends upon the user's locale and the default encoding, e.g., on Windows, it is a codepage-based charset such as <code>windows-1252</code> or <code>windows-31j</code>. The method <code>java.nio.charsets.Charset.defaultCharset()</code> returns the default charset. A quick way to see the default charset of the current JDK is with the following command:</p> <pre><code>java -XshowSettings:properties -version 2>&1 | grep file.encoding</code></pre> <p>Several standard Java APIs use the default charset, including:</p> <ul> <li> <p>In the <code>java.io</code> package, <code>InputStreamReader</code>, <code>FileReader</code>, <code>OutputStreamWriter</code>, <code>FileWriter</code>, and <code>PrintStream</code> define constructors to create readers, writers, and print streams that encode or decode using the default charset.</p> </li> <li> <p>In the <code>java.util</code> package, <code>Formatter</code> and <code>Scanner</code> define constructors whose results use the default charset.</p> </li> <li> <p>In the <code>java.net</code> package, <code>URLEncoder</code> and <code>URLDecoder</code> define deprecated methods that use the default charset.</p> </li> </ul> <p>We propose to change the specification of <code>Charset.defaultCharset()</code> to say that the default charset is <a href="https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/nio/charset/Charset.html#standard">UTF-8</a> unless configured otherwise by an implementation-specific means. (See below for how to configure the JDK.) The UTF-8 charset is specified by <a href="http://www.ietf.org/rfc/rfc2279.txt">RFC 2279</a>; the transformation format upon which it is based is specified in Amendment 2 of ISO 10646-1 and is also described in the <a href="http://www.unicode.org/standard/standard.html">Unicode Standard</a>. It is not to be confused with <a href="https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/DataInput.html#modified-utf-8">Modified UTF-8</a>.</p> <p>We will update the specifications of all standard Java APIs that use the default charset to cross-reference <code>Charset.defaultCharset()</code>. Those APIs include the ones listed above, but not <code>System.out</code> and <code>System.err</code>, whose charset will be as specified by <a href="https://bugs.openjdk.java.net/browse/JDK-8264208"><code>Console.charset()</code></a>.</p> <h3 id="The-file-encoding-and-native-encoding-system-properties">The <code>file.encoding</code> and <code>native.encoding</code> system properties</h3> <p>As envisaged by the specification of <code>Charset.defaultCharset()</code>, the JDK will allow the default charset to be configured to something other than UTF-8. We will revise the treatment of the system property <code>file.encoding</code> so that setting it on the command line is the supported means of configuring the default charset. We will specify this in an implementation note of <a href="https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/System.html#getProperties()"><code>System.getProperties()</code></a> as follows:</p> <ul> <li> <p>If <code>file.encoding</code> is set to <code>"COMPAT"</code> (i.e., <code>java -Dfile.encoding=COMPAT</code>), then the default charset will be the charset chosen by the algorithm in JDK 17 and earlier, based on the user's operating system, locale, and other factors. The value of <code>file.encoding</code> will be set to the name of that charset.</p> </li> <li> <p>If <code>file.encoding</code> is set to <code>"UTF-8"</code> (i.e., <code>java -Dfile.encoding=UTF-8</code>), then the default charset will be UTF-8. This no-op value is defined in order to preserve the behavior of existing command lines.</p> </li> <li> <p>The treatment of values other than <code>"COMPAT"</code> and <code>"UTF-8"</code> are not specified. They are not supported, but if such a value worked in JDK 17 then it will likely continue to work in JDK 18.</p> </li> </ul> <p><strong>Prior to deploying on a JDK where UTF-8 is the default charset, developers are strongly encouraged to check for charset issues by starting the Java runtime with <code>java -Dfile.encoding=UTF-8 ...</code> on their current JDK (8-17).</strong></p> <p>JDK 17 introduced the <a href="https://bugs.openjdk.java.net/browse/JDK-8265989"><code>native.encoding</code></a> system property as a standard way for programs to obtain the charset chosen by the JDK's algorithm, regardless of whether the default charset is actually configured to be that charset. In JDK 18, if <code>file.encoding</code> is set to <code>COMPAT</code> on the command line, then the run-time value of <code>file.encoding</code> will be the same as the run-time value of <code>native.encoding</code>; if <code>file.encoding</code> is set to <code>UTF-8</code> on the command line, then the run-time value of <code>file.encoding</code> may differ from the run-time value of <code>native.encoding</code>.</p> <p>In <em>Risks and Assumptions</em> below, we discuss how to mitigate the possible incompatibilities that arise from this change to <code>file.encoding</code>, as well as the <code>native.encoding</code> system property and recommendations for applications.</p> <p>There are three charset-related system properties used internally by the JDK. They remain unspecified and unsupported, but are documented here for completeness:</p> <ul> <li> <p><code>sun.stdout.encoding</code> and <code>sun.stderr.encoding</code> — the names of the charsets used for the standard output stream (<code>System.out</code>) and standard error stream (<code>System.err</code>), and in the <code>java.io.Console</code> API.</p> </li> <li> <p><code>sun.jnu.encoding</code> — the name of the charset used by the implementation of <code>java.nio.file</code> when encoding or decoding filename paths, as opposed to file contents. On macOS its value is <code>"UTF-8"</code>; on other platforms it is typically the default charset.</p> </li> </ul> <h3 id="Source-file-encoding">Source file encoding</h3> <p>The Java language allows source code to express Unicode characters in a <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-3.html#jls-3.1">UTF-16 encoding</a>, and this is unaffected by the choice of UTF-8 for the default charset. However, the <code>javac</code> compiler is affected because it assumes that <code>.java</code> source files are encoded with the default charset, unless configured otherwise by the <code>-encoding</code> <a href="https://docs.oracle.com/en/java/javase/16/docs/specs/man/javac.html#standard-options">option</a>. If source files were saved with a non-UTF-8 encoding and compiled with an earlier JDK, then recompiling on JDK 18 or later may cause problems. For example, if a non-UTF-8 source file has string literals that contain non-ASCII characters, then those literals may be misinterpreted by <code>javac</code> in JDK 18 or later unless <code>-encoding</code> is used.</p> <p><strong>Prior to compiling on a JDK where UTF-8 is the default charset, developers are strongly encouraged to check for charset issues by compiling with <code>javac -encoding UTF-8 ...</code> on their current JDK (8-17). Alternatively, developers who prefer to save source files with a non-UTF-8 encoding can prevent <code>javac</code> from assuming UTF-8 by setting the <code>-encoding</code> option to the value of the <code>native.encoding</code> system property on JDK 17 and later.</strong></p> <h3 id="The-legacy-default-charset">The legacy <code>default</code> charset</h3> <p>In JDK 17 and earlier, the name <code>default</code> is recognized as an alias for the <code>US-ASCII</code> charset. That is, <code>Charset.forName("default")</code> produces the same result as <code>Charset.forName("US-ASCII")</code>. The <code>default</code> alias was introduced in JDK 1.5 to ensure that legacy code which used <code>sun.io</code> converters could migrate to the <code>java.nio.charset</code> framework introduced in JDK 1.4.</p> <p>It would be extremely confusing for JDK 18 to preserve <code>default</code> as an alias for <code>US-ASCII</code> when the default charset is specified to be <code>UTF-8</code>. It would also be confusing for <code>default</code> to mean <code>US-ASCII</code> when the user configures the default charset to its pre-JDK 18 value by setting <code>-Dfile.encoding=COMPAT</code> on the command line. Redefining <code>default</code> to be an alias not for <code>US-ASCII</code> but rather for the default charset (whether <code>UTF-8</code> or user-configured) would cause subtle behavioral changes in the (few) programs that call <code>Charset.forName("default")</code>.</p> <p>We believe that continuing to recognize <code>default</code> in JDK 18 would be prolonging a poor decision. It is not defined by the Java SE Platform, nor is it recognized by IANA as the name or alias of any character set. In fact, for ASCII-based network protocols, IANA encourages use of the canonical name <code>US-ASCII</code> rather than just <code>ASCII</code> or obscure aliases such as <code>ANSI_X3.4-1968</code> -- plainly, use of the JDK-specific alias <code>default</code> goes counter to that advice. Java programs can use the enum constant <code>StandardCharsets.US_ASCII</code> to make their intent clear, rather than passing a string to <code>Charset.forName(...)</code>.</p> <p>Accordingly, in JDK 18, <code>Charset.forName("default")</code> will throw an <code>UnsupportedCharsetException</code>. This will give developers a chance to detect use of the idiom and migrate to either <code>US-ASCII</code> or to the result of <code>Charset.defaultCharset()</code>.</p> <h2 id="Testing">Testing</h2> <ul> <li> <p>Significant testing is required to understand the extent of the compatibility impact of this change. Testing by developers or organizations with geographically diverse user populations will be needed.</p> </li> <li> <p>Developers can check for issues with an existing JDK release by running with <code>-Dfile.encoding=UTF-8</code> in advance of any early-access or GA release with this change.</p> </li> </ul> <h2 id="Risks-and-Assumptions">Risks and Assumptions</h2> <p>We assume that applications in many environments will see no impact from Java's choice of <code>UTF-8</code>:</p> <ul> <li> <p>On macOS, the default charset has been UTF-8 for several releases, except when configured to use the POSIX C locale.</p> </li> <li> <p>In many Linux distributions, though not all, the default charset is UTF-8, so no change will be discernible in those environments.</p> </li> <li> <p>Many server applications are already started with <code>-Dfile.encoding=UTF-8</code>, so they will not experience any change.</p> </li> </ul> <p>In other environments, the risk of changing the default charset to <code>UTF-8</code> after more than 20 years may be significant. The most obvious risk is that applications which implicitly depend on the default charset (e.g., by not passing an explicit charset argument to APIs) will behave incorrectly when processing data produced when the default charset was unspecified. A further risk is that data corruption may silently occur. We expect the main impact will be to users of Windows in Asian locales, and possibly some server environments in Asian and other locales. Possible scenarios include:</p> <ul> <li> <p>If an application that has been running for years with <code>windows-31j</code> as the default charset is upgraded to a JDK release that uses UTF-8 as the default charset then it will experience problems when reading files that are encoded in <code>windows-31j</code>. In this case, the application code could be changed to pass the <code>windows-31j</code> charset when opening such files. If the code cannot be changed, then starting the Java runtime with <code>-Dfile.encoding=COMPAT</code> will force the default charset to be <code>windows-31j</code> until the application is updated or the files are converted to UTF-8.</p> </li> <li> <p>In environments where several JDK versions are in use, users might not be able to exchange file data. If, e.g., one user uses an older JDK release where <code>windows-31j</code> is the default and another uses a newer JDK where UTF-8 is the default, then text files created by the first user might not be readable by the second. In this case the user on the older JDK release could specify <code>-Dfile.encoding=UTF-8</code> when starting applications, or the user on the newer release could specify <code>-Dfile.encoding=COMPAT</code>.</p> </li> </ul> <p>Where application code can be changed, then we recommend it is changed to pass a charset argument to constructors. If an application has no particular preference among charsets, and is satisfied with the traditional environment-driven selection for the default charset, then the following code can be used <em>on all Java releases</em> to obtain the charset determined from the environment:</p> <pre><code>String encoding = System.getProperty("native.encoding"); // Populated on Java 18 and later Charset cs = (encoding != null) ? Charset.forName(encoding) : Charset.defaultCharset(); var reader = new FileReader("file.txt", cs);</code></pre> <p>If neither application code nor Java startup can be changed, then it will be necessary to inspect the application code to determine manually whether it will run compatibly on JDK 18.</p> <h2 id="Alternatives">Alternatives</h2> <ul> <li> <p><em>Preserve the status quo</em> — This does not eliminate the hazards described above.</p> </li> <li> <p><em>Deprecate all methods in the Java API that use the default charset</em> — This would encourage developers to use constructors and methods that take a charset parameter, but the resulting code would be more verbose.</p> </li> <li> <p><em>Specify UTF-8 as the default charset without providing any means to change it</em> — The compatibility impact of this change would be too high.</p> </li> </ul> </div></div><div id="sidebar"><div id="openjdk-sidebar-logo"><a href="/"><img alt="OpenJDK logo" width="91" height="25" src="/images/openjdk2.svg" /></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 class="link"><a href="https://mastodon.social/@openjdk" rel="me">Mastodon</a></div><div class="link"><a href="https://bsky.app/profile/openjdk.org">Bluesky</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/23">23</a>, <a href="/projects/jdk/24">24</a>, <a href="/projects/jdk/25">25</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" width="100" height="13" src="/images/oracle.svg" /></a></div></div><div id="footer"> © 2025 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="/uRxzba/Rr/-0/1F1q/XDCvs8JPP2B6Y/uuuzSDmNYmrh/ZHE1PQ/SXF/kNSQ_NgMC"></script></body></html>