mdedetrich commented on PR #2156: URL: https://github.com/apache/pekko/pull/2156#issuecomment-3261769621
> 1. There's already a declaration here. Yes the PR exposes Java 1.8 Stream in a `Sink` so it should be fine, but the same pitfalls with the other stream converter methods also needs to be documented. I'll check in more detail when I have access to laptop. > 2. Java 25 is coming soon, and managed blocking is a thing of the past. Irrelevant, not everyone is running on JVM 25 and people run Pekko in other environments. > 3. The API needs to be kept simple and reasonable. If you think this is wrong, why does smallrye-mutiny have an `asStream` method? and `reactor.core.publisher.Flux#toStream()` I don't know how mutiny works. All I am saying is that a core design of Pekko Streams specifically is that it's built on the assumption that everything is purely asynchronous which is why as I explained before that materialized values/stream elements can never block and since we can't enforce that users will always 100% of the time use `VirtualThread` we have to deal with this. Unfortunately this was the issue with Java not having a core async/concurrency primitive when it was releases (in contrast to Kotkin which has coroutines and Go which has channels) and it takes 30 years to release an officially supported one (although you can argue that `CompletionStage` is that primitive) That actually opens up another set of questions, we may be able to simplify the current stream converters API by wrapping the results in a `CompletionStage`. That way the API is easier to work with (the current design of it being in a `Sink` is a pita to work with) and we may be able to avoid these deadlock issues. I am not against have another API which is designed for `VirtualThread` and is even simpler, it would just have to assert that it's being run on a `VirtualThread` and crash with a helpful error message if it's not -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
