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

(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 ﬁnal 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 2010Still 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 & varList<String> myList = new ArrayList<String>(); =>import java.util.ArrayListval myList = new ArrayList[String]

3. No source ﬁle naming constraints• Don’t need to be named after package & class name like java• So multiple classes are allowed in a single ﬁle 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 OneSensible class constructors +1No getters & settersval and var, implict variable typing +4No filename restrictionsNo need for semicolons +1Same tools, lib, depoyment, runtime characteristics as java +1Less { }object keyworddecent collections library“”” string notationlist.filter(_.test).map(_.transformation) +1case classes for value object +2default parametersregexes: .r & unapply +1it’s fun!val => encourages immutubilitytraits +2match statementslibrary DSLs such as lift-jsoneasy maps and listsREPL +1write the java you know then refinemap, filter etcFar more expressive codeFunctions 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. Optionor 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 TODAYWe now think of Options as lists with zero or one entries

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

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 nullsWe used implicit conversions to hide the Java yuk demo: RichSolrDocument

5. pattern matching demo: UserTier

After a couple of monthsUsing Option properlyFunctional programming - i.e. without side effects +1Powerful collections librarytraits as mixins +2json & xml parsing & generationimplicit conversions to enhance existing classes +2regexesapply and unapply methodsinfix statementslearning not to overcomplicatethinking functionallyDSLsActorsRename imported classesExtractors & pattern matching +1Passing closures allCompanion object patterncurrying functionsdefault parameters and case class copy methodsparser combinators +1implicits and traits instead of dependency injectionpartial functionsnull 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

http://lanyrd.com	37
http://www.mongodb.org	9
http://paper.li	3
http://twitter.com	3
http://www.linkedin-ei2.com	2
http://squadzik.blogspot.com	2
http://inspiraciondemusas.blogspot.com	2
http://www.demysex.org.mx	1
http://www.onlydoo.com	1
http://www.studysols.com	1
http://disasterawareness.blogspot.com	1
http://tweetedtimes.com	1
http://solar.gwu.edu	1
http://www.linkedin.com	1

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

by Graham Tackley on Jan 14, 2011

Accessibility

Categories

Upload Details

Usage Rights

14 Embeds 65

Statistics

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