My journey through JVM languages

Syntax

What made Groovy stand out was its syntax. On the one side, it eased some of Java language pains via optional semicolons, allowing more than one class per file or type inference with the def keyword.

On the other hand, it featured modern language features, such as traits, closures, string interpolation, optional chaining (?. operator) and many other features long before even Java 8 came out.

// Optional chaining:

def gear = car?.getGearBox()?.getGear()

// Instead of

Gear gear = null;
if (car != null) {
  if (car.getGearBox() != null) {
    gear = car.getGearBox().getGear();
  }
}

Moreover, Groovy is a superset of Java. It means, that a Java class is a perfectly valid Groovy class too! This makes its adoption way easier because you can just change the file extension to .groovy and transfer it to a more idiomatic code step by step as you need.

DSLs

Closures, maps and optional dots and parentheses allows us to create Domain Specific Languages, which can look like almost like written in plain English.

The excerpt below is from the official Groovy documentation and in my opinion it explains it quite well.

show = { println it }
square_root = { Math.sqrt(it) }

def please(action) {
  [the: { what ->
    [of: { n -> action(what(n)) }]
  }]
}

// equivalent to: please(show).the(square_root).of(100)
please show the square_root of 100
// ==> 10.0

Those DSLs are used for example in Gradle, Jenkins Pipelines, or Spock, so there is a chance, that you’ve been using Groovy without even realizing it.

Downsides

Groovy is a dynamic language, which means, that objects can be modified at runtime via appending methods or intercepting the calls. This is also the reason, why Groovy isn’t my go-to language anymore. It kind of suffers from the disadvantages of both approaches it tries to merge.

On one side, it still has to be compiled, because it is run on the JVM platform. Because of that, it can’t benefit from fast feedback loops like in other dynamic languages such as Ruby, which are interpreted.

On the other one, because it’s a dynamic language, the compilation step won’t give us that much guarantees about program correctness. Even though we can specify types of our variables and method arguments, we still can run into a runtime error at some point.

Types

Scala is statically typed, but it is a way more advanced mechanism than in Java. Types are not just classes. The hierarchy is larger, including types such as Any, AnyVal or Nothing. We can also construct types as functions, with defined arguments and returned values. It’s possible to define type aliases to make our definitions shorter and clearer.

Case Class is another help in using types in Scala. It’s basically a class with immutable fields and all batteries included. Because the fields are immutable, we don’t have to define getters and methods such as equals or hashCode are already there for us. Usually, those classes have just one line of code and they are very convenient to define simple structure types.

case class Circle(x: Double, y: Double, radius: Double)

In Scala, we also make use of monad types. What monads are is a topic for a completely separate blog post, but what’s important is that they help to make our code more meaningful. We can use Option if we want to represent a value that may or may not be defined or we can use Try or Either if we want to represent a successful result of some operation or an error if it failed.

val studentOpt: Option[Student] = students.findById(123)

studentOpt.foreach(student => println(student.name))

The gamechanger here is the fact, that the Scala Standard Library uses those types throughout the library, so we don’t have to worry about null checks or runtime exceptions within the Scala code unless we use them explicitly or integrate with Java libraries using them.

Pattern matching and for comprehension

Scala has two particular features, that help to work with monad types and case classes – pattern matching and for comprehension.

Pattern matching seems like a simple switch statement, but it is much more than that. We can define more advanced conditions, especially check types, and use the filtered values without unsafe casting.

val result: Either[ErrorCode, SuccessValue] = ???

result match {
    case Right(successValue) =>
      handleSuccess(successValue)   // no cast needed, successValue is already of SuccessValue type 

    case Left(errorCode) if errorCode.value > 300 =>    // additional conditions are possible too
      handleLowPriorityError(errorCode)

    case Left(errorCode) =>
      handleHighPriortyCode(errorCode)  
}

For comprehension is the syntactic sugar, which helps us to avoid nested chains of .flatMap or .foreach calls when we work with monad types. It’s the easiest to explain it with an example:

val employeeNames = for {
  company <- companies
  employee <- company.employees
  if employee.currentlyEmployed
} yield {
  employee.name
}

