Void NullPointerException with Scala Option

0 comments

If you tell me that in your programming career, you have never been inflicted at-least once with a NullPointerException, you were simply the best programmer out there.

During the early days of my career, I can remember times and times again, I ended up hitting NullPointerException's until I really made it a point to adjust my design to completely get rid of them. It was just me trying to get rid of them, but the NullPointers weren't prepared to leave me.

Alright, let's look at it in steps:

I have a method called myMethod that returns me a String value after doing some lengthy calculation:

def myMethod: String = {
  ...
  val retVal = doLengthyCalculation()
  ...
  retVal
}

Now imagine that the myMethod is called by another method which would do something with the String value it gets.

def anotherMethod: String = {
  ...
  myMethod.equals("someValue") // Potential source for NullPointerException
  ...
}

From the above code snippet, it is obvious that myMethod could return a null value and when the caller tries to invoke a method on a null value... I don't want to say what happens next! You know it! So how does Scala deals with this? Scala, since being a functional programming language, has a concept called Monad (borrowed from Category Theory). I won't go through what a monad it, but for a one-liner, here is what it is:

A monad is sort of a container of a certain type. You can unpack the container, do some operation on the type, pack the container back and keep doing this operation over and over again.

I know you might be scolding me as that definition did not make much sense. Yes I know that! For a detailed look into what Monads are have a look at the following article

Now coming back to our code snippet, the method myMethod said to the external world that it is going to return a String but what happened eventually in our scenario is that it returned null which is a pure violation of the contract.

Scala solves this elegantly by introducing something called an Option. Now when I apply this Option as a return type to myMethod, it becomes:

def myMethod: Option[String] = {
  ...
  val retVal = doLengthyCalculation()
  ...
  retVal
}

The myMethod contract now says that, I may or may not return a String, so whoever calls me, be prepared to handle this. It is a lot better to know this beforehand than to wait until Runtime to be confronted with a NullPointerException. The caller of myMethod would then handle this as described in the code snippet below:

def anotherMethod: String = {
  ...
  myMethod match {
    case Some(strValue) => // Hurray no more NullPointerException's
    case None => // You know what to do
  }
  ...
}

To-gether with the Scala's pattern matching syntax, the Option types are an elegant way of dealing and avoiding NullPointerExceptions.

Test private methods (a.k.a code smell) using Scala Test

0 comments

I will not debate upon whether writing private methods are a code smell or not but rather just show how a private method can be unit tested using the Scala Test framework Here is our test class where we would write a unit test which tests a private method called myPrivateMethod in a class called MyClass

class MyPrivateTester extends FlatSpec with Matchers with PrivateMethodTester {
  "PrivateMethodTester" should "be able to test a private method in MyClass" in {
    val privateMethod = PrivateMethod[String]('myPrivateMethod)
    val myClass = new MyClass
    val invokationResult: String = myClass.invokePrivate(privateMethod("param1", "param2"))
  }
} 
A few points to note about the test code is that we need to extend the PrivateMethodTester trait. The signature for a private method invocation looks like:
val privateMethod = PrivateMethod[ReturyType_Of_The_Private_Method_That_Is_Tested]('Private_Method_Name')
The type PrivateMethod is a type member of the PrivateMethodTester trait. We give it the return type of what the private method is returning and the private method name. Once we have the PrivateMethod defined, we can use it to actually call our private method on the object or class type that we want ot test. In our example above, we wanted to test the private method named myPrivateMethod available in the MyClass object. Assuming that myPrivateMethod takes two String arguments, the call to test this method would look like:
val invokationResult: String = myClass.invokePrivate(privateMethod("param1", "param2"))
The invokationResult is the result of calling the private method.

Scala Dynamic Proxy

0 comments

One of the coolest features since Scala 2.10.3 are the Scala dynamic types. Let's look at what they are! A dynamic type is a type with which we can dynamically add fields / methods to an existing type. This is better explained with some examples Assume that we have a scala class as defined below:

  class MyClass {
    def myMethod(str: String) = println(str)
  }
  ...
  ...
  val myClass1 = new MyClass().myMethod("printme") // Fine!
  val myClass2 = new MyClass().notMyMethod("beep") // Yes you know it!
For situations like above, scala dynamic types come to the rescue. They are a mechanism by which we can intercept calls to a non-existing field or a method in a class Let's now modify our MyClass and try to get rind of the compile error when invoking the notMyMethod!
  import scala.language.dynamics
 
  object MyClass extends Dynamic {
 
    private var myMap = mutable.Map[String, Any]()
   
    def myMethod(str: String) = println(str)
   
    def selectDynamic(args: String) = println("selectDynamic " + args)
   
    def applyDynamic(methodName: String)(args: Any*) = println("applyDynamic " + args)
   
    def applyDynamicNamed(methodName: String)(args: (String, Any)*) = println("applyDynamicNamed " + args)
   
    def updateDynamic(name: String)(value: Any) = { myMap(name) = value } // mutating sounds scary!!!
  }
Let's go through each one of those xxxDynamic methods that we added in the example above:
  • applyDynamic - Dynamically creates a method and the arguments as though that method was part of the declared type
  • applyDynamicNamed - Similar to applyDynamic, with the benefit that we can use a named argument
  • selectDynamic - Dynamically invoke a field as though that field was part of the given type (think of a getter)
  • updateDynamic - Dynamically update a field as though that field was part of the given type - (think of a setter)
I wonder why there is the updateDynamic, I would rather refrain from using it for obvious reasons that we all know (avoid mutability damn it!) Try the following examples and figure out which xxxDynamic method is invoked in each case
MyClass.showMyAge("my age is", 34) - ???
MyClass.FUCK!! - ???
MyClass.printUser(userName = "Joe", age = "34")  - ???
MyClass
If you have got all the above examples correctly, you have understood the basics of Scala's dynamic types!

Converting collections to and fro in Scala / Java

0 comments

Say that you have to use a Java library in your Scala application and this Java library has a couple of API's that require you to pass a Java collection type. Let's see how we can cope with it by looking at the following examples: Suppose I have a java ArrayList that contains some Integers and I want to map these List of Integers by incrementing 1 to each of the elements in the ArrayList as below:

scala> val javaList = new java.util.ArrayList[Integer]()
javaList: java.util.ArrayList[Integer] = []

scala> javaList.add(1)
res0: Boolean = true

scala> javaList.add(2)
res1: Boolean = true

scala> javaList map { i => i + 1 }
error: value map is not a member of java.util.ArrayList[Integer]
    javaList map { i => i + 1 }

As you can see that the message from the Scala compiler is very clear that there is no map function available to the ArrayList and we need someway to tell the compiler to treat that as a Scala collection. Java Conversions to the rescue:

import scala.collection.JavaConversions._

scala> javaList map { i => i + 1 }
res3: scala.collection.mutable.Buffer[Int] = ArrayBuffer(2, 3)

What happened above is that we imported the JavaConversions package available in the Scala library to tell the compiler that it should implicitly convert the java.util.ArrayList to a closest possible collection type in Scala which in our case happened to be an ArrayBuffer. If you take a look at the Scala API documentation on JavaConversions there is an implicit method called asScalaBuffer which was used in our example implicitly to convert the java.util.ArrayList to a Scala collection type.

The JavaConversions package contains a couple of implicit methods to convert between a Java collection to a Scala collection and vice-versa. There is yet another package in the scala.collections called JavaConverters. What is the difference? Both the JavaConversions and JavaConverters do more or less the same thing, i.e., convert to and fro between a Java / Scala collection. You might be wondering over which one you should prefer. Let's find that out with the help of some more examples:

scala> val scalaMap = Map("A" -> 1)
scalaMap: scala.collection.immutable.Map[String,Int] = Map(A -> 1)

scala> scalaMap.contains(1)
error: type mismatch;
    found   : Int(1)
    required: String
    scalaMap.contains(1)
    ^

What we did just now is instantiated an immutable Map from the Scala library that maps a set of String to Int. Remember, the syntax for Scala Map looks like below:

trait Map[A, +B] extends Iterable[(A, B)] with GenMap[A, B]
    with MapLike[A, B, Map[A, B]]

The contains method looks like below:

def contains(key: A): Boolean

What we did with our scalaMap variable above is that we created a Map that took a String as key and Int as value, so when we called the contains method and passed it an Int, it failed. The contains method implementation in Scala internally calls the get method to check if the key is contained in the collection. Now let's see what happens if we import the JavaConversions:

scala> import scala.collection.JavaConversions._
import scala.collection.JavaConversions._

scala> scalaMap.contains(1)
res1: Boolean = false

It kind of worked and returned false. Practically speaking the variable scalaMap does not contain 1, so returning false would look like the right thing to do. What was compromised here is the type safety that we had before importing the JavaConversions. Soon after importing the JavaConversions package, the Scala compiler gives an implicit call to the MapWrapper class wherein the MapWrapper class implements the containsKey method from the Java library and the implementation looks like this in the Scala library's MapWrapper class

