At LinkedIn, we’ve started to use the Play Framework, which supports not only Java, but also Scala. Many teams have opted to write their apps in Scala, so I’ve spent a fair amount of time helping team members learn the language.

Scala logo

Most LinkedIn engineers are proficient in Java, so their early Scala code looks like a literal translation from Java to Scala: lots of for-loops, mutable variables, mutable collection classes, null values, and so on. While this code works, it’s not taking advantage of one of Scala’s biggest strengths: strong support for functional programming.

In this post, I want to share 10 recipes for how to translate a few of the most common imperative Java patterns into functional Scala code.

Why functional programming?

Why would you want to make your code “functional”? This question has been asked and answered many times, so rather than recreating the answers myself, I’ll point you to a couple good starting points:

  1. Why Functional Programming Matters by John Hughes
  2. Functional Programs Rarely Rot by Michael O. Church

It’s worth mentioning that Scala is not a pure functional language, but it is still worth trying to make as much of your code as possible out of (a) small functions that (b) use only immutable state and (c) are side effect free. If you do that, I believe your code will generally be easier to read, reason about, and test.

Now, on to the cookbook!

Recipe 1: building a list

Let’s start easy: we want to loop over a List of data, process each item in some way, and store the results in a new List. Here is the standard way to do this in Java:

List<String> processList(List<String> list) {
  List<String> out = new ArrayList<String>();
  
  for (String item: list) {
    out.add(doSomeProcessing(item));
  }  
  
  return out;
}

It’s possible to translate this verbatim into Scala by using a mutable.List and a for-loop, but there is no need to use mutable data here. In fact, there is very rarely a reason to use mutable variables in Scala; think of it as a code smell.

Instead, we can use the map method, which creates a new List by taking a function as a parameter and calling that function once for each item in the original List (see: map and flatMap in Scala for more info):

def processList(list: List[String]): List[String] = {
  list.map { item =>
    doSomeProcessing(item)
  }
}

Recipe 2: aggregating a list

Let’s make things a little more interesting: we again have a List of data to process, but now we need to calculate some stats on each item in the list and add them all up. Here is the normal Java approach:

Integer calculateTotalStats(List<StatsObject> list) {
  int total = 0;
  
  for (StatsObject item: list) {
    total += calculateStats(item);
  }  
  
  return total;
}

Can this be done without a mutable variable? Yup. All you need to do is use the foldLeft method (read more about it here). This method has two parameter lists (Scala’s version of currying): the first takes an initial value and the second takes a function. foldLeft will iterate over the contents of your List and call the passed in function with two parameters: the accumulated value so far (which will be set to initial value on the first iteration) and the current item in the List.

Here is the exact same calculateTotalStats written as a pure Scala function with only immutable variables:

def calculateTotalStats(list: List[StatsObject]): Int = {
  list.foldLeft(0) { (totalSoFar, item) =>
    totalSoFar + calculateStats(item)
  }
}

Recipe 3: aggregating multiple items

OK, perhaps you can do some simple aggregation with only immutable variables, but what if you need to calculate multiple items from the List? And what if the calculations were conditional? Here is a typical Java solution:

CalculatedStats calculateStats(List<StatsObject> list) {
  CalculatedStats stats = new CalculatedStats();
  
  for (StatsObject item: list) {
    if (item.id.equals("foo")) {
      stats.statsA.add(calcA(item));
    } else if (item.id.equals("bar")) {
      stats.statsB.add(calcB(item));
    } else if (item.id.equals("baz")) {
      stats.statsC.add(calcC(item));
    }
  }  
  
  return stats;
}
 
class CalculatedStats {
  // In idiomatic Java, these fields would usually 
  // be private and have getters and setters
  List<Integer> statsA = new ArrayList<Integer>();
  List<Integer> statsB = new ArrayList<Integer>();  
  List<Integer> statsC = new ArrayList<Integer>();
}

Can this be done in an immutable way? Absolutely. We can use foldLeft again, combined with pattern matching and a case class (case classes give you lots of nice freebies) to create an elegant, safe, and easy to read solution:

def calculateStats(list: List[StatsObject]): CalculatedStats = {
  list.foldLeft(CalculatedStats()) { (acc, item) =>
    item match {
      case "foo" => acc.copy(statsA = acc.statsA + calcA(item))
      case "bar" => acc.copy(statsB = acc.statsB + calcB(item))
      case "baz" => acc.copy(statsC = acc.statsC + calcC(item))
      case _ => acc
    }
  }
}
 