// is an equivalent of this:

val employeeNames = companies
  .flatMap(company =>
    company.employees
      .withFilter(employee => employee.currentlyEmployed)
      .map(employee => employee.name)
  )

Downsides

The obvious Scala’s downside is a steep learning curve. Due to its complexity, it takes some time to be productive in it and write a proper idiomatic code. In my case, I’ve made the biggest progress during my first code review in a team, which was already using Scala and I think it’s the best way to learn it – from other teammates already proficient in it 🙂

Another issue is that it is similar to C in one specific manner – both of those languages are powerful tools, but because of that, it’s very easy to get carried away and write complicated, unreadable code. It’s part of the reason why Scala’s learning curve is so steep.

The last one is harder integration with Java libraries. Not being a Java superset could be annoying, but in fact, IDE support makes it negligible. A more serious problem is that Java libraries do not use Scala monad types and they may use mutable objects. Therefore we can receive a null object when we do not expect it, running into a NullPointerException. This is probably one of the reasons why Scala collections were written from scratch and they even don’t implement the java.util. interfaces.

Nullable types and Java integration

Kotlin’s approach to tackle the NullPointerException problem is to introduce nullable types. When a type is declared with a ? sign at the end (e.g. String?), it means that it can be null. The best part is that it’s the compiler that checks if we try to use such an object without checking if it wasn’t null and returns the error if we did.

val nullableString: String? = null  // OK
val notNullableString: String = null // compilation error!

All values coming from Java code are nullable by default, which makes this mechanism work even when we integrate our Kotlin code with some Java library.

Just like in Scala, we can work with immutable values and collections, but without committing that much to the functional programming paradigm:

• Data classes can have mutable fields, where Scala’s case classes can not.
• There are no monad types in the standard library. We can use libraries, like arrow-kt, but we have to wrap the values ourselves.
• No pattern matching, no for comprehension, less complicated (but thus – less expressive) type system.

Those functionalities make Kotlin a perfect candidate for being a “better Java”. We can see results today, where Android and Spring already have Kotlin integration.

Domain Specific Languages

Similarly to Groovy, Kotlin has closures, which lets us build DSL in Kotlin too. The advantage is that in Kotlin such DSLs are typed. Gradle has Kotlin DSL and my IDE can finally check my code for errors and give me some hints about available properties.

Coroutines

Closures are also used in another distinct Kotlin feature – Coroutines. In essence, they are simply lightweight threads, which can handle asynchronous operations while preserving the readability.

The below example comes from Kotlin documentation. If we tried to run 100k of thread at once, we would cause an OutOfMemoryException.

import kotlinx.coroutines.*

fun main() = runBlocking {
    repeat(100_000) { // launch a lot of coroutines
        launch {
            delay(5000L)
            print(".")
        }
    }
}

Within the coroutine context, the code can be organized with suspend functions, which are functions that are run within the coroutine and its execution can be paused and resumed later, e.g. when the data from the HTTP request arrives.

import kotlinx.coroutines.delay
import kotlinx.coroutines.runBlocking

fun doSomeWork() = runBlocking {
    val result = makeHttpCall()
    println(result)
}

// Simulate making the call and return the result
suspend fun makeHttpCall(): String {
    // The delay here is also a suspend function, which does block the thread.
    // The execution of the makeHttpCall function is paused until
    // the time of delay passes and then it's resumed
    delay(1000)
    return "Some result"
}

Coroutines are pretty heavily used in the web framework called Ktor.

Downsides

Regarding downsides, I think that the biggest one is Kotlin’s young age. I could especially experience it with Kotlin Gradle DSL, where on one hand it’s great that finally the DSL is typed, but on the other hand, it was still easier to copy and paste some Groovy code from the internet than to figure out how to translate it. However, I’m sure, that this situation will be better and better over time.

The other matter is that Kotlin is some sort of “jack of all trades, master of none”, at least in my opinion. It integrates well with Java libraries, but still it has some overhead comparing to just going with Java. It allows a functional approach, but not to such extent as Scala. This does not have to be a bad thing, but it’s something you should be aware of.