Activator will be EOL-ed on May 24, 2017.

Activator will be EOL-ed on May 24, 2017.

We’re making it easier and simpler for developers to get started with Lightbend technologies.


This unfortunately means that future releases of Play, Akka and Scala will no longer include Activator support, and Lightbend’s Activator server will be decommissioned by the end of 2017. Instead of supporting Activator to create and set up development projects, we'll be supporting standard Giter8 templates for sbt users and Maven archetypes for Maven users.

So going forward,
To create new Lightbend projects
Instead of using the Activator command, make sure you have sbt 0.13.13 (or higher), and use the “sbt new” command, providing the name of the template.

For example, “$ sbt new akka/hello-akka.g8”. You can find a list of templates here.

Also, as a convenience, the Lightbend Project Starter allows you to quickly create a variety of example projects that you just unzip and run.

To create new templates

If you want to create new templates, you can now do that in Giter8.

To migrate templates from Activator to Giter8
If you created Activator templates in the past, please consider migrating them to Giter8 with this simple process.

Thank you!

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.

Introduction to Reactive Programming

Introduction

In this post,  I'm going to discuss about Reactive Programming theoretical concepts and will develop some real-time  applications in my coming posts.

What is Reactive?

Reactive means "Non-blocking". Reactive Programming means writing code in a Non-Blocking way.

Non-Blocking means that make a call and continue doing with other work, don't wait for a response from that call. Do something once you get notification from that call.

Reactive programming is a paradigm to develop Non-Blocking Asynchronous Even-Based applications very easily.

Why we need Reactive Programming?

We need to use Reactive programming paradigm to get the following benefits:

• We can develop highly Scalable and highly available applications very easily.
• We can develop modular programming very easily so that we can get loosely coupling.
• We can develop very responsive applications very easily.
• We can develop Fault-Tolerant applications very easily.
• We can develop Low Latency applications very easily.
• We can develop Highly efficient and Better Performance applications very easily.
• We can develop Asynchronous Non-Blocking code very easily.
• We can develop Event-Driven or Message-Driven applications very easily.
• We can develop more Flexible applications very easily.
• We can develop more Robust applicatons very easily.

Reactive Programming Examples

In this section, we will discuss a list of clients who is using Reactive Programming, a list languages/Frameworks, which supports Reactive Programming.

• RX Java - It supports Reactive Programming in JVM
• Scala/Akka/Play Framework
• React JS
• Scalatra Framework
• Micro Soft .NET C#

Clients who are using Reactive Programming Paradigm:

• Netflix
• Facebook
• LinkedIn
• Microsoft
• Google
• HSBC
• Citigroup
• UK DWP

and Many more clients.

The following are upcoming languages/Frameworks which supports Reactive Programming Paradigm:

• Java 9
• Spring 5 Framework

Java is going to add a reactive module in it's next version 9.

Spring Framework is going release a reactive module: spring-reactive soon in it's new version 5.

The principles of Reactive Programming

We can define Reactive Programming Paradigm by using the following four principles:

• Responsive
• Resilient (Fault-tolerant)
• Message-Driven (Event-Driven)
• Elastic (Scalable)

What is Functional Reactive Programming (FRP)?

Functional Reactive Programming (FRP) is a programming paradigm for Reactive Programming (RP) on Functional Programming (FP). That means a programming paradigm combining both FP and RP.

What is Object-Oriented Reactive Programming (OORP)?

Objecte-Oriented Reactive Programming (OORP) is a programming paradigm for Reactive Programming (RP) on Object-Oriented Programming (OOP). That means a combination of OOP and RP.

We will discuss some practical examples on Reactive Programming in my coming posts.

Please send me your valuable comments or suggestions or feedback about my posts.

Thank you for reading my tutorials.

Akka Framework 2.4.1 New Features

Introduction

In my previous post, I have already discussed about Akka Framework 2.4.0 New Features. However, Lightbend team recently has release Akka 2.4.1 for Scala 2.11.7 and Java SE 8.

