How we ported our application from Java to Scala

Øyvind Raddum Berg

@olvindberg

Penger.no

Penger.no - Early Timeline

Java project, Situation early 2012...

• code base growing quickly
• unhappy with technology

codebase size and complexity growing quickly

initial 18 months of project (jan 2011-june 2012)

Unhappy with technology

• limited/leaky abstractions
• want to understand whats going on
• runtime failures
• debugging

Situation

• scala expertise within team
• insurance app originally scala
• backoffice app already rewritten
• mortgage app very important for us i come in december 2012, hired partly for scala first task was rewriting backoffice app of course there was also...this other project other team had all the fun unbearable lunch that leads me to the main reason for the rewrite...

Envy

Wanted to optimize for:

• peace of mind/trust in code
• similar technology between projects
• developer happiness

Porting strategy:

Refactor Java codebase

• limit/contain mutability
• avoid multiple returns
• short, static functions
• composition over inheritance
• value classes

Optional semantics

• compile-time guarantees and easy porting, not elegance
• today: would have used java.util.Optional<T>

public class MyOption<T> implements Iterable<T> {
    private final T value;

    public static <G> MyOption<G> option(final G value) {
        return new MyOption<G>(value);
    }

    ...
}

Mechanically convert

Source graph

• Scala calling Java 👍

• Java calling Scala 👎

• start converting controllers, then continue downstack

• keep all inter-module APIs «Java-friendly» while you can

IntelliJ <3

Example

public class Foo<T> {
    private final T param;

    public Foo(T param) {
        this.param = param;
    }
}

automatically converted (doesnt compile, in this case):

    class Foo {
      def this(param: T) {
        this()
        this.param = param
      }

      private final val param: T = null
    }

what you probably want:

case class Foo[T](param: T)

looks like this

Porting collections

converting between hierarchies

explicitly (preferred)

import scala.collection.JavaConverters._

val javaMap: util.Map[String, Int] =
    immutable.Map("foo" -> 2, "bar" -> 42).asJava

implicitly

import scala.collection.JavaConversions._

val javaMap: util.Map[String, Int] =
    immutable.Map("foo" -> 2, "bar" -> 42)

checked exceptions => Either[A, B] or Try[T]

• rewriting exposes inconsistencies
• often far reaching changes

good opportunity to introduce semantically richer error types:

public Provider providerForApp(Application a,
                               List<Provider> ps)
                               throws Exception1, Exception2

def providerForApp(a:  Application,
                   ps: Seq[Provider]): Either[Seq[Refusal], Provider]

</hibernate>

scalaquery was somewhat immature

• difficult to figure out DSL
• encountered a few weird bugs in SQL generation
• technical limitations leaked over to domain types
• stuck with it because of promise and because it brought sanity.
• slick 1 was a relief

Technical limitations leaked over to domain types

• catch 22 made us to split up database tables
• Option[Long] id fields in case classes for auto-increment fields

Sanity/sleep well at night

@Transactional
public void saveThingie(final Thingie t) {
    sessionFactory.getCurrentSession().save(t);
}

def saveThingie(t: Thingie)(implicit s: Session) =
    ThingieTable insert t

Despringify

Replacement functionality

• spring comes with... everything
• most functionality we need exists in scala stdlib, or is easy to write yourself
• took a few other dependencies, like commons-fileupload, and commons-email

app wiring

• started rewiring components early because of slick
• two apps in one, with somewhat intertwining dependencies
• ugh...

Have spring do the ultimate wiring

Share config and database connection

@Configuration
class SpringBeans {
  @Bean @Autowired
  def concreteApp(ds: javax.sql.DataSource, cfg: Config): ConcreteApp = {
    new ConcreteApp with DataSourceDbConnectionComponent {
      lazy val datasource = ds
      lazy val conf       = cfg
    }
  }
}

Spring MVC/JSP

• by far biggest challenge
• unfiltered, argonaut
• wrote a toolkit for form handling
• wrote minimalistic templating engine
• two months of dedicated time

Product owners

• might not be as enthusiastic
• sell them something else

Porting timeline

Time usage

• six months of preparatory refactoring

• one year on and off porting

• no dedicated time until december 2013

• two months stop-the-world development to code new frontend, rewrite http layer and wrap up porting effort

Codebase evolution

june 2012 - april 2014

Conclusion

• 👍 developer happiness
• 👍 peace of mind/trust in code
• 👍 similar technology between projects