Carrier classes are Project Amber’s current idea to extend some of records’ benefits to regular classes. Probably the most important among them is deconstruction, which would allow classes to participate in pattern matching and reconstruction. In recent weeks, there have been two mails to the Amber mailing list that describe that idea, and in this episode we discuss them both as well as the evolution between them. We also hear why syntax discussions often provide negative value and get a sneak peak at what will likely be the next Project Amber language feature.

Just ahead of the JavaOne speakers dinner, Nicolai Parlog sits down with Brian Goetz, Java Language Architect in Oracle’s Java Platform Group, for this “Ask the Architect” episode of the Inside Java Podcast.

Links:

• mail #1
• mail #2

Make sure to also check the Duke’s Corner podcast on dev.java.

Additional resources

• Inside.java : News and views from members of the Java team at Oracle
• Dev.java : The Destination for Java Developers
• OpenJDK
• Oracle Java

For more episodes, check out Inside Java, our YouTube playlist, and follow @Java on Twitter.

Contact us here.

Building a compelling desktop app today requires features such as UI controls, charts, interactive media, web content, animation, CSS styling, 2D and 3D rendering, rich text, and property binding, with an easy-to-use programming paradigm that runs cross-platform. JavaFX is all this and more, delivering a rich graphical UI toolkit for building your applications and can also seamlessly interoperate with Swing.

In this session you’ll learn about the new and exciting features we’ve developed over the past couple of years, culminating with the release of JavaFX 26. You’ll also get an update on RichTextArea. We’ll show plenty of demos and sample code, and finish with a sneak peek at what’s coming next.

Make sure to check the JavaOne 2026 playlist.

_Let’s quickly review in definitely under 3 minutes the 10 JEPs (JDK Enhancement Proposals) that were included in the JDK 26 release! Couldn’t make it to JavaOne? Catch the biggest moments by joining us on our livestreams for the opening Keynote and Community Keynotes right here on the Java YouTube Channel! _

Make sure to check the show-notes.

Cloud native adoption is now mainstream. Kubernetes usage in production has soared to 82% among container[1], and Java applications constitute a substantial share within those clusters. As Kubernetes adoption continues to grow, the need for monitoring, managing and observing Java applications in containers have become more crucial…

In cloud-native architectures, services are typically decomposed into many microservices running across multiple pods. As a result, effective troubleshooting and performance analysis depend on correlating telemetry data (logs, metrics, and traces) across services and performing cross-JVM analysis to diagnose bottlenecks.

While managed Kubernetes platforms provide infrastructure-level metrics such as CPU, memory, logs, and pod health, they do not natively expose JVM-level diagnostic data. JDK Flight Recorder (JFR) is a JVM specific tool that provide these diagnostics such as garbage collection behaviour, allocation profiling, lock contention, safe point analysis, CPU profile shifts, and thread state transitions.

Java Management Service (JMS) in OCI leverages the JFR capabilities to address this gap by providing secure, fleet-scale orchestration of JFR across distributed Kubernetes environments.

Challenges in Getting JVM Diagnostics in Kubernetes

Traditional approach to get JVM diagnostics is by accessing the running JVM directly via JMX or command-line tools like jcmd. However, modern microservices architecture introduces following complexities:

• Services run across hundreds or thousands of pods.
• Containers are ephemeral.
• Direct shell access is restricted.
• JMX ports are restricted due to security and compliance policies.

These complexities introduce several operational challenges:

• Orchestration of JFRs across hundreds of distributed JVM instances demands a scalable and centralized management approach capable of operating reliably in dynamic Kubernetes environments.
• A recording mechanism that is resilient to pod lifecycle events.
• Large scale storage coordination- for example, capturing 24 hour recording with an average size of 1-2 GB per pod across 100 pods results in approximately 200 GB of diagnostic data.
• Direct shell access is often restricted, and exposing JMX endpoints for profiling increases the security surface area.
• Slim JRE builds or jlink-generated runtimes, which may limit the availability of diagnostic utilities within the container.

Secure JFR Orchestration with Java Management Service (JMS)

JMS, an OCI native service, provides monitoring and management for Java workloads. It extends OCI observability by enabling secure, scalable JFR captures across Kubernetes clusters without exposing the JMX endpoints or requiring direct container access. It is implemented as a plugin to the Oracle Management Agent (OMA)[3] and key capabilities includes:

