chore: Deprecate Source#future in javadsl

[He-Pin]

This method should be deprecated and then removed in 2.0.0 release
#2554

[pjfanning]

I'm not sure why we can't keep some of the old methods. People have probably been using them and they cause no harm. 100%, let's add extra Java DSL methods that better support Pure Java alternatives but Scala Future is not an awful API for Java users.

[He-Pin]

We should hide some scala types when the target user is Java developers.
new Source(scaladsl.Source.future(..)) can be used anyway.

[pjfanning]

-1 from me - this is not a a permanent block - but I'm in the middle of a release and would prefer not to have this merged during a release

I would also like to maybe bring this to a vote of the PMC because I don't really see why we need to deprecate this - we already have javadoc mentioned Source.completionStage.

I don't see why this method offends anyone. My view is that let users use this if they like it.

[pjfanning]

can we go down the route of deprecating now (main and 1.5.x) and coming back in a few months and looking at removing from main?

[mdedetrich]

I'm not sure why we can't keep some of the old methods. People have probably been using them and they cause no harm. 100%, let's add extra Java DSL methods that better support Pure Java alternatives but Scala Future is not an awful API for Java users.

Its not awful but its entirely redundant given CompletionStage exists. Its useful to provide context here, the only reason why Future is exposed to Java users in the first place (ignoring oversights) is that Akka predates JVM 1.8 which is when CompletionStage was added to JVM stdlib. There are also parts of the Future API which are difficult/complicated for Java users to use, i.e. it exposes Scala's Try which is designed to be used with pattern matching, something that Java has no analogue for. I know this because I had to use Future in Java code every now and then, and even saying its API usage is not idiomatic in Java would be charitable.

So yes in a world where Java doesn't have CompletionStage there is merit, but that is no longer the case here and hasn't been in a while and the only reason these methods sat there for so long is because Akka sat at 2.x for so long and they couldn't break the API. We are breaking the API now, this is no longer an issue.

[He-Pin]

As akka is moving to Java first now, I think we should keep java don't clean and Java native, so leaking the Future in a Java dsl is a leak of implementation detail

[mdedetrich]

-1 from me - this is not a a permanent block - but I'm in the middle of a release and would prefer not to have this merged during a release

I would also like to maybe bring this to a vote of the PMC because I don't really see why we need to deprecate this - we already have javadoc mentioned Source.completionStage.

I don't see why this method offends anyone. My view is that let users use this if they like it.

can we go down the route of deprecating now (main and 1.5.x) and coming back in a few months and looking at removing from main?

This doesn't make sense, if anything we should deprecate the methods as soon as possible, not later. Also lets put things into perspective here, we have been deprecating these Future related methods in Java dsl since Pekko 1.2? (maybe 1.3) and unless I missed something there hasn't been a single user complaint.

So to me, as far as I can tell, there hasn't been a single actual Java user (of which there are many of, if not more than Scala) that has complained about these methods being deprecated, likely because almost no one in Java is actively trying to use Future.

And if for some reason Java users need to use Scala's Future in their API, in Scala 2.13 and later there is a method in Scala's stdlib which will convert a Scala Future to a Java CompletionStage, see scala.jdk.javaapi.FutureConverters

[pjfanning]

The existing method causes us zero pain. Users might be using it. We are in no position to tell anyone what long existing methods that they can and can't use. Users expect to be able to upgrade lib versions without any hassle. You can claim that a major release allows us to remove whatever you like but what you are really doing is convincing a large proportion of our users to not upgrade. These users choose to either:

• stick to an outdated release that doesn't get fixes
• or pay a company to provide them LTS on the old release
• or plan to move to a new set of libs that don't go around changing their APIs

[mdedetrich]

The existing method causes us zero pain.

I'm sorry this is a terrible argument in general, I mean why did we go ahead and remove all of the Pekko 1.x deprecated methods in Pekko 2.x?

I could just as easily argue that there was no reason for removing these those deprecated as it causes us zero pain and yet we did it.

Users might be using it.

All evidence points to the contrary. We have been deprecating these methods for a while now and there hasn't been a single complaint.

In fact I don't think it's ridiculous to claim that deprecating these Future methods and removing it in Pekko 2.x is causing us zero pain as well (that also includes our users)

We are in no position to tell anyone what long existing methods that they can and can't use.

Yes we most certainly are if it's a breaking release of Pekko, that's the whole point of a breaking point release.

Users expect to be able to upgrade lib versions without any hassle. You can claim that a major release allows us to remove whatever you like but what you are really doing is convincing a large proportion of our users to not upgrade. These users choose to either:

• stick to an outdated release that doesn't get fixes

• or pay a company to provide them LTS on the old release

• or plan to move to a new set of libs that don't go around changing their APIs

And again, we have been deprecating these methods for a while and no has complained and that's not surprising because it would be shocking if any Java users willingly used Scala Future.

There is an obvious misalignment/tension here and rejecting PRs like this is in my view too far. Can we discuss this on the mailing list and make an executive decision on it? The whole premise of deprecating these Future methods in the java dsl is it should be done as soon as possible so we can actually get feedback from Java users on releases, and this PR should have been in Pekko 1.4.0 for exactly this reason.

I am on the verge of blocking future Pekko 1.x releases over this, as this argument comes up again and again and it's the same arguments that cause us to go around in circles. We are already in the middle of doing this transition of cleaning up the Java dsl wrt Future and that only works if we holistically deprecate the related methods as soon as we can in the Pekko 1.x series

[pjfanning]

I don't have a problem generally with deprecating the method (this PR). I object to the related PR which removes the method before we have even a release with the deprecation.

release is out

[pjfanning]

I don't have a problem generally with deprecating the method (this PR). I object to the related PR which removes the method before we have even a release with the deprecation.

I am somewhat unhappy with PRs going straight to 1.x branches like this PR does. The norm is for PRs to go to main branch first and to then be backported.

[mdedetrich]

I don't have a problem generally with deprecating the method (this PR). I object to the related PR which removes the method before we have even a release with the deprecation.

Sure that's fine, in which case we should still discuss this properly and if the result is that is a deprecation PR needs to land in Pekko 1.x first then that is totally fine (and this is my position as well) This would also make it clear for @He-Pin as he is largely driving this.

EDIT: Also I am aware the release is out, my point is that ideally these deprecations should have landed in Pekko 1.4.0 as we need to give sufficient time/warning to end users before a Pekko 2.0.0 full release.

[mdedetrich]

I don't have a problem generally with deprecating the method (this PR). I object to the related PR which removes the method before we have even a release with the deprecation.

I am somewhat unhappy with PRs going straight to 1.x branches like this PR does. The norm is for PRs to go to main branch first and to then be backported.

I am aware, but to me this is evidently causing confusion/chaos so it makes sense to revisit this position. These deprecations only make sense if they are put to end users as soon as we can.

[He-Pin]

@pjfanning @mdedetrich We can rewrite the commit message with the reference to the pr to main

[pjfanning]

lgtm - @He-Pin after we merge this, could we cherry pick it to main while we discuss the timing about removing the method?