2 What’s New in this Release

Learn about the features, enhancements, and changes made to Oracle Coherence. Oracle updates the release notes periodically after the software release. This document is accurate at the time of publication.

This chapter includes the following sections:

• New Features
  
• Breaking Changes
  
• Deprecated Features
  

New Features

This section describes new and improved capabilities in Oracle Coherence 26.1.0.0.0.

Java SE and Jakarta EE Support for 26.1.0.0.0

• Java SE 25 support. This release adds support for Java SE 25 and continues to support Java SE 21. Java SE 21 is the minimum Java version; Java SE 17 is no longer supported. Upgrade Java on members, clients, build tools, and operational utilities before deploying the new libraries.

• Jakarta EE 11 compatibility. This release adds support for Jakarta EE 11. Check the certified application-server and Jakarta integration combinations for the modules that you deploy. See Jakarta EE 11 Compatibility.

Security Profiles and Application Policy

The default security profile is hardened. It enforces compatibility-sensitive serialization, named executable-class, input, and administrative policies. The separate runtime property coherence.mode continues to control runtime and license behavior.

Applications can generate per-artifact META-INF/coherence/security-config.xml resources from annotations, including @Remote.Allowed, @Remote.Executable, and portable-type metadata. Maven and Gradle tooling support policy generation. Generated configuration makes the application's accepted types and executable classes explicit; it does not authenticate a caller or grant business permissions.

Additional controls cover gRPC authentication, transport and serializer selection; REST resources and input; management, metrics, Reporter and health administration; serializer-owned resource limits; and optional RAG administration and imports. Configure authentication, authorization and TLS for each exposed service. See Securing Oracle Coherence and Security Defaults and Upgrade Preparation.

Unified Journal Persistence

Journal persistence adds an append-oriented persistence engine with checkpointing, recovery, compaction, and migration from Berkeley DB (BDB). Choose the mode that fits the backing-map and recovery requirements.

Table 2-1 Journal Persistence Modes

Mode	Use
Side-channel persistence	Use journal persistence with an existing backing map as an explicitly configured alternative to BDB.
Unified primary backing map	Use <journal-scheme/> so the journal-backed map and persistence share the primary data representation.
Journal backup map	Use <backup-storage><type>journal</type></backup-storage> for journal-backed backup storage. This can be combined with the supported primary modes.

BDB remains the default persistence environment unless journal persistence is explicitly selected. Journal observability includes management statistics, checkpoint operations and Java Flight Recorder events. Follow the supported snapshot-import or rolling-migration procedure when changing persistence formats; see Persistence and Transaction Compatibility.

Virtual Daemon Pools and Platform Pool Improvements

A service can use a virtual daemon pool to execute eligible work on Java virtual threads. Select <daemon-pool>virtual</daemon-pool> on that service's scheme. The platform daemon pool remains the default. Virtual execution is particularly useful when service work blocks, but it does not remove contention, downstream limits, or the need to test the application's workload.

Virtual pools expose task, backlog, pool-type and admission statistics through the Service MBean. An optional <task-limit> provides an aggregate admission ceiling. Platform-thread sizing elements are not substitutes for virtual-pool admission controls.

Platform daemon pools also improve dynamic resizing and cross-queue worker wakeup. Resizing responds to throughput, utilization and sustained blocking within configured bounds; pools without an explicit maximum derive a safety bound from JVM resources. Idle workers can more promptly steal queued work without changing the default work-slot arrangement.

Review Daemon Pool Configuration and Read Quorum Changes before reusing older virtual-thread configuration or read-quorum settings.

Continuous Aggregation

Continuous Aggregation maintains partition-local partial results as cache entries change. The InvocableMap.addAggregator API returns a ContinuousAggregator<K, V, R> handle that combines those partials when queried, reducing repeated full scans for suitable workloads. When maintained state is building or cannot provide an answer, Coherence scans the affected partition before returning the result.

Supported families include count, numeric sums and averages, minimum and maximum, distinct values, reducers, Top-N, groups, and supported composites. Custom aggregators require the continuous-maintenance contract. Retained state, mutation cost and result cardinality should be considered when choosing a registration.

Handles also support key-affinity projections, and entry processors can obtain partition-local registered results. Non-transforming ContinuousQueryCache views compose their view filter with the registration filter; transforming views do not support this registration. Definitions and eligible maintenance state participate in persistence and ownership changes. StorageManager MBean metrics expose registrations, readiness, fallbacks and rebuilds.

