DRAFT: Split ActorSystem creation into javadsl and scaladsl

[mdedetrich]

This PR is an exploratory PR to see whether its worth it to resolve https://github.com/apache/pekko/issues/2093 as a non source breaking change when going from Pekko 1.3.0 to 2.0.0. If we decide that a source breaking change in Pekko 2.0.0 is acceptable then this PR is not necessary

Explanation of methods

• terminate: This one is deprecated and is no longer meant to be used. I was forced to do this since the current terminate method returns a Future making it impossible to create the appropriate return type for javadsl/scaladsl (javadsl should return CompletionStage where as scaladsl should return Future). Instead we have terminateAsync which returns Future for scaladsl and CompletionStage for javadsl
• close: A method with a configurable timeout that blocks on termination. Also implements the Java AutoCloseable interface, meaning it will execute automatically if an ActorSystem is created in a try/catch clause.
  • Adding AutoCloseable may be too much as it is a behaviour change, might be better to do this in Pekko 2.0.0
• closeAsync: Essentially the same as old terminate/new terminateAsync but it doesn't return a Future/CompletionStagebut rather justUnit/void. This is necessary in cases where you have the root pekko.actor.ActorSystemand still need to terminate the system in a non blocking manner, typically when usingcontext` i.e.

  case TerminateMsg(Left(false)) =>
    context.system.closeAsync()
    stop()
  

[pjfanning]

In the PR description, would it be possible to provide a succinct description of what the close, terminate, closeAsync and terminateAsync methods do?

[mdedetrich]

In the PR description, would it be possible to provide a succinct description of what the close, terminate, closeAsync and terminateAsync methods do?

Will do, right now this is more of an exploratory PR to see if we should go ahead with it at all (see https://lists.apache.org/thread/0lzlhh4ll08t1o1gfh7w08635c5t6bw3)

[mdedetrich]

In the PR description, would it be possible to provide a succinct description of what the close, terminate, closeAsync and terminateAsync methods do?

Done

[mdedetrich]

I think the shape is great, but what about the AutoCloseable?

Its implemented

[He-Pin]

@mkurz FYI too

[pjfanning]

Whatever we come up, we should make sure that the typed ActorSystem is then set up to have an equivalent API. Same split into Java DSL / Scala DSL. Same method names and behaviours for the close* and terminate* methods. Autocloseable interface. That can be done separately but we shouldn't release 1.3.0 or 2.0.0-M1 with changes in classic ActorSystem and no changes in typed ActorSystem.

[mdedetrich]

That can be done separately but we shouldn't release 1.3.0 or 2.0.0-M1 with changes in classic ActorSystem and no changes in typed ActorSystem.

I also plan to do typed ActorSystem but that will come later

Also can we please not do copilot AI review until PR is done, its just going to create a whole lot of noise at a time when its not useful

[He-Pin]

@mdedetrich Is there an ETA, maybe we can do that in one PR. to make sure it consistentcy

[mdedetrich]

So I have some bad/annoying news, it appears that its not possible to do this in Pekko 1.3.x because of how the inheritance between the various Actor classes is done and the fact that Java interfaces cannot extend abstract classes. I can get the scaladsl to work by having the actor.scaladsl.ActorSystem/actor.javadsl.ActorSystembe a trait, converting actor.ActorSystem to a trait but the same doesn't work because we need a constructor for actor.ActorSystem (some parts of Akka can instantiate a actor.ActorSystem manually by reflection, this also breaks MiMa).

I tried making ActorSystemImpl a trait to get around this, but we then get a cyclic inheritance issue. Ill have another try at it, but it looks like that in order to do this it would have to be with breaking changes in Pekko 2.0.0 where some slight adjustments to the inheritance need to be made

[mdedetrich]

@mdedetrich Is there an ETA, maybe we can do that in one PR. to make sure it consistentcy

There is no ETA as of yet, this is a proof of concept to see if its even possible (and given the previous comment it doesn't look like it is)

[He-Pin]

then what about we delay this in 2.0.0, and let 1.3.x released soon?

[pjfanning]

Thanks @mdedetrich, can we retarget at main branch and continue there?

[mdedetrich]

Thanks @mdedetrich, can we retarget at main branch and continue there?

Give me a couple of days to figure out, if that doesn't work then I will make a new PR against 2.0.0 as it will be slightly different and will have a better/cleaner API.

Also if anyone has any other alternatives feel free to checkout the branch and play with it locally, may have forgetten something

[pjfanning]

One possible 1.x solution would to leave the existing ActorSystem class as is except maybe to deprecate its methods. You can add new Scala and Java DSL classes that delegate to the existing class but that implement their own APIs and Autocloseable. The new classes would not subclass the existing class. I would still prefer to see this in main branch first and then something that implements something equivalent can be backported. In the end of day, there isn't a big demand for this. I'd prefer to proceed with 1.3.0 without this and I expect we'll have a 1.4.0 at some stage.

[mdedetrich]

One possible 1.x solution would to leave the existing ActorSystem class as is except maybe to deprecate its methods. You can add new Scala and Java DSL classes that delegate to the existing class but that implement their own APIs and Autocloseable.

The issue is that even doing this doesn't work at least without a huge amount of code churn. Direct inheritance doesn't work (as described) and delegation also won't work for other reasons, a lot of Actor code expects to work with pekko.actor.ActorSystem (or one of its subclasses) and so delegation won't work here.

Regarding AutoCloseable, I made a PR at https://github.com/apache/pekko/pull/2486. The AutoCloseable interface is not reliant on scala/java dsl in any way so that can be implemented irrespective of https://github.com/apache/pekko/issues/2093