Deprecate the org.apache.pekko.japi.Function in 1.2.0

[He-Pin]

There are :

org.apache.pekko.japi.Function

and

org.apache.pekko.japi.function.Function

we should deprecate all of it in org.apache.pekko.japi.Function and remove it in the next release.

[mdedetrich]

we should deprecate all of it in org.apache.pekko.japi.Function and remove it in the next release.

We are not allowed to remove deprecated methods until Pekko 2.x.x due to semver. Deprecating methods is fine but can only happen in next minor (not patch) release.

[He-Pin]

@mdedetrich Yes, we should mark it deprecated and add overload methods on the user sides.

[pjfanning]

We're already discussing (in mailing list) the idea of making the next non-patch release a 2.0.0 so we may end up having to deprecate in 2.0.0 and remove in 3.0.0.
That is, there might not be a 1.2.0 release. We may have missed the boat by not deprecating this sooner.
Still, we could deprecate now but it could be a long time before we get to remove the code.

[pjfanning]

I don't think this is a task for a first time contributor. Some changes could be contentious and first time contributors often don't want to get into big debates about changes.

[raboof]

This is indeed an unfortunate puzzle. We have public API's that accept org.apache.pekko.japi.Function as a parameter. I don't think we should mark org.apache.pekko.japi.Function as deprecated when we still have non-deprecated APIs that require it. Replacing those with variants that take org.apache.pekko.japi.function.Function is not easy, since having both variants is ambiguous when called with a Java lambda. I don't see an elegant way to make this migration. Perhaps we should just make this breaking change 'in one go' in 2.0.0 without a deprecation cycle - after all, these classes aren't really meant to be used 'on their own', but only in the context of being used as parameters.

[He-Pin]

since having both variants is ambiguous when called with a Java lambda.

I totally missed that!!!