In-cluster, Extend and gRPC Java clients can use the feature. Every storage-enabled member of the cache service must support commercial Coherence 26.1.0.0.0 or the corresponding compatible Community Edition capability. Extend requires NamedCache protocol version 13; gRPC requires NamedCache protocol version 2. See Continuous Aggregation During Rolling Upgrade.

Partition-Streamed Queries and Adaptive Aggregation

Eligible partitioned queries and parallel streaming aggregations use bounded service worker lanes for partition processing. This improves use of available execution capacity while preserving index consistency, authorization, query statistics, timeouts, ownership checks and cleanup.

Explicit BY_MEMBER and BY_PARTITION aggregator characteristics remain execution contracts. Unqualified parallel aggregators can choose member or partition granularity according to pool capacity and load. These changes do not add a stronger cross-partition snapshot guarantee.

Extend Request Processing

Extend proxies can automatically grow connection-affine selector and decoding pipelines according to connection density and measured pressure. New connections are assigned across pipelines while preserving connection ownership and ordering.

The TCP acceptor's <pipeline-count> configuration distinguishes automatic operation, a single legacy pipeline and an explicitly fixed topology. ConnectionManager MBean attributes expose configured, active and limiting pipeline counts. Java Extend initiators also use larger stream buffers to reduce socket and framing overhead without a wire-protocol change.

Operational Diagnostics and Native Images

Journal and FlashJournal diagnostics add visibility into writer, congestion, compaction and file lifecycle behavior. Federation reports include additional transport backlog and journal insertion metrics. These measurements help distinguish execution, network and storage constraints.

The Coherence GraalVM native-image feature supplies Coherence-specific native-image registration support. Use the native-image version, dependencies, configuration and platform supported by the chosen distribution; Java library support alone does not establish native-image certification.

Distributed tracing uses OpenTelemetry. OpenTracing support has been removed; see OpenTracing.

Selected Library Updates

The release updates its third-party dependency baselines. Review application-supplied libraries and optional-module dependencies when upgrading.

Table 2-2 Selected Dependency Versions

Library	Release baseline
Netty	4.1.139.Final
OpenTelemetry	1.64.0
Jersey	4.0.2
Jackson	2.21.5
Log4j 2	2.25.4
gRPC	1.75.0
Protocol Buffers	4.31.1

These are release dependency versions, not a statement of the minimum compatible version for every integration. In particular, supply and configure the appropriate OpenTelemetry runtime for the deployment.

Breaking Changes

Learn about updates in Coherence 26 (26.1.0.0.0) that introduce potentially incompatible changes between Coherence releases.

• Java SE 21 Minimum
  
• Jakarta EE 11 Compatibility
  
• Security Defaults and Upgrade Preparation
  
• Java Clients Connecting to Older Servers
  
• Daemon Pool Configuration and Read Quorum Changes
  
• Continuous Aggregation During Rolling Upgrade
  
• Persistence and Transaction Compatibility
  
• Input, Stored-Value and Native Library Compatibility
  
• OpenTracing
  

Java SE 21 Minimum

Java SE 17 and older runtimes cannot run this release. Upgrade the JDK used by servers, Java clients, command-line tools, build jobs and container images to a supported Java SE 21 or Java SE 25 combination before replacing Coherence libraries. Confirm the complete operating-system and application-server combination using Certification Information.

Jakarta EE 11 Compatibility

Coherence 26.1.0.0.0 adds Jakarta EE 11 compatibility. Align the application's servlet, REST, injection and related integration dependencies with the supported module and container combination. Do not mix incompatible Java EE and Jakarta API variants on the same application class path.

Use the target release's compatibility and certification information to determine the supported application-server versions and migration requirements. See Jakarta EE Compatibility in Installing Oracle Coherence and Certification Information.

Security Defaults and Upgrade Preparation

Starting with Coherence 26.1.0.0.0, omitting the security-mode property selects hardened. Runtime coherence.mode=prod is independent. A blank or unrecognized security-profile value fails configuration resolution.

Table 2-3 Security Upgrade Actions

