Akka 2.5.0 Framework Features

Akka 2.5.0 Released!

we—the Akka committers—are proud to be able to announce the availability of Akka 2.5.0. Since the release of Akka 2.4.0 (already 18 months ago) we have incrementally added many new features to the 2.4.x release series, including Akka Streams and HTTP. That has worked well and we think you appreciate the API stability of all those patch versions. As always, there are some changes one cannot do in patch versions and therefore it is time for Akka 2.5. One of these changes is to promote some of the experimental modules to fully stable modules and incorporate some API improvements before declaring them stable.

Akka 2.5 is binary backwards compatible with 2.4 with the ordinary exceptions listed in a separate section below. Read the migration guide as the first step.

The key features of the 2.5.0 release are:

• The Java API for AbstractActor was promoted to fully stable API. While doing this we made some small, yet important, improvements to the API that will require some mechanical changes of your source code.Thanks to @ortigali for help.
• Faster and more flexible Akka Streams materializer, which matters for short lived streams, such as HTTP requests.
• Distributed Data was promoted to a fully stable module. Several improvements were also included, such as:
  • Support for delta-CRDTs in Distributed Data to reduce the amount of data that is replicated, thanks to help from @gosubpl.
  • Generic type for the key in Distributed Data ORMap, thanks to jgordijn
• Coordinated shutdown to facilitate ordered stopping of actors and services and perform registered tasks during the shutdown process. This greatly simplifies tasks involved in graceful leaving of Akka Cluster.
• Support remembering entities in Cluster Sharding with the Distributed Data (ddata) mode. ddata is now also the default mode for Cluster Sharding.
• New Java API for Testkit taking advantage of lambas, thanks to @Hawstein
• Fix performance regression for Scala 2.12, due to change in scheduling fairness of the JDK8 ForkJoinPool implementation
• We added @ApiMayChange and other annotations which can be used to mark experimental API inside stable modules, primarily for use in Akka HTTP.
• API improvements of Akka Typed, including Java API

Binary Compatibility

Akka 2.5.x is backwards binary compatible with previous 2.4.x versions (exceptions listed below). This means that the new JARs are a drop-in replacement for the old one (but not the other way around) as long as your build does not enable the inliner (Scala-only restriction). It should be noted that Scala 2.12.x is is not binary compatible with Scala 2.11.x, which means that Akka’s binary compatibility property only holds between versions that were built for a given Scala version—akka-actor_2.12-2.5.0.jar is compatible with akka-actor_2.12-2.4.17.jar but not with akka-actor_2.11-2.4.17.jar.

Binary compatibility is not maintained for the following:

• akka-testkit and akka-multi-node-testkit
• modules and API marked as “may change”, such as akka-typed and akka-contrib
• features, classes, methods that were deprecated in 2.4.0 or earlier and removed in 2.5.x

We had to make two additional exceptions:

• Custom Mailbox implementations. Scala 2.12 is using the standard JDK8 ForkJoinPool, which may cause performance regression for some Actor messaging scenarios. Therefore we have embedded the ForkJoinPool from Scala 2.11 in Akka. This breaks binary backwards compatibility for custom Mailboximplementations that were compiled with Akka 2.4.
• To make the Java APIs AbstractPersistentActor and AbstractPersistentActorWithAtLeastOnceDelivery to work with Scala 2.12 we could find no other solution but to break the binary compatibility of the Scala versions (which the Java ones were based on).

Being binary backwards compatible means that applications and libraries built on top of Akka 2.4.x continue to work with Akka 2.5.x without recompilation (subject to the conditions below), which implies that Akka HTTP as well as Play Framework 2.5 can be combined with Akka 2.5.