operator-framework · csviri · Jul 3, 2026 · Jul 29, 2026 · Aug 1, 2026 · Jul 23, 2026
diff --git a/.github/workflows/e2e-test.yml b/.github/workflows/e2e-test.yml
@@ -25,6 +25,7 @@ jobs:
           - "sample-operators/webpage"
           - "sample-operators/leader-election"
           - "sample-operators/operations"
+          - "sample-operators/kotlin-operator"
     runs-on: ubuntu-latest
     steps:
       - name: Checkout

diff --git a/README.md b/README.md
@@ -65,19 +65,21 @@ projects want to advertise that fact here. For this reason, we ask that if you'd
 to be featured in this section, please open a PR, adding a link to and short description of your 
 project, as shown below:
 
-- [kroxylicious](https://github.com/kroxylicious/kroxylicious/tree/main/kroxylicious-kubernetes/kroxylicious-operator) Kafka proxy operator  
-- [ExposedApp operator](https://github.com/halkyonio/exposedapp-rhdblog): a sample operator 
-  written to illustrate JOSDK concepts and its Quarkus extension in the ["Write Kubernetes 
-  Operators in Java with the Java Operator SDK" blog series](https://developers.redhat.com/articles/2022/02/15/write-kubernetes-java-java-operator-sdk#).
-- [Keycloak operator](https://github.com/keycloak/keycloak/tree/main/operator): the official
-  Keycloak operator, built with Quarkus and JOSDK.
-- [Apache Flink Kubernetes operator](https://github.com/apache/flink-kubernetes-operator) is the market leader among Flink operators.
+- [Apache Flink Kubernetes Operator](https://github.com/apache/flink-kubernetes-operator) is the market leader among Flink operators.
 - [Apache Spark Kubernetes Operator](https://github.com/apache/spark-kubernetes-operator) emerging operator for Spark.
+- [kroxylicious](https://github.com/kroxylicious/kroxylicious/tree/main/kroxylicious-kubernetes/kroxylicious-operator) Kafka proxy operator
+- [Debezium Operator](https://github.com/debezium/debezium-operator): Debezium Operator adds Change-Data-Capture capabilities to your Kubernetes or OpenShift cluster by providing an easy way to run and manage [Debezium Server](https://debezium.io/documentation/reference/stable/operations/debezium-server.html) instances.
+- [Keycloak operator](https://github.com/keycloak/keycloak/tree/main/operator): the official Keycloak operator, built with Quarkus and JOSDK.
+- [Apache Hive Kubernetes Operator](https://github.com/apache/hive/tree/master/packaging/src/kubernetes/src/java/org/apache/hive/kubernetes/operator)
+- [OpenMetadata Operator](https://github.com/open-metadata/OpenMetadata/tree/main/openmetadata-k8s-operator) for AI context, data cataloging, and metadata management service
 - [Strimzi Access operator](https://github.com/strimzi/kafka-access-operator). While the core Strimzi operator development predates  
   JOSDK, but new components like the Access operator is using the framework.
+- [Wanaku](https://github.com/wanaku-ai/wanaku/tree/main/apps/wanaku-operator) MCP Router Operator
+- [Apicurio Registry Operator](https://github.com/Apicurio/apicurio-registry/tree/main/operator) 
+- [Kaap](https://github.com/datastax/kaap) autoscaling Operator for Apache Pulsar
 - [EureKubeOperator](https://medium.com/@heesuk.dev/implementing-kubernetes-operator-for-eureka-service-discovery-integration-by-java-operator-sdk-d21d8087c38e): integrates service discovery of Eureka and Kubernetes using the framework - developed by 11street. It is not released as an open source yet but is very interesting to read about this problem and how it is solved by an operator written with JOSDK.
 - [Locust k8s operator](https://github.com/AbdelrhmanHamouda/locust-k8s-operator): Cloud native solution to run performance tests on any Kubernetes cluster.
-- [Strimzi Schema Registry Operator](https://github.com/shangyuantech/strimzi-registry-ksql-operator): A Schema Registry Operator based on JOSDK for running the Confluent Schema Registry with a Strimzi-based Kafka cluster.
-- [Airflow Dag Operator](https://github.com/cdmikechen/airflow-dag-operator): Use JOSDK(Quarkus Extension) to replace Airflow Git Sync strategy. The main idea of the project is to start a synchronization container on each airflow pod to synchronize the DAG/files into the DAG folder.
+- [ExposedApp operator](https://github.com/halkyonio/exposedapp-rhdblog): a sample operator
+  written to illustrate JOSDK concepts and its Quarkus extension in the ["Write Kubernetes
+  Operators in Java with the Java Operator SDK" blog series](https://developers.redhat.com/articles/2022/02/15/write-kubernetes-java-java-operator-sdk#).
 - [Glasskube Operator](https://github.com/glasskube/operator): simplifies the deployment, maintenance and upgrade of popular open source business tools. It is written in Kotlin and uses the JOSDK and fabric8 Kubernetes client with Kotlin-based DSL.
-- [Debezium Operator](https://github.com/debezium/debezium-operator): Debezium Operator adds Change-Data-Capture capabilities to your Kubernetes or Openshift cluster by  providing an easy way to run and manage  [Debezium Server](https://debezium.io/documentation/reference/stable/operations/debezium-server.html) instances.
diff --git a/bootstrapper-maven-plugin/pom.xml b/bootstrapper-maven-plugin/pom.xml
@@ -22,7 +22,7 @@
   <parent>
     <groupId>io.javaoperatorsdk</groupId>
     <artifactId>java-operator-sdk</artifactId>
-    <version>5.5.1-SNAPSHOT</version>
+    <version>999-SNAPSHOT</version>
   </parent>
 
   <artifactId>bootstrapper</artifactId>

diff --git a/caffeine-bounded-cache-support/pom.xml b/caffeine-bounded-cache-support/pom.xml
@@ -21,7 +21,7 @@
   <parent>
     <groupId>io.javaoperatorsdk</groupId>
     <artifactId>java-operator-sdk</artifactId>
-    <version>5.5.1-SNAPSHOT</version>
+    <version>999-SNAPSHOT</version>
   </parent>
 
   <artifactId>caffeine-bounded-cache-support</artifactId>

diff --git a/...javaoperatorsdk/operator/processing/event/source/cache/sample/AbstractTestReconciler.java b/...javaoperatorsdk/operator/processing/event/source/cache/sample/AbstractTestReconciler.java
@@ -96,15 +96,14 @@ public List<EventSource<?, P>> prepareEventSources(EventSourceContext<P> context
             1); // setting max size for testing purposes
 
     var es =
-        new InformerEventSource<>(
+        new InformerEventSource<ConfigMap, P>(
             InformerEventSourceConfiguration.from(ConfigMap.class, primaryClass())
                 .withItemStore(boundedItemStore)
                 .withSecondaryToPrimaryMapper(
                     Mappers.fromOwnerReferences(
                         context.getPrimaryResourceClass(),
                         this instanceof BoundedCacheClusterScopeTestReconciler))
-                .build(),
-            context);
+                .build());
 
     return List.of(es);
   }

diff --git a/...t/en/docs/documentation/dependent-resource-and-workflows/dependent-resources.md b/...t/en/docs/documentation/dependent-resource-and-workflows/dependent-resources.md
@@ -289,6 +289,41 @@ If you encounter this issue on an older Kubernetes version, consider changing yo
 that resource, or even upgrading your Kubernetes version. If you encounter it on a newer Kubernetes version, please log
 an issue with the JOSDK and with upstream Kubernetes.
 
+### Detecting dependent resource API version changes (experimental)
+
+When a dependent resource's CRD gains a new API version and the operator is upgraded to target it,
+comparing `actualResource.getApiVersion()` with the desired resource's API version is not a
+reliable way to detect resources that still need to be updated: the Kubernetes API server serves a
+resource using the requested, served API version regardless of which version it is actually stored
+as, so this comparison would always trivially match.
+
+`KubernetesDependentResource` therefore ignores `apiVersion` when matching. To still force a
+one-time update of dependent resources after such an upgrade, without triggering an update on every
+reconciliation, `KubernetesDependent` provides the opt-in, experimental
+`detectApiVersionChange` flag:
+
+```java
+@KubernetesDependent(detectApiVersionChange = true)
+public class MyDependentResource extends CRUDKubernetesDependentResource<MyResource, MyPrimary> {
+  // ...
+}
+```
+
+When enabled, JOSDK records the API version it applies in the `javaoperatorsdk.io/last-applied-api-version`
+annotation. On subsequent reconciliations, the resource is considered mismatched (and thus updated)
+if that recorded marker differs from the API version the operator currently uses - this also
+covers resources that predate this feature and therefore have no marker at all. Once the resource
+has been updated, the marker matches the current API version again, so no further update is
+requested until the API version changes again.
+
+This is disabled by default: existing behavior, including for resources created before this
+feature existed, is unaffected unless you opt in. It does not read or infer the actual storage
+version of the resource from the Kubernetes API, since that information is not reliably exposed;
+it only tracks what the operator itself last applied. It is also not a replacement for
+Kubernetes' [StorageVersionMigration](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/storage-version-migration/),
+which addresses migrating the stored representation of resources, a concern orthogonal to this
+feature.
+
 ## Telling JOSDK how to find which secondary resources are associated with a given primary resource
 
 [`KubernetesDependentResource`](https://github.com/java-operator-sdk/java-operator-sdk/blob/main/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/kubernetes/KubernetesDependentResource.java)

diff --git a/docs/content/en/docs/documentation/event-filters.md b/docs/content/en/docs/documentation/event-filters.md
@@ -84,7 +84,7 @@ public List<EventSource<?, MyCustomResource>> prepareEventSources(
           .withOnAddFilter(cm -> true)
           .build();
 
-  return List.of(new InformerEventSource<>(informerConfiguration, context));
+  return List.of(new InformerEventSource<>(informerConfiguration));
 }
 ```
 

diff --git a/docs/content/en/docs/documentation/eventing.md b/docs/content/en/docs/documentation/eventing.md
@@ -97,7 +97,7 @@ public class WebPageReconciler implements Reconciler<WebPage> {
                 InformerEventSourceConfiguration.from(Deployment.class, WebPage.class)
                         .withLabelSelector(SELECTOR)
                         .build();
-        return List.of(new InformerEventSource<>(configuration, context));
+        return List.of(new InformerEventSource<>(configuration));
     }
 
     // omitted code
@@ -346,4 +346,70 @@ for [primary resources](https://github.com/operator-framework/java-operator-sdk/
 
 See
 also [CaffeineBoundedItemStores](https://github.com/operator-framework/java-operator-sdk/blob/main/caffeine-bounded-cache-support/src/main/java/io/javaoperatorsdk/operator/processing/event/source/cache/CaffeineBoundedItemStores.java)
-for more details.
+for more details.
+
+### Sharing Informers Between Controllers (Informer Pool)
+
+{{% alert title="Experimental" color="warning" %}}
+Informer pooling is marked `@Experimental`: the feature itself is production ready, but its
+configuration API may still change in a non-backwards-compatible way.
+{{% /alert %}}
+
+By default JOSDK maintains an *informer pool* so that informers are **shared** across controllers
+and event sources. When several `InformerEventSource`s (whether belonging to different controllers,
+or dynamically registered at runtime) watch the same resource type with an equivalent configuration,
+they are all backed by a single underlying `SharedIndexInformer` instead of one informer each. This
+reduces memory usage and the number of watch connections opened against the API server — which
+matters in operators where many controllers watch the same secondary resource type (for example
+`ConfigMap` or `Secret`).
+
+Two event sources share an informer when their effective informer configuration matches on all of:
+
+- the `KubernetesClient` they watch through, compared by instance: normally every event source
+  resolves the operator's own client, but an event source watching another cluster brings its own
+  (see [multi-cluster](#informereventsource-multi-cluster-support)). Two separate client instances
+  never share an informer, not even when they connect to the same API server — they may differ in
+  credentials, impersonation or TLS material, and the informer keeps using the client it was created
+  from,
+- the resource type (or the group/version/kind for generic resources),
+- the watched namespace,
+- the label, field and shard selectors,
+- the configured [item store](#bounded-caches-for-informers).
+
+The `informerListLimit` is intentionally *not* part of this identity: if two otherwise-equivalent
+event sources request a different list limit, the existing informer is reused (a warning is logged
+and the first-configured limit is kept). Indexers are also not part of the identity: they are
+registered on the shared informer under a name qualified with the controller and event source that
+added them, so index names are private to an event source and cannot collide with those of another
+one. You keep looking indexes up by the name you registered, and the indexers of an event source are
+removed from the shared informer when it stops using it.
+
+The pool is reference-counted: the shared informer is created on first use and only stopped once the
+last event source using it is de-registered (or its controller stops). Dynamically registering an
+event source for a resource that is already backed by a running informer reuses that informer, and
+the initial state already in its cache is replayed to the newly added handler.
+
+#### Selecting the pooling strategy
+
+The strategy is provided by the
+[`InformerPool`](https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/pool/InformerPool.java)
+configured on the `ConfigurationService`. Two implementations are available:
+
+- [`DefaultInformerPool`](https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/pool/DefaultInformerPool.java)
+  (the default): shares informers as described above.
+- [`NonSharingInformerPool`](https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/pool/NonSharingInformerPool.java):
+  never shares informers, creating a dedicated informer for every event source. Use this to opt out
+  of pooling and restore the pre-pooling behavior.
+
+You can override the strategy through the `ConfigurationService`:
+
+```java
+Operator operator = new Operator(overrider ->
+    overrider.withInformerPool(new NonSharingInformerPool()));
+```
+
+A custom strategy has to extend
+[`AbstractInformerPool`](https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/pool/AbstractInformerPool.java),
+which is what `withInformerPool` accepts: it already creates the informers from an
+`InformerClassifier` and starts them, leaving the subclass to decide only whether and how they are
+shared. `InformerPool` itself is just the narrower contract that the event sources consume.
diff --git a/docs/content/en/docs/documentation/operations/configuration.md b/docs/content/en/docs/documentation/operations/configuration.md
@@ -84,7 +84,7 @@ public class MyReconciler implements Reconciler<TestCustomResource> {
     InformerEventSource<ConfigMap, TestCustomResource> configMapES =
         new InformerEventSource<>(InformerEventSourceConfiguration.from(ConfigMap.class, TestCustomResource.class)
             .withNamespacesInheritedFromController(context)
-            .build(), context);
+            .build());
 
     return EventSourceUtils.nameEventSources(configMapES);
   }

diff --git a/docs/content/en/docs/documentation/working-with-es-caches.md b/docs/content/en/docs/documentation/working-with-es-caches.md
@@ -85,8 +85,7 @@ public class WebPageReconciler implements Reconciler<WebPage> {
        configMapEventSource = new InformerEventSource<>(
                 InformerEventSourceConfiguration.from(ConfigMap.class, WebPage.class)
                         .withLabelSelector(SELECTOR)
-                        .build(),
-                context);
+                        .build());
 
         return List.of(configMapEventSource);
     }
@@ -200,7 +199,7 @@ With this index in place, you can retrieve the target resources very efficiently
 ```java
 
   InformerEventSource<Job,Cluster> clusterInformer =
-          new InformerEventSource(
+          new InformerEventSource<>(
         InformerEventSourceConfiguration.from(Cluster.class, Job.class)
             .withSecondaryToPrimaryMapper(
                 cluster ->
@@ -214,7 +213,7 @@ With this index in place, you can retrieve the target resources very efficiently
                         .stream()
                         .map(ResourceID::fromResource)
                         .collect(Collectors.toSet()))
-            .withNamespacesInheritedFromController().build(), context);
+            .withNamespacesInheritedFromController().build());
 ```
 
 ## Read-cache-after-write consistency and event filtering

diff --git a/micrometer-support/pom.xml b/micrometer-support/pom.xml
@@ -21,7 +21,7 @@
   <parent>
     <groupId>io.javaoperatorsdk</groupId>
     <artifactId>java-operator-sdk</artifactId>
-    <version>5.5.1-SNAPSHOT</version>
+    <version>999-SNAPSHOT</version>
   </parent>
 
   <artifactId>micrometer-support</artifactId>

diff --git a/migration/pom.xml b/migration/pom.xml
@@ -21,15 +21,15 @@
   <parent>
     <groupId>io.javaoperatorsdk</groupId>
     <artifactId>java-operator-sdk</artifactId>
-    <version>5.5.1-SNAPSHOT</version>
+    <version>999-SNAPSHOT</version>
   </parent>
 
   <artifactId>migration</artifactId>
   <name>Operator SDK - Migration Recipes</name>
   <description>OpenRewrite migration recipes for Java Operator SDK</description>
 
   <properties>
-    <openrewrite.version>8.87.5</openrewrite.version>
+    <openrewrite.version>8.88.0</openrewrite.version>
   </properties>
 
   <dependencies>

diff --git a/operator-framework-bom/pom.xml b/operator-framework-bom/pom.xml
@@ -21,7 +21,7 @@
 
   <groupId>io.javaoperatorsdk</groupId>
   <artifactId>operator-framework-bom</artifactId>
-  <version>5.5.1-SNAPSHOT</version>
+  <version>999-SNAPSHOT</version>
   <packaging>pom</packaging>
   <name>Operator SDK - Bill of Materials</name>
   <description>Java SDK for implementing Kubernetes operators</description>
@@ -54,7 +54,7 @@
     <maven-gpg-plugin.version>3.2.8</maven-gpg-plugin.version>
     <maven-source-plugin.version>3.4.0</maven-source-plugin.version>
     <maven-javadoc-plugin.version>3.12.0</maven-javadoc-plugin.version>
-    <spotless.version>3.8.0</spotless.version>
+    <spotless.version>3.9.0</spotless.version>
     <central-publishing-maven-plugin.version>0.11.0</central-publishing-maven-plugin.version>
   </properties>