mdedetrich commented on PR #2554: URL: https://github.com/apache/pekko/pull/2554#issuecomment-3634168179
> As the javadoc says, this function is "Here for Java interoperability, the normal use from Java should be [[Source.completionStage]]". Ideally a 'healthy' codebase should likely not need this method, and use `CompletionStage` consistently. Indeed we've been making nice progress towards making that possible in Pekko itself for 2.0.0. > > > > There might be places where we still only produce `Future`, and more importantly, people might be using 3rd-party or in-house components that provide `Future`s. Actual Java users indeed don't like and don't want to use Scala's future, but IMHO that means we _should_ have good interoperability helpers, rather than making it even harder for those Java devs that inevitably find themselves having to deal with a Future due to other constraints. The big remaining issue here is ActorSystem but that is something that I will now look into given that 2.0.0-M1 is out. > In this case AFAICS [FutureConverters.asJava](https://www.scala-lang.org/api/2.13.18/scala/jdk/javaapi/FutureConverters$.html#asJava[T](f:scala.concurrent.Future[T]):java.util.concurrent.CompletionStage[T]) provides a simple drop-in replacement making this helper superfluous. For this reason I'd support deprecating in 1.x and removing already in 2.0.0: even if we discover cases where it is still hard to avoid a `Future`, we can direct people to `FutureConverters.asJava` and `Source.completionStage`. Yes this is exactly the point, there already are future/completion stage converters that are part of Scala's stdlib for Scala 2.13+, including ones that are designs to be called within Java (converting Future to CompletionStage). Actually our codebase uses them frequently throughout, and we use those Future to CompletionStage converters in our Java tests (often because of these aforementioned uses of Future in Java APIs that we are gradually fixing) > > I'm not sure I think we should wait for a 1.x release with the deprecation before merging this PR, but I agree there's a risk we'd forget the deprecation, so I agree it would be good to get the deprecation in 1.x merged before we merge the removal for 2.x. I will approve PR once the deprecation lands in 1.4.x Pekko. -- 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]