Area	Changed behavior	Preparation
Global profile	An unset coherence.security.mode selects hardened.	Prepare the application and configuration before first startup. If a temporary migration phase is needed, explicitly set -Dcoherence.security.mode=compatibility on the affected upgraded process before starting it.
Application types and named executables	Hardened checks class allowlists and named remote executable classification at the applicable boundary.	Generate and deploy security configuration on receivers. Classify processors, aggregators, filters, extractors, tasks and other remote executable classes, including nested state and custom lambda targets.
Extend identity and service exposure	The default hardened asserter rejects non-null wire identity tokens; InvocationService and Concurrent Extend proxy defaults are disabled.	Configure a validating identity transformer/asserter chain. Enable an intended remote proxy explicitly with coherence.invocation.enabled=true or coherence.concurrent.extend.enabled=true, with authentication and authorization prepared.
Management and metrics HTTP	The shipped hardened authentication default is basic. Explicit compatibility uses none; configured overrides remain possible.	Prepare management clients and scrapers. Set the intended authentication and TLS configuration consistently across endpoint members before upgrade.
Serializer container limits	Hardened defaults are 64 MiB of container bytes, 262144 elements and 131072 map entries at the documented serializer-owned checks.	Test legitimate largest payloads. Configure a reviewed bound where required; these limits are not a universal process allocation budget.
REST and JSON	Hardened REST requires declared resources and approved input. Hardened JSON class metadata requires exact configured aliases.	Declare resources, enable direct queries only where intended, configure expression/type aliases, and verify the consuming marshaller. Package aliases do not satisfy the hardened JSON class-metadata requirement.
gRPC	Authentication and secure transport are explicitly configured. Hardened policy refuses Basic credentials over an insecure network transport and constrains serializer names and diagnostic exposure.	Configure the proxy and client together. Prepare custom serializer allowlists and TLS providers; choosing hardened does not itself provision TLS or an authentication scheme.
TLS and signed identity	Hardened hostname verification and access-controller signing policy are stricter. TLS references retain the intended DNS or numeric identity.	Use certificates whose subject alternative names match the actual endpoint identity. Prepare modern signing keys and trust; test real endpoint names and reconnections.
Reporter and JMX	Hardened policy restricts administrative targets, Reporter sources/output paths and dynamic RMI stub publication.	Approve required report sources and output roots. Configure static JMX publication, including coherence.management.remote.registryport when applicable, and verify management tooling.

The current dynamic remote-code default is allow in both security profiles. To refuse the paths governed by the shared dynamic gate, explicitly set coherence.remote.dynamic.unauthenticated=deny. This includes DYNAMIC lambda bytecode, reflective MethodInvocationProcessor, script execution and dynamic remote installs. Allowance does not bypass bytecode, lambda-target, script host-access or caller checks. Some dynamic install routes can be allowed without a named executable-class entry; do not infer dynamic default-deny from the hardened profile.

The default POF context requires registered type identifiers. Use SafeConfigurablePofContext only as an explicitly selected compatibility context where needed; SerializableSerializer is not registered by the default product POF configuration. Confirm serializers, POF registrations and generated security resources together on each receiver.

JMXMP binds to loopback by default and requires a configured authenticator. Before connector creation it uses an existing JVM-wide object-input filter or installs and verifies its constrained fallback. Review that process-wide effect with other libraries rather than assuming an absent preconfigured filter always prevents startup.

Health mutators remain separately disabled by default. Explicit enablement requires supported authentication. Storage authorization remains an explicitly configured application policy. The hardened profile does not supply business roles, keys, credentials or TLS identities.

If compatibility is used temporarily, collect available shadow diagnostics and test the actual workload under hardened policy before completing migration. A class-policy shadow event is not proof of the final result on every dynamic route, and it does not measure all deserialization or lambda checks. See Securing Oracle Coherence.

Java Clients Connecting to Older Servers

A 26.1 Java client using compute or replaceAll operations against 14.1.2 or 15.1.1 servers must explicitly select coherence.security.mode=compatibility on the client before Coherence initializes. The hardened client can select newer named processor representations that those older servers do not recognize.

Verify the supported client/server and serializer combinations for the deployment, including failover and all APIs in use. Treat client interoperability and the security profile of upgraded 26.1 servers as separate deployment settings.

Daemon Pool Configuration and Read Quorum Changes

