GitHub user mdedetrich edited a comment on the discussion: Stream JavaDSL: start adding alternate methods that use Java function interfaces instead of the Pekko ones
So lets lay things out here, the only perceived benefit I can see to either changing the current API to use `java.lang.*` (or providing an alternate API that uses `java.lang.*`) is > The core reason is that when a Java user calls these functions using new > xFunction, they will see a strange japi.function.Function instead of the > familiar java.util.function.* that they are used to. I believe this is the > main issue, especially for beginners. As for @exception, I don't think it's a > significant problem since Java streams have never provided it anyway. Which is an incredibly weak reason to change the entire API (I am even ignoring the fact that using hacks like `@SneakyThrows` would be just as confusing to any Java beginner as would `org.apache.pekko.japi.function.*`, you are just trading inconvenience for another and `@SneakyThrows` is objectively worse here since its a hack). On the other hand, there is a very good technical and correct reason as to why `org.apache.pekko.japi.function.*` exists, its for lambda's that can legitimately throw an exception i.e. in a when supplying a lambda to `create` for creating a resource (such as a file) that lambda can throw an `IOException`. This is succinctly summarised as * Supplied lambda should never throw (i.e. creating a collection)? Use `java.util.*` * Supplied lambda could throw (i.e. allocating a resource such as a file)? Use `org.apache.pekko.japi.function.*` When reading an API and programming against the Pekko API in java, this to me is **_CRITICAL_** as it **_CLEARLY_** tells me for the lambda I am providing whether it makes sense for exceptions to be thrown or not, i.e. if with [this allocate parameter](https://github.com/apache/incubator-pekko/blob/cf704782010db237bd07f197e0942c9b02ffe23c/stream/src/main/scala/org/apache/pekko/stream/javadsl/Flow.scala#L4354-L4360), since its a `java.util.*` `@FunctionalInterface` I know that if I am trying to provide a lambda and its throwing an exception I am doing something **_very wrong_**. This is also why I **_don't_** wan't to encourage hacks like lombok's `@SneakyThrow` because its actually teaching the wrong pattern, if you are using the current Pekko DSL you should never have to use `@SneakyThrow` because if you are throwing an exception in one of the lambda's that use `java.util.*` you are almost certainly doing something wrong. The benefit we get (which is some small convenience for beginners) is greatly overshadowed by the inconvenience of either having to change everything for Pekko 2.0.x (we cannot do this before, it will break users) or creating an alternate `v2`/`juf` javadsl which to be honestly I would almost certainly `-1` as this is much more confusing than any other option or the status quo. If your goal is not to confuse beginners, then having multiple java api's will achieve the exact opposite effect. Another point to keep in mind is that minor beginner inconveniences will always get trumped by correctness/API design as this is one of the core tenets of Akka and hence Pekko. If you want something easy and quick then you probably shouldn't be looking at Akka/Pekko in the first place. That doesn't mean we should make it as Pekko approachable by beginners, but it doesn't mean that Pekko should cater to every single minor beginner inconvenience, this is a slippery slope that we should not go down. Given that there is one glaring hole, which is the this distinction of `@FunctionalInterface`'s in core java stdlib vs the ones in `org.apache.pekko.japi.function.*` doesn't appear to be generally documented (even though it is [clearly documented in code](https://github.com/apache/incubator-pekko/blob/b0fdac259bd57fdd481483f3fe9a7aec6e1ff38a/actor/src/main/scala/org/apache/pekko/japi/function/Function.scala#L18-L22)), due to this it makes sense to document this in the Pekko general docs somewhere. GitHub link: https://github.com/apache/incubator-pekko/discussions/960#discussioncomment-8140746 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
