I have been using Play Framework from the 1.2 version. Lately, I do most of the work with the 2.2/2.3 version. It supports both Scala and Java (you can literally mix the code files). Because I know Java much better compared to Scala (well I don’t know Scala at all), I do all my coding in Java.
Play Framework comes with Akka that supports actors for processing data. I have about 20 different actors that handle different scenarios. Actors talk with each other, so there’s a lot of different messages. Each message represents specific action.
One thing that really frustrates me is that Akka and Java don’t play nicely. I mean, everything works, but the authors of Akka don’t put a lot of effort into Java. I know, Scala is the great new language and once you know it, why the hell would you still use Java. Problem is that examples and tutorials are mostly written in Scala, coding actors in Scala is much easier and testing is just damn short and sweet.
Examples and Tutorials
When I face a problem and I want to see how others solved it or learn a new thing, I notice that most (about 95%) of Akka examples are in Scala. That means I need to somehow decode examples and convert to Java. This is not always possible. Sometimes certain implementations in Scala cannot be directly converted to Java and different approach has to be used.
Official docs have Scala nad Java version, but Scala version has much more content. There are many very useful blogs, like http://letitcrash.com/, but it’s all in Scala. Most of the books for Akka are also in Scala. Similar is with opensource projects on github.com.
For somebody coming from Java world, this can be frustrating.
Code
Java is not a language for writing short programs. So part of the fault is on Java, but again there could be better ways to write actors. For example, when I create an actor and want to process 3 different messages.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
public class ABCActor extends UntypedActor { private final LoggingAdapter log = Logging.getLogger(getContext().system(), this); @Override public void onReceive(Object message) throws Exception { if(message instanceof MessageA) { MessageA messageA = (MessageA) message; this.process(messageA.foo); } else if(message instanceof BMessage) { MessageB messageB = (MessageB) message; this.process(messageB.foo); } else if(message instanceof CMessage) { MessageC messageC = (MessageC) message; this.process(messageC.foo) } else { unhandled(message) } } public void process(String foo) { String reply = generateReply() sender().tell(reply, self()); } public String generateReply() { return "bar"; } public static class MessageA implements Serializable { public final String foo; public MessageA(String foo) { this.foo = foo; } } // similar for MessageB and MessageC } |
The code quickly become long (and I have very simple example), because it’s hard to filter messages and forward them to appropriate methods. While in Scala, things are much shorter.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
object ABCActor { case class MessageA(foo:String) case class MessageB(foo:String) case class MessageC(foo:String) } class ABCActor extends Actor with ActorLogging { import ABCActor._ def receive = { case MessageA(foo:String) => process(foo) case MessageB(foo:String) => process(foo) case MessageC(foo:String) => process(foo) case _ => unhandled() } def generateReply():String = "bar" def process(foo:String) = { val reply = generateReply() sender ! reply } } |
For me it’s important that you can fit the whole logic into screen. So I can see the whole code without scrolling it. It’s easier to put the logic into my brand. This is not possible with Java code (of course, I could split it and add extra files, but again the instead of scrolling I would be clicking).
Sending a message
|
1 2 3 4 5 |
// Java actor.tell(message, self()) // Scala actor ! message |
Scheduling a message
|
1 2 3 4 5 6 7 8 9 10 |
// Java system.scheduler().scheduleOnce(Duration.create(5, TimeUnit.SECONDS), actor, message, system.dispatcher(), null); // Scala import context.system._ scheduler.scheduleOnce(5 seconds, actor, message) |
There are tons of other examples. What I’m trying to say it that it’s much easier to write actor logic with Scala compared to Java. Much easier.
Testing
When writing unit tests, you should always test small parts of the code. That means that tests should also be small and short. Because Scala is very descriptive language, you can easily define a test. For example, let’s test our ABC actor and see if it replies.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
class ABCActorTest(_system: ActorSystem) extends TestKit(_system) with FlatSpecLike with MockitoSugar with ImplicitSender with Matchers with BeforeAndAfterAll { trait Fixture { var message = new MessageA("foo") } def this() = this(ActorSystem("ABCActorTest")) override def afterAll() { TestKit.shutdownActorSystem(system) } "Actor" should "send a message and get a reply" in new Fixture { val actor = TestActorRef(Props(new ABCActor())) actor ! message expectMsg("bar") } } |
Again, much shorted, much easier to understand and mostly less possibility for mistakes. We can also test specific method of actor.
|
1 2 3 4 5 6 |
"Actor" should "generate reply" in { val actorRef = TestActorRef(Props(new ABCActor())) val actor = actorRef.underlyingActor actor.generateReply() should be == ("bar") } |
Or we can mock certain actor methods. First we need to create a trait (similar to Java interfaces), so we can mock methods.
|
1 2 3 4 5 6 7 8 9 |
trait ABCActorBase { def generateReply():String } class ABCActor extends Actor with ActorLogging with ABCActorBase { // same code } |
Now when we create a test, we can inject different ABCActorBase.
|
1 2 3 4 5 6 7 8 9 10 11 |
trait ABCActorTestBase extends ABCActorBase { def generateReply():String = "mocked bar" } "Actor" should "mock method" in new Fixture { val actor = TestActorRef(Props(new ABCActor with ABCActorTestBase)) actor ! message expectMsg("mocked bar") } |
Scala has ScalaTest, which in my opinion is one of the best testing libraries. It offers very descriptive test results and error reporting. It supports multiple styles of testing, some of them look really awesome.
Conclusion
Even though I didn’t like Scala, I had to realize that it’s actually a great language. Not my favorite, but it’s OK. Since I’m developing an application that runs on JVM, it’s a shame not to use it if possible to solve certain tasks. It has many many more great features that I didn’t showcase, so feel free to check them out.
Final result it that I rewrote all my actors with Scala. They are much shorter and it’s easier to understand what they are doing. At the same time, great part of tests are now in Scala and I have a feeling that code is much stable and more error prone. It’s been few weeks since I have new actors in production and there were zero problems. Happy coding.