The former <virtual-threads-enabled> operational element and coherence.virtualthreads.enabled properties, including service-specific variants, are removed. The old switch did not provide the new virtual daemon pool. Remove it and select virtual execution per service with <daemon-pool>virtual</daemon-pool>. XML containing the removed element fails the updated schema; the removed properties are no longer read.

When selecting a virtual pool, replace incompatible platform-thread sizing settings with the supported virtual-pool admission configuration. The default service pool remains platform-based.

get and getAll on read-through-capable or sliding-expiry caches are now treated as write-shaped operations for quorum and execution routing because they can commit replicated state. Deployments that configured only read quorum can now see these operations subject to write quorum. Review service quorum settings and custom backing-map classification; do not assume every API named as a read is mutation-free.

Continuous Aggregation During Rolling Upgrade

Continuous Aggregation registration, removal and handle queries require all storage-enabled members of the cache service to advertise the compatible capability. These operations fail with UnsupportedOperationException while older storage members remain during upgrade or downgrade. Ordinary cache operations and on-demand aggregation remain available.

Complete the storage-member upgrade and use compatible clients and proxies before registering or querying maintained results. A compatible transport connection alone does not establish feature support. Retain the defining classes and their security configuration for persistence recovery. Transforming ContinuousQueryCache views do not support registration.

Persistence and Transaction Compatibility

Changing from BDB to journal persistence is a data-format migration. Use the supported BDB snapshot-import or rolling-restart procedure and keep a tested backup and rollback plan. BDB remains the default unless journal persistence is explicitly configured; do not point an arbitrary new store at old active files and assume format compatibility.

Transaction exception and XID bridges accept narrow supported type sets. The POF XID writer normalizes XIDs to the supported representation; tightened readers reject arbitrary legacy custom serializable XID implementations. Complete or explicitly test prepared XA work that depends on such implementations before mixed-version traffic can reach the new reader.

Transaction message bindings use typed POF fields 4 through 9. New readers do not materialize legacy binding field 2, so a legacy-only sender can yield empty bindings. Coordinate binding-dependent transaction traffic during rolling upgrade. Supported exception graphs are bounded, including a 16384-element bridge array ceiling; translate or trim unsupported state before transmission.

Persisted topic subscriber executable metadata is rechecked on replay. Hardened policy defaults to rejecting executable-policy drift; coherence.topics.persisted.policy-drift=warn-allow is a deliberate migration option. Keep the metadata's classes and executable policy available on recovery members.

Input, Stored-Value and Native Library Compatibility

Malformed, overflowing or truncated serialized containers and native index inputs are rejected at the documented boundaries. Memcached-origin stored values no longer permit arbitrary serialized object terminal forms through binary pass-through; the supported scalar/binary forms and the narrow configured-serializer interoperability path remain available.

Use the HNSW native binary supplied for the matching Java module, operating system and architecture. The macOS x86_64 HNSW library is no longer supplied. Do not copy an older native library into a newer installation to bypass input validation or platform availability.

Optional RAG deployments must prepare supported authentication, administrator roles and explicit import/model policy. Hardened model download rejects an empty model allowlist. HTTP imports use the approved direct transport and validate redirect destinations; selected proxies are refused. Local imports require supported secure directory traversal and protected roots. Consult the security guide for the exact optional-module controls.

OpenTracing

OpenTracing integration is removed in Coherence 26.1.0.0.0. Replace OpenTracing dependencies and initialization with the supported OpenTelemetry integration.

Coherence does not supply a tracing implementation for the application's runtime. Provide the supported OpenTelemetry dependencies and configure initialization and export for the deployment. Do not treat the old OpenTracing libraries as a compatibility switch.

See Distributed Tracing in Developing Applications with Oracle Coherence.

Deprecated Features

Deprecated features are distinct from features removed in this release. Deprecated features may still be available but subject to their documented restrictions.

Table 2-4 Removed Features and Replacements

Removed item	Replacement or action
Java SE 17 runtime support	Use a supported Java SE 21 or Java SE 25 combination. See Java SE 21 Minimum.
OpenTracing integration	Use OpenTelemetry. See OpenTracing.
<virtual-threads-enabled> and coherence.virtualthreads.enabled	Use the per-service <daemon-pool> configuration. See Daemon Pool Configuration and Read Quorum Changes.

Review the deprecation notices in the Java API reference for individual APIs and the certification information for supported runtime and container combinations. Do not interpret a removed runtime or integration as a still-supported deprecated option.