    override def containsKey(key: AnyRef): Boolean = try {
    // Note: Subclass of collection.Map with specific key type may redirect generic
    // contains to specific contains, which will throw a ClassCastException if the
    // wrong type is passed. This is why we need a type cast to A inside a try/catch.
    underlying.contains(key.asInstanceOf[A])
    } catch {
        case ex: ClassCastException => false
    }

As it can be see, the containsKey takes an Object / AnyRef rather than the specific type which in our case is a String. With JavaConversions, we went down from a stricter type to a more looser type. Let's see now how we could retain the stricter type by being a bit more explicit, using the JavaConverters!

scala> val scalaMap = Map("A" -> 1)
scalaMap: scala.collection.immutable.Map[String,Int] = Map(A -> 1)

scala> import scala.collection.JavaConverters._
import scala.collection.JavaConverters._

scala> scalaMap.contains(1)
error: type mismatch;
    found   : Int(1)
    required: String
    scalaMap.contains(1)
    ^

Did you see the difference? There is now no implicit conversion between the Java and Scala collection types. If you want the scalaMap variable to be a java.util.Map, you now have to be explicit as below:

scala> scalaMap.asJava
res0: java.util.Map[String,Int] = {A=1}

So from my point of view, it is better to be explicit which would imply to use the JavaConverters instead of JavaConversions.

Implicit Classes Scala 2.10 Extension Methods

0 comments

Having worked with C# in the last couple of months, writing extension methods was one of the cool features that I appreciated a lot! Extension methods are just a way to add new mwthods to the existing set of types. For example, the double type has several methods as part of the Scala API. If you now want to add a method that finds the reciprocal of a double, the first thing that comes naturally would be to write a helper utility function that does this for us. With extension methods, you can make that helper utility function look like as though it is part of the API itself. So let's see how to write the reciprocal extension method on a double!

  implicit class DoubleExtensions(val d: double) extends AnyVal {
    def reciprocal = 1 / d
  }
A few points to note on the code snippet
  • The implicit keyword makes the primary constructor of the class available for implicit conversions
  • The implicit classes may be defined inside a trait, class or an object - good practice
  • Only one non implicit argument is allowed in the primary constructor (the val d: double in the case above)
  • There may not be any method, member or object in scope with the same name as the implicit class
I find this pretty neat and very simple rules surrounding implicit classes!

Pattern Matching Scala Collections

0 comments

One of the astonishing features that Scala has is the pattern matching mechanism. Think of it like a Java Switch statement on Steroids. Pattern matching is such a powerful concept in Scala. Once you start using them, you'll find it inevitable to not using them. Let's look at some examples

You want to pattern match a List based on the number of elements in the List :

def patternMatch = {
  val matchResult = List(1,2,3,4,5) match {
    case Nil => "Matches an empty List"
    case head :: Nil => "Matches a List that has exactly one element"
    case head :: tail => "Matches a List that hast at-least one element"
  }
}

What is happening in the above code snippet is that, the myList is run through the case blocks and it is obvious that myList has more then one element init and hence the last case statement is matched and the following statement is returned as the matchResult.

If you are wondering what the case syntax is all about, here is a quick description of what it is:

case pattern => expression

The case is a Scala keyword, the pattern is what you specify for the supplied value to be checked against and the expression is what you want to be returned if the pattern matches. Simple or?