Was this deprecated in the 1.x series of Pekko?

@mdedetrich I will deprecate it in the 1.4.x with another pr

Was this deprecated in the 1.x series of Pekko?

That is my point. The code is not yet deprecated and I think there is a good chance that Java users have been using it.
I don't see why we can't leave the method alone and maybe just add a javadoc mention of more Java friendly methods that we also support.

It causes us zero overhead to maintain the existing method.

That is my point. The code is not yet deprecated and I think there is a good chance that Java users have been using it. I don't see why we can't leave the method alone and maybe just add a javadoc mention of more Java friendly methods that we also support.

It causes us zero overhead to maintain the existing method.

While I agree that the PR to deprecate the method should land first in Pekko 1.x series, leaving around the method in 2.0.x series is likely going to be pointless/useless because the only reason it exists is due to deficiencies in the current 1.x Pekko API where it leaks the usage of Scala futures to javaapi, a lot of which is actually fixed in 2.0.x series.

Actual Java users don't like and don't want to use Scala's future, and I would be shocked if anyone is actually using these methods aside from the usecase I described ergo some javadsl returning/accepting a Scala future when it should instead be using CompletionStage.

@mdedetrich Me too, as Java developer using Scala's future is a bit wired

Even if we deprecate Java DSL Source.future, we don't yet have a release with the deprecation notice so I think this PR is getting well ahead of itself. Let's deprecate, get a release with the deprecation and see if there is any feedback before removing the method.

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 Futures. 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.

In this case AFAICS FutureConverters.asJava 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.

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.

Yes, it would be nice if we had a 1.5.x during the release cycle of 2.0.0

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 Futures. 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 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.