EmadAlblueshi commented on issue #2093: URL: https://github.com/apache/pekko/issues/2093#issuecomment-3262076830
> > [@mdedetrich](https://github.com/mdedetrich) I was trying to do [#2152](https://github.com/apache/pekko/issues/2152), but that seems to need rework of many api too. I suggest you just work on the main, at least for me, I did not expect a 1.3.x branch. > > The thing is, if we want to do breaking changes in 2.0.x series (such as removing the methods that work with `Future` for Java users) the changes have to land in Pekko 1.x series because we have to then deprecate those methods. > > My work is currently based on the 1.2.x branch, but while the changes are mechanically simple it is in terms of volume a big PR also because documentation needs to be updated. There are also open questions about how far we want to go, i.e. do we want to follow the pekko-connectors/http pattern where even if the methods are the same for `scaladsl`/`javadsl` we still have copies of those methods in both API's (i.e. they are just alias's in the respective dsl packages) **OR** do we have these common API's just sit in `org.apache.pekko.actor` (one nesting above `org.apache.pekko.actor.scaladls`/`org.apache.pekko.actor/javadsl`), I wanted to ask this question in the PR. > > The tl;dr is, if we want Pekko 2.0.x to be clean and have a consistent API with the rest of pekko these changes need to land in 1.x at some point. > > On another note I also looked into the git log and I know why the API for `Actor` is the way it is, its **REALLY** old. It actually predates even Java's `CompletableFuture`/`CompletionStage` (which only came out in Java 1.8, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html and https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html) which explains why the API was designed the way it was, at that time `CompletableFuture`/`CompletionStage` didn't exist and so they expected Java users to just have to deal with the Scala `Future`. Java's `Future` was added in 1.5, but it was largely useless as it was missing the other necessary abstractions such as `CompletableFuture`/`CompletionStage`. > > I actually think for this reason, 2.0.x is an excellent opportunity to be bold and just remove all of this legacy design and cruft. Whether it be dropping Scala 2.12 (which seems likely), JVM 17 as minimum version which lets us simplify the sbt build a bit or just updating the API's (as we are talking about in this issue) so that both Java and Scala users are happy and also opens the doors for other types of dsl's (i.e. kotlin, clojure if someone is crazy enough????). This will also make our job easier in maintaining pekko, with the limited capacity we have as open source contributors. > > We just need to make sure that users are not hanging by waiting extended periods of time for a 2.0.0 release, hence why I think releasing semi-frequent milestones for 2.0.0 is the strategy to go here. This is one reason milestones are designed for, especially when we are doing binary breaking changes due to bump in major versions. Hi everyone, I'm not a contributor but a heavily Pekko java user and mixing between scala Future with java code base really confused me so splitting is the best way to go. Thank you. -- 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]
