Since our last major release in March we have been working full steam ahead on Reactive Streams and Akka Streams, which forms the foundation onto which we are porting Spray as our new Akka HTTP module. This effort is making steady progress as witnessed by frequent milestone releases—the feedback from the community is invaluable while these exciting new technologies are taking shape. Our goal is to reach feature parity between our HTTP module and Spray by the end of October, including an implementation of Akka Streams that we consider ready for public review. We will then release these new modules for the 2.3.x series—as usual with the “experimental” marker—asking for wider testing and feedback, so that they can then be a proper part of the Akka 2.4.0 release early next year.
The Akka Persistence module is meanwhile also developing nicely, owing to very high-quality feedback and discussions on the akka-user mailing list (e.g. here and here), thanks a lot! We simplified and unified Processor, EventsourcedProcessor, Channel and PersistentChannel into just one way of doing things: PersistentActor with the optional add-on AtLeastOnceDelivery. We are currently discussing how to improve and simplify our story on the read-side as well, PersistentView has proven too limiting to express common patterns like CQRS efficiently. Our goal is to finish these changes in time to offer the best possible Persistence module with 2.4.0—without the “experimental” marker.
Next to common codebase hygiene (removal of deprecated features, performance improvements, promotion of proven patterns from the Contrib area to Akka Cluster, documentation) there is one more long-standing topic that needs solving. Our ØMQ integration module has several flaws that we cannot easily overcome: it requires a native library that needs separate installation and that does not integrate nicely with our robustness model—instead of raising supervision events it shuts down the JVM in some cases. In addition the language bindings lag behind the official libzmq version and are not maintained any longer. A possible way forward would be to use the existing pure Java implementation, but that comes with limitations in terms of supported transport protocols and it also uses a license which is incompatible with our Akka licensing model. We have therefore decided to remove the akka-zeromq module from Akka 2.4, encouraging the community to take over its development. We will of course help out by answering related questions on the akka-dev mailing list.
Lastly, we dare a look beyond the next major release: after Akka 2.4.0 we will tackle the number one feature request, namely more type-safety for inter-Actor messaging. This will be a major research effort and likely also a disruptive API change. For this reason Akka 2.4 is planned to be a long-term support release, because even though we will try to find ways for compatibility or at least an easy migration path we cannot currently foresee the exact nature of all related changes. Another reason for nominating the next major update to be supported long-term is that Akka 2.4 will be the last release that remains compatible with Java 6 & 7. Future versions will require at least Java 8—the opportunities offered by the new language features are too compelling to be passed up and even Java 7 will reach its scheduled end of life in April 2015.
If you have any feedback to this plan, please do let us know.
