(mostly)

How we moved from
         ^

   Java to Scala
     Graham Tackley
     guardian.co.uk
History

• Java shop since 2006
• guardian.co.uk: java + spring + velocity +
  hibernate + oracle
• ~100k lines production java code (and
  ~35k xml...)
Content API
• Provide API to access all of our website
  content
• Limited beta released early 2009
• Started implementation of final version late
  2009
• Live May 2010:
  http://content.guardianapis.com
Content API


(demo of http://content.guardianapis.com)
November 2009


• Started new Content API implementation
• java + guice + guice servlets + apache solr
November 2009


• A few people had played with scala
• No production scala code
January 2010
• Comprehensive integration tests were very
  important to us
• Started writing our integration tests in
  Scala with the awesome ScalaTest
• Already a maven project, so mixed scala-
  java support easy with maven-scala-plugin


                                             demo: mavan-scala-plugin, ScalaTest
January 2010
January 2010


• A fair bit of our test code was java-
  without-semicolons as we learnt about
  Scala...
January 2010
February 2010

• ... despite that we loved it so much that
  after a month we decided to convert the
  whole app to Scala
• scala + guice + guice servlets + apache solr
February 2010




Still some very java-like code...
February 2010




... immediate win with non-IDE generated constructors ...
February 2010




... and some things much more readable than Java
Our top 5 things we
 loved about scala
    on day one
1. Sensible Class Constructors



             =>
2. Type inference / val & var

List<String> myList = new ArrayList<String>();



                      =>

import java.util.ArrayList
val myList = new ArrayList[String]
3. No source file naming
           constraints


• Don’t need to be named after package &
  class name like java
• So multiple classes are allowed in a single file


                                              e.g. ResponseRenderer.scala
4. REPL (console)



• run “scala” for a scala shell
• awesome for experimentation
5. Same tools, libs, deployment &
 runtime characteristics as Java

• We still use IntelliJ (with the scala plugin)
• A scala war file is just a war file
• All the experience of running jvm in
  production still applies
• Can still use java libraries

                                          e.g. GuiceServletConfig.scala, XmlFormatter.scala
From Day One

Sensible class constructors                                   +1

No getters & setters

val and var, implict variable typing                          +4

No filename restrictions

No need for semicolons                                        +1

Same tools, lib, depoyment, runtime characteristics as java   +1

Less { }

object keyword

decent collections library

“”” string notation

list.filter(_.test).map(_.transformation)                     +1

case classes for value object                                 +2

default parameters

regexes: .r & unapply                                         +1

it’s fun!

val => encourages immutubility

traits                                                        +2

match statements

library DSLs such as lift-json

easy maps and lists

REPL                                                          +1

write the java you know then refine

map, filter etc

Far more expressive code

Functions as first class objects
Our top 5 things we
          loved about scala
             on day one

                          SUMMARY:
Scala is great even if you only use it as a more concise java
                 (java-without-semicolons™);
             for us this was a great way to start.
July 2010

• Switched from maven to simple-build-tool
• Mainly for incremental compilation
• ~ test-quick and ~ prepare-webapp also
  invaluable
Our top 5 things we
 love about scala
   one year on
1. Option
or How we learned to stop worrying and love the Option

 We’d read “don’t use nulls, use Option instead”
                DAY ONE
               x != null
                 became
             x.isDefined
               DAY THREE
     x match {
       case None => ...
       case Some(value) => ...
     }
1. Option
    or How we learned to stop worrying and love the Option

                       WEEK THREE




                          TODAY



We now think of Options as lists with zero or one entries
2. powerful collections library




it took us a while to realise that most of the loops we
     wrote in Java were actually “map” or “flatMap”
2. powerful collections library




it took us a while to realise that most of the loops we
     wrote in Java were actually “map” or “flatMap”
3. traits as mixins



 demo: SearchRequest
4. implicit conversions to
      enhance existing classes


      Content API extensively uses Solr/J,
     which is good but returns loads of nulls



We used implicit conversions to hide the Java yuk


                                                demo: RichSolrDocument
5. pattern matching



    demo: UserTier
After a couple of months

Using Option properly

Functional programming - i.e. without side effects           +1

Powerful collections library

traits as mixins                                             +2

json & xml parsing & generation

implicit conversions to enhance existing classes             +2

regexes

apply and unapply methods

infix statements

learning not to overcomplicate

thinking functionally

DSLs

Actors

Rename imported classes

Extractors & pattern matching                                +1

Passing closures all

Companion object pattern

currying functions

default parameters and case class copy methods

parser combinators                                           +1

implicits and traits instead of dependency injection

partial functions

null is not an option
Summary
• Migration path from Java relatively smooth
• Take it easy, and don’t fear java-without-
  semicolons in the early days
• An incremental embrace of Scala features
  worked really well for us
• Hide the Java yuk with implicit conversions
• http://content.guardianapis.com
• http://www.guardian.co.uk/open-platform
• http://github.com/guardian/open-platform-
  content-api-scala-client
• And we’re hiring:
  http://www.gnmcareers.co.uk ref JS323
       graham.tackley@guardian.co.uk

LSUG: How we (mostly) moved from Java to Scala

  • 1.
    (mostly) How we movedfrom ^ Java to Scala Graham Tackley guardian.co.uk
  • 2.
    History • Java shopsince 2006 • guardian.co.uk: java + spring + velocity + hibernate + oracle • ~100k lines production java code (and ~35k xml...)
  • 3.
    Content API • ProvideAPI to access all of our website content • Limited beta released early 2009 • Started implementation of final version late 2009 • Live May 2010: http://content.guardianapis.com
  • 4.
    Content API (demo ofhttp://content.guardianapis.com)
  • 5.
    November 2009 • Startednew Content API implementation • java + guice + guice servlets + apache solr
  • 6.
    November 2009 • Afew people had played with scala • No production scala code
  • 7.
    January 2010 • Comprehensiveintegration tests were very important to us • Started writing our integration tests in Scala with the awesome ScalaTest • Already a maven project, so mixed scala- java support easy with maven-scala-plugin demo: mavan-scala-plugin, ScalaTest
  • 8.
  • 9.
    January 2010 • Afair bit of our test code was java- without-semicolons as we learnt about Scala...
  • 10.
  • 11.
    February 2010 • ...despite that we loved it so much that after a month we decided to convert the whole app to Scala • scala + guice + guice servlets + apache solr
  • 12.
    February 2010 Still somevery java-like code...
  • 13.
    February 2010 ... immediatewin with non-IDE generated constructors ...
  • 14.
    February 2010 ... andsome things much more readable than Java
  • 15.
    Our top 5things we loved about scala on day one
  • 16.
    1. Sensible ClassConstructors =>
  • 17.
    2. Type inference/ val & var List<String> myList = new ArrayList<String>(); => import java.util.ArrayList val myList = new ArrayList[String]
  • 18.
    3. No sourcefile naming constraints • Don’t need to be named after package & class name like java • So multiple classes are allowed in a single file e.g. ResponseRenderer.scala
  • 19.
    4. REPL (console) •run “scala” for a scala shell • awesome for experimentation
  • 20.
    5. Same tools,libs, deployment & runtime characteristics as Java • We still use IntelliJ (with the scala plugin) • A scala war file is just a war file • All the experience of running jvm in production still applies • Can still use java libraries e.g. GuiceServletConfig.scala, XmlFormatter.scala
  • 21.
    From Day One Sensibleclass constructors +1 No getters & setters val and var, implict variable typing +4 No filename restrictions No need for semicolons +1 Same tools, lib, depoyment, runtime characteristics as java +1 Less { } object keyword decent collections library “”” string notation list.filter(_.test).map(_.transformation) +1 case classes for value object +2 default parameters regexes: .r & unapply +1 it’s fun! val => encourages immutubility traits +2 match statements library DSLs such as lift-json easy maps and lists REPL +1 write the java you know then refine map, filter etc Far more expressive code Functions as first class objects
  • 22.
    Our top 5things we loved about scala on day one SUMMARY: Scala is great even if you only use it as a more concise java (java-without-semicolons™); for us this was a great way to start.
  • 23.
    July 2010 • Switchedfrom maven to simple-build-tool • Mainly for incremental compilation • ~ test-quick and ~ prepare-webapp also invaluable
  • 24.
    Our top 5things we love about scala one year on
  • 25.
    1. Option or Howwe learned to stop worrying and love the Option We’d read “don’t use nulls, use Option instead” DAY ONE x != null became x.isDefined DAY THREE x match { case None => ... case Some(value) => ... }
  • 26.
    1. Option or How we learned to stop worrying and love the Option WEEK THREE TODAY We now think of Options as lists with zero or one entries
  • 27.
    2. powerful collectionslibrary it took us a while to realise that most of the loops we wrote in Java were actually “map” or “flatMap”
  • 28.
    2. powerful collectionslibrary it took us a while to realise that most of the loops we wrote in Java were actually “map” or “flatMap”
  • 29.
    3. traits asmixins demo: SearchRequest
  • 30.
    4. implicit conversionsto enhance existing classes Content API extensively uses Solr/J, which is good but returns loads of nulls We used implicit conversions to hide the Java yuk demo: RichSolrDocument
  • 32.
    5. pattern matching demo: UserTier
  • 33.
    After a coupleof months Using Option properly Functional programming - i.e. without side effects +1 Powerful collections library traits as mixins +2 json & xml parsing & generation implicit conversions to enhance existing classes +2 regexes apply and unapply methods infix statements learning not to overcomplicate thinking functionally DSLs Actors Rename imported classes Extractors & pattern matching +1 Passing closures all Companion object pattern currying functions default parameters and case class copy methods parser combinators +1 implicits and traits instead of dependency injection partial functions null is not an option
  • 34.
    Summary • Migration pathfrom Java relatively smooth • Take it easy, and don’t fear java-without- semicolons in the early days • An incremental embrace of Scala features worked really well for us • Hide the Java yuk with implicit conversions
  • 35.
    • http://content.guardianapis.com • http://www.guardian.co.uk/open-platform •http://github.com/guardian/open-platform- content-api-scala-client • And we’re hiring: http://www.gnmcareers.co.uk ref JS323 graham.tackley@guardian.co.uk