2.2 Spotlight: Deprecation of Closure-Taking Props

From 2.2-M3 onwards you will probably notice several new deprecation warnings when trying out the Akka update on an existing project since all factories taking UntypedActorFactory, Creator<Actor> or Scala by-name arguments will produce warnings. We know that some of you will—at first sight—not like this, but please bear with us because we do this for a very good reason: we want to make your code safer!

The background for this change is that we have seen on many occasions code like the following:

… or in Scala:

It is an easy mistake to make and sometimes harmless, until you happen to call a method which is not thread-safe (as shown above) or you want to make this a remote deployment. In the first case you break actor encapsulating by implicitly passing “this” into the closure—deviously hidden by closure syntax—introducing race conditions and releasing the whole host of concurrency demons. In the second case the deployment will fail mysteriously because the enclosing class—often an Actor—is not serializable.

Akka’s mission is to make your life less frustrating, so we chose to replace those hidden failures which are hard to debug by early warnings from your dearest friend, the compiler.

So What Shall I Do?

The foremost use of the deprecated methods was to construct actors which take arguments. We have made this even simpler than before:

This syntax actually improves the LoC balance in the Java case considerably. For Scala it looks like this:

And What About Dependency Injection?

Another use-case for UntypedActorFactory was to let another framework perform the actual actor creation, e.g. OSGi/CDI/Spring/you-name-it. For those cases allow me to refer to our documentation for Java and Scala.

What the Future May Bring

For Scala there are two more use cases to consider: the inline construction of ad-hoc actors and the cake pattern—its close relative. The former is dangerous when performed inside another actor for the reasons outlined above, while the latter is usually safe. Therefore we plan on introducing macro-based alternatives which allow your favorite syntax to be used while not suffering from the pitfalls; stay tuned but please do not literally hold your breath, it may take several weeks until more pressing matters are resolved. Until then we are truly sorry for littering your builds with some false warnings.

Recent comments

Blog comments powered by Disqus

1 Notes

  1. hakkers posted this