He-Pin opened a new pull request, #3677: URL: https://github.com/apache/pekko/pull/3677
### Motivation `ShardCoordinator.AbstractShardAllocationStrategy` is the Java API for custom shard allocation strategies, but its two abstract methods returned a Scala `Future` and took the allocated shards as `scala.collection.immutable.IndexedSeq`. Java implementers had to work with Scala types. Pekko 2.0.0 removes such leaks from the Java APIs elsewhere (for example pekko-persistence in #2092), and a scan of `cluster-sharding` and `cluster-sharding-typed` shows this was the last Java API in the sharding modules that still leaked a Scala `Future` or a Scala collection. ### Modification * `allocateShard` and `rebalance` now return `java.util.concurrent.CompletionStage` instead of `scala.concurrent.Future`. * The current shard allocations are passed as a `java.util.Map` of `java.lang.Iterable` shard ids instead of `scala.collection.immutable.IndexedSeq`. `java.lang.Iterable` follows the existing precedent for input parameters in `pekko.dispatch.CompletionStages` and the router constructors. `rebalanceInProgress` stays a `java.util.Set` because its contract is membership testing, and the `rebalance` result stays a `java.util.Set` because it is an output. * The `final` Scala-facing overrides convert between the Scala `ShardAllocationStrategy` API and the Java API using `scala.jdk.FutureConverters`/`CollectionConverters`. The Scala `ShardAllocationStrategy` trait itself is unchanged. * Added MiMa filters for the two changed abstract methods. Note that deprecating the `Future`-returning methods instead of replacing them is not possible here: the old and new `allocateShard`/`rebalance` overloads would differ only in their return type, which `javac` rejects for methods with the same erasure. This PR therefore follows the approach already taken for the pekko-persistence Java APIs in #2092 and documents the change in the migration guide. ### Result A custom shard allocation strategy can now be written in Java using Java types only. Scala implementations of `ShardAllocationStrategy` are unaffected. Existing Java subclasses have to switch their return types and shard-id collections; this is recorded in the 1.x to 2.x migration guide. ### Tests * `sbt "cluster-sharding/Test/testOnly org.apache.pekko.cluster.sharding.AbstractShardAllocationStrategySpec"`: 5 tests passed. The new spec drives a Java implementation (`RecordingShardAllocationStrategy`) through the Scala API and asserts the forwarded requester, shard id and allocation order, the `rebalanceInProgress` contents, the converted results, and that a failed `CompletionStage` surfaces as a failed `Future`. * `sbt "cluster-sharding/mimaReportBinaryIssues"`: passed with the new filters (Scala 2.13). * `sbt headerCreateAll`, `sbt "cluster-sharding/Test/javafmt"`: passed. * Native `scalafmt` on the changed Scala files, and `git diff --check`: passed. * `docs/paradox` for the migration guide and release notes change. * Not run locally: JDK 17 is not installed, so the Java formatter ran on JDK 21. The Scala 3 `mimaReportBinaryIssues` run and `sbt validatePullRequest` are delegated to CI. ### References Refs #2092 - continues removing Scala types from the Pekko Java APIs for 2.0.0 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