• Discovery of JVM running inside Kubernetes
• Identification of runtimes below defined security baselines
• Fleet-wide JFR recordings across pods
• JFR recording scheduler
• Secure export of JFR Recording to an OCI object store
• Integration to JMS advanced features using JFRs
• Performance improvement recommendation to fine tune JVM Parameters
  • Detection of deprecated cryptographic algorithms in Oracle JDK

JMS enables centralized capture of JFR recordings from a specific container or across selected application containers within a cluster. Through the JMS console or APIs, administrators can select the target workload, configure recording parameters, and initiate a JFR capture request. Upon completion, the recordings from each container are automatically exported to the designated Object Storage bucket. These recordings can then be analysed to diagnose performance bottlenecks, optimize resource utilization, and gain actionable insights into Java application behaviour.

Figure 1: Architecture Overview

JMS integrates with the Oracle Management Agent (OMA) service, which is deployed in the Kubernetes cluster using the OCI Kubernetes Monitoring Solution[2]. The JMS plugin runs within the OMA pod and interacts with application pods to collect Java telemetry data and perform JFR operations.

The JMS plugin communicates with the JMS service running in OCI to transmit telemetry data and manage JFR capture requests. Using Kubernetes client APIs, the plugin discovers Java workloads in the cluster, retrieves Java runtime usage details, and executes commands within the application containers to start and stop JFR recordings. The captured telemetry and JFR data are sent securely to JMS service and Object storage respectively. The JMS console displays this data, providing insights into Java runtime versions and application details across the Kubernetes environment.

Common Use Cases and Operational Workflow

A. Out-of-the-Box (OOTB) Capabilities in JMS

A.1. One Click JFR Across Cluster

Administrators can monitor Java application in active containers and trigger or schedule JFRs.

Operational workflow:

• Onboard the Kubernetes cluster to JMS
• Discover active Java containers
• Identify Java runtime versions below security baseline
• Trigger JFR with single click
• Export recordings for analysis using tools such as JDK Mission Control

Figure 2: JMS Console displaying active Java containers and JFR controls

A.2. Incident Response at Fleet Scale

In case of an incident, administrators can trigger JFR across all replicas in a single action during live production troubleshooting.

B. Customer-Implemented Patterns Using JMS + OCI Services

B.1. Automating JFR trigger based on Kubernetes Metrics

JMS can be integrated with OCI Monitoring to trigger JFR based on real time Kubernetes metrics.

Operational workflow:

• Pre-configure rules based on desired Kubernetes metrics into OCI Monitoring service
• OMA collects Kubernetes metrics (example CPU/memory)
• OCI Monitoring evaluates threshold rules
• OCI Alarm is triggered when thresholds breach
• OCI Function processes the events
• JMS APIs triggers JFR on impacted load

(Phase enhancements are planned to reduce trigger latency (~ 10 minutes) for near-immediate recordings)

B.2. Post Deployment Validation

Automatically capture JFR for a fixed duration after each production deployment and detect performance regression early.

Operational workflow:

• Integrate JFR recordings in production using automation
• Compare CPU profile shifts, Allocation rate
• Validate behavioral consistency against baseline

B.3. Post PSU/CPU Patching or Infrastructure Upgrade Analysis

Run JFR for 48–72 hours after and compare allocation rate, thread states, blocking time, CPU profile shifts. This reduces MTTR and prevents regression from surfacing an alert noise.

Conclusion

As Kubernetes adoption accelerates, infrastructure-level observability is no longer enough for Java workloads. Organizations need secure JVM intelligence embedded into their cloud operations model. With JMS, OCI provides a centralized framework for Java runtime governance and fleet-scale JFR orchestration across cloud native environments.

References

• [1] CNCF Annual Cloud Native Survey Jan 2026
• [2] OCI Kubernetes Monitoring
• [3] Oracle Management Agent (OMA)

Additional Resources

• Java Management Service (JMS)
• JMS Kubernetes Agent
• Live labs for Java management Service (JMS)

Java 26 is getting all packaged up to be shipped worldwide! As with every release of the JDK there are a number of new features, improvements, changes in behavior, and more developers should be aware of before upgrading. In this episode of the Inside Java Newscast we will review all the noteworthy changes coming in Java 26 that will impact developers.

Links to JDK Enhancement Proposals (JEPs):

• JEP 500 - Prepare to Make Final Mean Final
• JEP 504 - Remove the Applet API
• JEP 516 - Ahead-of-Time Object Caching with Any GC
• JEP 517 - HTTP/3 for the HTTP Client API
• JEP 522 - G1 GC: Improve Throughput by Reducing Synchronization
• JEP 524 - PEM Encodings of Cryptographic Objects (Second Preview)
• JEP 525 - Structured Concurrency (Sixth Preview)
• JEP 526 - Lazy Constants (Second Preview)
• JEP 529 - Vector API (Eleventh Incubator)
• JEP 530 - Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Links to JDK Bug Systems (JBS) tickets:

• JDK-8371470 - Java Launcher does not fail when running compact java-file with private no-arg constructor
• JDK-8346944 - Update Unicode Data Files to 17.0.0
• JDK-8354548 - Update CLDR to Version 48.0
• JDK-8364361 - [process] java.lang.Process should implement Closeable
• JDK-8369432 - Add Support for JDBC 4.5 MR
• JDK-8363972 - Lenient parsing of minus sign pattern in DecimalFormat/CompactNumberFormat
• JDK-8342705 - Add dark mode for docs
• JDK-8356557 - Update CodeSource::implies API documentation and deprecate java.net.SocketPermission class for removal
• JDK-8366577 - Deprecate java.net.Socket::setPerformancePreferences
• JDK-8277585 - Remove the terminally deprecated finalize() method from javax.imageio.stream APIs
• JDK-8368226 - Remove Thread.stop
• JDK-8366575 - Remove SDP support
• JDK-8366911 - (fs) Remove support for normalizing file names to Unicode normalized form D (macOS)
• JDK-8351413 - Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport
• JDK-8359760 - Remove the jdk.jsobject module
• JDK-8357653 - Inner classes of type parameters emitted as raw types in signatures
• JDK-8370387 - Remove handling of InterruptedIOException from java.io classes
• JDK-8361614 - Missing sub-int value validation in the Class-File API
• JDK-8361635 - Missing List length validation in the Class-File API
• JDK-8362637 - Convert java.nio.ByteOrder to an enum
• JDK-8362448 - Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
• JDK-8268406 - Deallocate jmethodID native memory
• JDK-8369517 - Compilation mismatch for equivalent lambda and method reference
• JDK-8347831 - Re-examine version check when cross linking

Make sure to also check the Duke’s Corner podcast on dev.java.

Additional resources

• Inside.java : News and views from members of the Java team at Oracle
• Dev.java : The Destination for Java Developers
• OpenJDK
• Oracle Java

For more episodes, check out Inside Java, our YouTube playlist, and follow @Java on Twitter.

Contact us here.

The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of a regular communication sent to the projects involved. To learn more about the program, and how-to join, please check here.

ISO 639 and BCP 47

BCP 47, first introduced in 1995, defines tags to identify languages and its primary subtag (the first of potentially multiple subtags) is usually drawn from the much older ISO 639-1 standard. There are exceptions, though, among them these three languages:

• Hebrew:
  • ISO 639: iw
  • BCP 47: he
• Indonesian:
  • ISO 639: in
  • BCP 47: id
• Yiddish:
  • ISO 639: ji
  • BCP 47: yi

Past Preference

Before JDK 17, Java treated the ISO-639 tags of these three languages as canonical and mapped the BCP 47 tags to them (see Locale’s documentation under Legacy language codes):

static void printLocales(String iso, String bcp) {
	System.out.println(Locale.forLanguageTag(iso) + " | " + Locale.forLanguageTag(bcp));
}

// on JDK < 17, ISO 639 tags are preferred:
public static void main(String[] args) {
	printLocales("iw", "he"); // ~> "iw | iw"
	printLocales("in", "id"); // ~> "in | in"
	printLocales("ji", "yi"); // ~> "ji | ji"
}

Transition

This changed in JDK 17 and since then the default behavior was to map to BCP 47 tags:

// on JDK 17+, BCP 47 tags are preferred:
public static void main(String[] args) {
	printLocales("iw", "he"); // ~> "he | he"
	printLocales("in", "id"); // ~> "id | id"
	printLocales("ji", "yi"); // ~> "yi | yi"
}

To allow applications to update to Java 17 and later without requiring immediate code changes, the temporary system property java.locale.useOldISOCodes was introduced. Setting it to true reverted to the behavior before Java 17.

New Preference

JDK 25 deprecated java.locale.useOldISOCodes and JDK 27 will remove it. Setting it will result in a warning:

WARNING: The system property "java.locale.useOldISOCodes" is no longer supported. Any specified value will be ignored.

Code that relies on java.locale.useOldISOCodes needs to be updated to consistently expect BCP 47 tags when querying Locale instances. It will remain possible to use the ISO 639 tags to instantiate Locale instances for Hebrew, Indonesian, and Yiddish.