Now that Java 27 is features complete (Rampdown Phase One at the day of writing), it\u2019s time to walk through all the functionalities that bring to us, developers, this new version.<\/p>\n
This article is part of a series on what\u2019s new on the last versions of Java<\/a>, for those who wants to read the others, here are the links: Java 26<\/a>, Java 25<\/a>, Java 24<\/a>, Java 23<\/a>, Java 22<\/a>, Java 21<\/a>, Java 20<\/a>, Java 19<\/a>, Java 18<\/a>, Java 17<\/a>, Java 16<\/a>, Java 15<\/a>, Java 14<\/a>, Java 13<\/a>, Java 12<\/a>, Java 11<\/a>,\u00a0Java 10<\/a>,\u00a0and\u00a0Java 9<\/a>.<\/p>\n After Java 26 and its 10 JEPs, Java 27 arrives with a small number of JEPs, 9, with very few new features.<\/p>\n G1<\/strong> was set as the default Garbage Collector in Java 9. At that time, tests showed that for environments with one CPU (or fewer) and less than 1792 MB of heap, the Serial<\/strong> Garbage Collector was more efficient. The JVM therefore used Serial<\/strong> by default in these cases.<\/p>\n Since then, G1<\/strong> has been improved, and tests have shown that G1<\/strong> is now equivalent to Serial<\/strong> for all heap sizes. With improvements to reduce synchronization (JEP 522<\/a>), G1<\/strong> now performs as well as Serial<\/strong>, even with a reduced number of CPUs. Finally, G1<\/strong> has also seen a reduction in its native memory consumption, reaching levels comparable to those of Serial<\/strong>.<\/p>\n Logically, since G1<\/strong> is equal to or better than Serial<\/strong> on all criteria, even in environments with few CPUs and\/or little RAM, it is now the default in all environments.<\/p>\n More information in JEP 523<\/a>.<\/p>\n Strengthens the security of Java applications requiring secure network communications by implementing hybrid key exchange algorithms<\/a> for TLS 1.3. These algorithms help protect against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional one.<\/p>\n A hybrid key exchange algorithm combines a quantum-resistant algorithm with a traditional one and remains secure as long as one of the two algorithms is not broken. This approach helps protect against quantum attacks while acknowledging that these new algorithms have not yet benefited from the years of testing and analysis already conducted on traditional algorithms.<\/p>\n The JDK’s implementation of TLS 1.3 will support three new post-quantum hybrid key exchange schemes that combine the Module-Lattice-Based Key-Encapsulation Mechanism<\/em> (ML-KEM – added via JEP 496<\/a>) with traditional Ephemeral Elliptic Curve Diffie-Hellman<\/em> (ECDHE) algorithms:<\/p>\n More information in JEP 527<\/a>.<\/p>\n Compact object headers<\/strong> allows the JVM to store object headers in 64 bits instead of 128: 22 bits for the class pointer, 31 bits for the hash code, 4 bits reserved for Valhalla, and the remaining bits as before for GC age and JVM flags.<\/p>\n Compact object headers<\/strong> were introduced as an alternative object header structure in preview in Java 24 via JEP 450<\/a>, and then exited preview in Java 25.<\/p>\n Since then, compact object headers<\/strong> have proven their stability and performance.<\/p>\n They have been tested at Oracle using the JDK’s full test suite. They have also been tested at Amazon and SAP, which have enabled them by default.<\/p>\n Various experiments show that enabling compact object headers<\/strong> improves performance:<\/p>\n In Java 27, compact object headers<\/strong> are enabled by default. The old layout is expected to be deprecated in a future release.<\/p>\n More information in JEP 534<\/a>.<\/p>\n JFR recording files contain command-line arguments as well as environment variable values and system properties, which show how the process was launched and configured. These events can therefore contain sensitive data, such as secrets in command-line arguments, environment variables, and system properties. Currently, this data appears as-is in the recording files, which poses a risk of sensitive information leakage when recordings are shared.<\/p>\n JFR will now mask many types of sensitive information by default, without any additional configuration.<\/p>\n You can explicitly select the information that JFR should mask using new sub-options of the existing command-line option The Filters use glob patterns<\/em>, where For example, to mask any environment variable or system property named “confidential” or “CONFIDENTIAL”, as well as any command-line argument resembling a URL containing a username and password (i.e., username:password@host<\/code>code>username:password@host<\/code<\/a>), use:<\/p>\n To verify that sensitive information has been properly masked, use the The following features comes out of preview (or incubator module) are now standard features:<\/p>\n None!<\/strong><\/p>\n This is rare enough to highlight. Some features that have been in preview for a long time are blocked waiting for the Valhalla project.<\/p>\n The following features remain in preview (or in the incubator module):<\/p>\n For details on these, you can refer to my previous articles.<\/p>\n Various additions to the JDK:<\/p>\n All new APIs in JDK 27 can be found in The Java Version Almanac – New APIs in Java 27<\/a>.<\/p>\n Like all new versions of Java, OpenJDK 27 contains a number of performance optimizations and security enhancements.<\/p>\n On the performance side, I noted two interesting improvements:<\/p>\n On the security side, we can mention:<\/p>\n The experimental JVM Compiler Interface (JVMCI) feature has been removed (JDK-8382582<\/a>). Quoting the release notes:The JVMCI provided an experimental internal Java API for writing a JIT compiler in Java that could be called by Hotspot. After more than a decade of experimentation, the costs of its maintenance and testing within the JDK have outweighed the benefits it provided to the limited number of downstream use cases it addressed. Downstream projects that depend on JVMCI must now integrate and maintain it in their own development trees, or remain on earlier JDK versions.<\/em>\nGraalVM was the most well-known of these projects; the Graal compiler no longer mentions JVMCI in its documentation<\/a>, using the Graal compiler instead of C2 should not be supported anymore.<\/p>\n Here are the new Java Flight Recorder (JFR) events in the JVM:<\/p>\n You can find all JFR events supported in this version of Java on the JFR Events<\/a> page.<\/p>\n Java 27 is a small release with no major changes or new features. The good news is that its successor, Java 28, will very likely include the first phases of the Valhalla project, as JEP 401 – Value Objects<\/a> already has an open PR (#31122<\/a>)!<\/p>\nJEP 523: Make G1 the Default Garbage Collector in All Environments<\/h2>\n
JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3<\/h2>\n
JEP 534: Compact Object Headers by Default<\/h2>\n
\n
JEP 536: JFR In-Process Data Redaction<\/h2>\n
-XX:FlightRecorderOptions<\/code>. Each sub-option specifies one or more filters that select the command-line arguments, environment variables, and system properties to mask.<\/p>\nredact-argument<\/code> sub-option specifies a list of filters for command-line arguments, and the redact-key<\/code> sub-option specifies a list of filters for key-value pairs in the form of environment variables and system properties.<\/p>\n*<\/code> and ?<\/code> are wildcards. If a filter matches an argument or a key, the argument or key value is recorded in the event as [REDACTED]<\/code>. Multiple filters are separated by semicolons and are evaluated in the order specified. The different sub-options of -XX:FlightRecorderOptions<\/code> are separated by commas.<\/p>\n\njava -XX:FlightRecorderOptions:'redact-key=confidential,redact-argument=https:\/\/*:*@*' \\\n -XX:StartFlightRecording:filename=dump.jfr \\\n -Dconfidential=ANOTHER_SECRET \\\n -jar application.jar https:\/\/john:YET_ANOTHER_SECRET@example.com\/login --verbose\n<\/pre>\n
jfr print<\/code> command:<\/p>\n\n$ jfr print \\\n --events InitialSystemProperty,InitialEnvironmentVariable \\\n dump.jfr\n[...]\njdk.InitialEnvironmentVariable {\n startTime = 17:39:02.244 (2026-02-15)\n key = "CONFIDENTIAL"\n value = "[REDACTED]"\n}\n<\/pre>\nFeatures coming out of preview<\/h2>\n
Features that remain in preview<\/h2>\n
isInitialized<\/code> and orElse<\/code>, addition of a factory method Set.ofLazy(...)<\/code>.<\/li>\ninstanceof<\/code> and switch<\/code>, and enhances pattern matching to support primitive type patterns: in instanceof<\/code>, in switch<\/code> cases, and in record deconstruction. No changes.<\/li>\nJoiner<\/code> interface: the join()<\/code> method accepts a third argument for the exception that a StructuredTaskScope<\/code> can throw; awaitAll()<\/code> has been removed in favor of allSuccessfulOrThrow()<\/code>, anySuccessfulOrThrow()<\/code>, and awaitAllSuccessfulOrThrow()<\/code>, which create joiners that throw an ExecutionException<\/code> in case of an exception; onTimeout()<\/code> has been replaced by timeout()<\/code>.<\/li>\nPEM<\/code> class; DEREncodable<\/code> has been renamed to BinaryEncodable<\/code>; added the EncryptedPrivateKeyInfo.getKeyPair()<\/code> method and added a CryptoException<\/code> exception used to signal cryptographic exceptions.<\/li>\n<\/ul>\nMiscellaneous<\/h2>\n
Math.acosh(double)<\/code> and StrictMath.acosh(double)<\/code>: returns the inverse hyperbolic cosine of a double<\/code> value.<\/li>\nMath.asinh(double)<\/code> and StrictMath.asinh(double)<\/code>: returns the inverse hyperbolic sine of a double<\/code> value.<\/li>\nMath.atanh(double)<\/code> and StrictMath.atanh(double)<\/code>: returns the inverse hyperbolic tangent of a double<\/code> value.<\/li>\nString.encodedLength(Charset)<\/code>: returns the length, in bytes, of this string encoded with the specified charset.<\/li>\nBigDecimal.rootn(int, MathContext)<\/code>: returns an approximation of the nth root of this value, rounded according to the context settings.<\/li>\nDateTimeFormatter<\/code> now supports short timezone offsets (+01<\/code> instead of +01:00<\/code>), see JDK-8210336<\/a>.<\/li>\n<\/ul>\nInternal changes, performance, and security<\/h2>\n
\n
HashMap.putAll()<\/code> now has a fast-path when the Map<\/code> is a HashMap<\/code>, which directly calls putHashMapEntries()<\/code>, resulting in a 66-86% improvement (PR #28243<\/a>);<\/li>\n\n
jcmd VM.security_properties<\/code> to list enabled security properties (JDK-8364182<\/a>).<\/li>\n<\/ul>\njcmd<\/code>, the JVM’s all-in-one management command, now supports bash completion (JDK-8357439<\/a>).<\/p>\nJFR Events<\/h2>\n
ShenandoahPromotionInformation<\/code>: no description.<\/li>\n<\/ul>\nConclusion<\/h2>\n