Akka 2.4.1 Release on: April 1st 2016.

Akka 2.4.1 release have the following new features or improvements:

1. Shard region now kills shards more consistently on HandOff
2. An empty shard region now shuts down correctly on graceful shutdown
3. Using the distributed data mode the sharding coordinator updates correctly after leader downing
4. Possibility to provide a custom supervision strategy for the BackOffSupervisor
5. Problem with split brain on cluster startup under some circumstances solved
6. A new Supervisor that supports exponential restart back-off semantics for actors reg Will try to deliver a Tutorial on Akka Framework soon through my new blog:
   
   
   https://rams4scala.wordpress.com ardless of their lifecycle model (the BackoffSupervisor overloads the meaning of self-termination)
7. The complete list of closed tickets can be found in the 2.4.1 github issues milestone.

Will try to deliver a Tutorial on Akka Framework soon through my new blog:

https://rams4scala.wordpress.com

Thank you.

Akka Framework 2.4.0 New Features

Introduction

In this post, we will list out Akka Framework 2.4.0 Release new features and improvements.

This is release for Scala 2.11 and Java SE 8. It also supports Scala 2.12 latest version.

NOTE:- Will try to deliver a Tutorial on Akka Framework soon through my new blog:


https://rams4scala.wordpress.com

Akka 2.4.0 release have the following new features or improvements:

1. dropped support for Java 6 & 7 as announced in the last roadmap update, and now require Java 8 or later
2. dropped support for Scala 2.10, kept 2.11 and added 2.12 (which is at milestone 2 currently); this is in keeping with our policy to support the Scala version that is “current” when the first milestone comes out plus any later version that is published during this series’ lifetime
3. Akka Persistence was promoted to a fully supported module (not experimental)
4. added experimental stream based API for the Query Side of Akka Persistence (implementations must be provided by query plugins corresponding to the journal plugins for the various data stores)
5. improved support for Akka Persistence event migrations by Serializer with String Manifest and Event Adapters and prepared comprehensive documentation of strategies for schema evolution of persistent events
6. made Akka Persistence failure handling more robust and support rejections of events
7. Akka Persistence can now use multiple different Journals within one ActorSystem (thanks to Andrei Pozolotin, who also split out ClusterMetrics into their own module)
8. introduced Persistent FSM, thanks to an awesome contribution from leonidb
9. simplified setting up Akka Clusters behind NAT (including inside Docker containers)
10. added the experimental Akka Typed module previously codenamed Project Gålbma, a new way of formulating Actor interactions with full type-system support
11. promoted the ClusterSingleton, ClusterClient, DistributedPubSub and ClusterSharding patterns to fully a supported Cluster Tools module, including various API and configuration improvements
12. ClusterSharding also learnt a few new tricks (graceful shutdown, asynchronous shard allocation, reviving entries after migration thanks to Dominic Black, and more flexible use of roles [thanks to Richard Marscher)
13. ClusterClient now uses custom failure detection to avoid quarantining in case of transient network failures
14. added experimental Akka Distributed Data which was previously known as Akka Data Replication (see akka-data-replication migration guide), the Distributed Data module is useful for sharing eventually consistent data (CRDTs) between nodes in an Akka Cluster
15. new experimental feature that makes it possible to promote new members to WeaklyUp during network partitions, thanks to Hector Veiga for contributing
16. the SLF4J logging adapter can now apply the log filtering rules prior to sending to the EventStream, see the migration guide
17. make it possible to use any version of Protobuf for serialization of application messages, the internal dependency to Protobuf has been replaced by embedding a shaded (renamed package) version, if you use Protobuf in your application you need to add the dependency to your build, see migration guide
18. but the biggest feature is probably that Akka 2.4 will be binary backwards compatible with Akka 2.3, see the detailed description below.

Thank you. 

I will try to deliver some posts with useful examples in my coming posts.