case class CalculatedStats(
  statsA: List[Int] = List(), 
  statsB: List[Int] = List(), 
  statsC: List[Int] = List()
)

Imagine you have a List of values and you need to transform each value and find the first one that matches some condition. The catch is that transforming the data is expensive, so you don’t want to transform any more values than you have to. Here is the Java way of doing this:

SomeOtherObject findFirstMatch(List<SomeObject> list) {
  for (SomeObject obj: list) {
    SomeOtherObject transformed = doExpensiveTransformation(obj);
    if (transformed.someCondition()) {
      return transformed;
    }
  }
  
  return null;
}

The normal Scala pattern for doing this would be to use the map method to transform the elements of the list and then call the find method to find the first one that matches the condition. However, the map method would transform all the elements, which would be wasteful if one of the earlier ones is a match.

Fortunately, Scala supports Views, which are collections that lazily evaluate their contents. That is, none of the values or transformations you apply to a View actually take place until you try to access one of the values within the View. Therefore, we can convert our List to a View, call map on it with the transformation, and then call find. Only as the find method accesses each item of the View will the transformation actually occur, so this is exactly the kind of lazy search we want:

 
def findFirstMatch(list: List[SomeObject]): Option[SomeOtherObject] = {
  val transformed = list.view.map(doExpensiveTransformation)
  transformed.find(_.someCondition())
}

Note that we return an Option[SomeOtherObject] instead of null. Take a look at Recipe 7 for more info.

Recipe 5: lazy values

What do you do if you want a value to be initialized only when it is first accessed? For example, what if you have a singleton that is expensive to instantiate, so you only want to do it if someone actually uses it? One way to do this in Java is to use volatile and synchronized:

class FooSingleton {
 
  private FooSingleton() {
    // Some expensive initialization code
  }
  
  private static volatile FooSingleton instance;
 
  public static Singleton getInstance() {
    if (instance == null) {
      synchronized (Singleton.class) {
        if (instance == null) {
         instance == new Singleton();
        }          
      }
    }
    return instance;
  }
}

Scala has support for the lazy keyword, which will initialize the variable only when it is first accessed. Under the hood, it does something similar to synchronized and volatile, but the code written by the developer is easier to read:

private class FooSingleton {
  // Some expensive initialization code
}
 
object FooSingleton {
  private lazy val instance = new FooSingleton
  
  def getInstance = instance
}

Recipe 6: lazy parameters

If you’ve ever worked with a logging library like log4j, you’ve probably seen Java code like this:

if (logger.isDebugEnabled()) {
  logger.debug("Diagnostics: " + getExpensiveDiagnosticsInfo());
}

The logging statement is wrapped with an isDebugEnabled check to ensure that we don’t calculate the expensive diagnostics info if the debug logging is actually disabled.

In Scala, you can define lazy function parameters that are only evaluated when accessed. For example, the logger debug method could be defined as follows in Scala (note the => in the type signature of the message parameter):

class Logger {
  def debug(message: => String) {
    if (isDebugEnabled) {
      doDebug(message) // message is only evaluated if we get here
    }
  } 
}

This means the logging statements in my code no longer need to be wrapped in if-checks even if the data being logged is costly to calculate, since it’ll only be calculated if that logging level is actually enabled:

logger.debug("Diagnostics: " + getExpensiveDiagnosticsInfo)

Recipe 7: null checks

A common pattern in Java is to check that a variable is not null before using it:

String buildSentence(String name) {
  String sentence = "Hello";
  
  if (name != null) {
    sentence += " " + name;
  }
  
  return sentence;
}

If you’re working purely in Scala, and have a variable that might not have a value, you should not set it to null. In fact, think of nulls in Scala as a code smell.

The better way to handle this situation is to specify the type of the object as an Option. Option has two subclasses: Some, which contains a value, and None, which does not. This forces the programmer to explicitly acknowledge that the value could be None, instead of sometimes forgetting to check and stumbling on a NullPointerException.

You could use the isDefined or isEmpty methods with an Option class, but pattern matching is usually cleaner:

def buildSentence(nameOpt: Option[String]): String = {
  val hello = "Hello"
  nameOpt match {
    case Some(name) => hello + " " + name
    case _ => hello
  }
}

The Option class also supports methods like map, flatMap, and filter, so you can safely transform the value that may or may not be inside of an Option. Finally, there is a getOrElse method which returns the value inside the Option if the Option is a Some and returns the specified fallback value if the Option is a None:

def buildSentence(nameOpt: Option[String]): String = {
  val hello = "Hello"
  val sentenceOpt = nameOpt.map(name => hello + " " + name)
  sentenceOpt.getOrElse(hello)
}

Of course, you rarely live in a nice, walled off, pure-Scala garden - especially when working with Java libraries - so sometimes you’ll get a variable passed to you that isn’t an Option but could still be null. Fortunately, it’s easy to wrap it in an Option and re-use the code above:

def buildSentence(maybeName: String): String = {
  val nameOpt = Option(maybeName)
  val hello = "Hello"
  val sentenceOpt = nameOpt.map(name => hello + " " + name)
  sentenceOpt.getOrElse(hello)
}

Recipe 8: multiple null checks

What if you have to walk an object tree and check for null or empty at each stage? In Java, this can get pretty messy:

String getDegree(Profile profile) {
  if (profile != null) {
    List<Education> educations = profile.getEducations();
    if (educations != null && !educations.isEmpty()) {
      Education education = educations.get(0);
      List<Degree> degrees = education.getDegrees();
      if (degrees != null && !degrees.isEmpty()) {
        Degree degree = degrees.get(0);
        if (degree.getName() != null && !degree.isEmpty()) {
          return "Degree: " + degree.getName();
        }
      }
    }
  }
  
  return null;
}

With Scala, you can take advantage of a sequence comprehension and Option to accomplish the exact same checks with far less nesting:

def getDegree(maybeProfile: Profile): Option[String] = {
  val degreeOpt = for {
    profile <- Option(maybeProfile)
    educations <- Option(profile.getEducations)
    education <- educations.headOption
    degrees <- Option(education.getDegrees)
    degree <- degrees.headOption
    name <- Option(degree) if !name.isEmpty
  } yield {
    "Degree: " + degree
  }
}

Recipe 9: instanceof and casting

In Java, you sometimes need to figure out what kind of class you’re dealing with. This involves some instanceof checks and casting:

String toPrettyString(Transport transport) {
  if (transport instanceof Car) {
    Car car = (Car) transport;
    return car.make + " " + car.model;
  } else if (transport instanceof Airplane) {
    Airplane airplane = (Airplane) transport;
    return airplane.name + ", speed: " + airplane.speed;
  } else if (transport instanceof Train) {
    Train train = (Train) transport;
    return "A train with " + train.cars + " cars";
  } else {
    return "Unrecgonized type of transport";
  }
}
 
interface Transport {}
 
class Car extends Transport {
  String make;
  String model;
}
 
class Airplane extends Transport {
  String name;
  int speed;
}
 
class Train extends Transport {
  int cars;
}

We can use pattern matching and case classes in Scala to make this code more readable, even though it does the same instanceof checks and casting under the hood:

def toPrettyString(transport: Transport): String = {
  transport match {
    case Car(make, model) => make + " " + model
    case Airplane(name, speed) => name + ", speed: " + speed
    case Train(cars) => "A train with " + cars + " cars"
    case _ => "Unrecgonized type of transport"
  }
}
 
trait Transport
case class Car(make: String, model: String) extends Transport
case class Airplane(name: String, speed: Int) extends Transport
case class Train(cars: Int) extends Transport

Recipe 10: regular expressions

Let’s say we want to match a String and extract some data from it using one of a few regular expressions. Here is the Java code for it:

Pattern nameTag = Pattern.compile("Hello, my name is (.+)");
Pattern list = Pattern.compile("Last: (.+). First: (.+).");
 
String extractName(String str) {
  Matcher nameTagMatcher = nameTag.matcher(str);
  if (nameTagMatcher.find()) {
    return nameTagMatcher.group(1);
  }
  
  Matcher listMatcher = list.matcher(str);
  if (listMatcher.find()) {
    return listMatcher.group(2) + " " + listMatcher.group(1);
  }
  
  return null;
}

In Scala, we can take advantage of extractors, which are automatically created for regular expressions, and pattern matching using partial functions, to create a much more readable solution:

val NameTag = "Hello, my name is (.+)".r
val List = "Last: (.+). First: (.+).".r
 
def extractName(str: String): Option[String] = {
  Option(str).collectFirst {
    case NameTag(name) => name
    case List(lname, fname) => fname + " " + lname
  }
}

Got some recipes of your own?

I hope this post has been helpful. It’s worth noting that the recipes above are only one of many ways to translate the code; for example, many of the List examples could have also been done with recursion.

If you’ve got suggestions on how to make the examples above even better or have some handy recipes of your own, leave a comment!