are we going to replace java.util.function params with pekko.util.function in Pekko 2.0.0?

[pjfanning]

I don't code much in Java. Pekko 2.0.0 dev already switched a lot of Java functions to pekko.util.function Functions.

We still have quite a lot of java.util.function Functions

https://github.com/search?q=repo%3Aapache%2Fpekko+java.util.function&type=code&p=1

It would be good to work out sooner rather than later, which, if any, of these usages are going to be rewritten for Pekko 2.0.0. If we do a 2.0.0-M0 release soon and then start doing even more breaking changes, this will mean that we end up with a 2.0.0-M1 which is still unstable - dragging out an ultimate 2.0.0 release.

So, I'm saying that we need to finalise all the changes now but it would be good to have some inkling as to what to expect later in the 2.0.0 dev cycle.

[pjfanning]

@He-Pin could you have a look at the remaining Java functions in Pekko main branch and work out if any of them need to change to Pekko functions?

[He-Pin]

I will take care of them tomorrow

[He-Pin]

@pjfanning I think I can continue this once #1986 got merged.

[mdedetrich]

So there are a couple of things flying around here. One seems to be a general cleanup that should be done as a result of Pekko 2.0.0 allowing breaking changes, this is absolutely fine.

The more critical change that has been silently been pushed into PR's without proper discussion is how we treat lambda functions that can throw exceptions, this is actually quite important because its part of API design and there is historical precedent to how it has worked in both Akka and in Pekko. There are PR's that have been merged which changes this behaviour and it to be blunt, it should have been discussed before changing the behaviour.

Both Akka and Pekko have historically and consistently designed their API in such a way that have you 2 types of functions. "pure" functions which cannot throw and "non pure" functions which can throw. Operators which do resource acquisition (such as mapWithResource) have used functions which allow throwing because you can hit cases where if you try to create a file (as part of a resource) it can throw an exception because the file failed to create.

On the other hand with functions like retry that have parameters like predicate, we have always used pure functions because throwing an exception in a predicate functions can have wildly different effects depending on which operator you use, and its also bad design because we have no idea of the intention when an exception is thrown. For example in a retry predicate function parameter, if an exception is thrown should it be true? Should it be false? Or should we just cancel the stream (if we are talking about pekko streams for example). There is no one answer, its entirely dependent on context and hence if a user of pekko is expecting exceptions to be thrown in a predicate function, they should explicitly map it to true or to false so they don't shoot themselves in the foot which is precisely what good API design facilitates.

tl;dr There is a reason, a very explicit one, why some function parameters in Akka/Pekko allowed exception throwing and some didn't. It was a deliberate decision, not an oversight and while we can change this we should have discussed it first.