Presentation from talk done at the London Scala User Group on Wednesday 12th Jan 2011. http://skillsmatter.com/podcast/java-jee/how-we-mostly-moved-from-java-to-scala

1. (mostly)
How we moved from
^
Java to Scala
Graham Tackley
guardian.co.uk

2. History
• Java shop since 2006
• guardian.co.uk: java + spring + velocity +
hibernate + oracle
• ~100k lines production java code (and
~35k xml...)

3. 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

4. Content API
(demo of http://content.guardianapis.com)

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

6. November 2009
• A few people had played with scala
• No production scala code

7. 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

8. January 2010

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

10. January 2010

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 some very java-like code...

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

14. February 2010
... and some things much more readable than Java

15. Our top 5 things we
loved about scala
on day one

16. 1. Sensible Class Constructors
=>

17. 2. Type inference / val & var
List<String> myList = new ArrayList<String>();
=>
import java.util.ArrayList
val myList = new ArrayList[String]

18. 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

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
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

22. 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.

23. July 2010
• Switched from maven to simple-build-tool
• Mainly for incremental compilation
• ~ test-quick and ~ prepare-webapp also
invaluable

24. Our top 5 things we
love about scala
one year on

25. 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) => ...
}

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 collections library
it took us a while to realise that most of the loops we
wrote in Java were actually “map” or “flatMap”

28. 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”

29. 3. traits as mixins
demo: SearchRequest

30. 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

32. 5. pattern matching
demo: UserTier

33. 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

34. 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

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