Naoki Takezoe discusses maintaining long-term Scala applications. He outlines two main difficulties: programming style differences that impact understandability and upgrades that require coordinating framework, Scala, and Java version changes. Case studies show upgrades can be blocked until dependent libraries support new versions. Solutions include reducing dependencies, using popular libraries, custom libraries for core components, and considering Java alternatives. Regular maintenance and preparing for breaking changes are key to sustainable Scala applications.

1. How to keep maintainability
of
long life Scala applications
Naoki Takezoe
@takezoen
Arm Treasure Data

2. Who?
● Naoki Takezoe
○ Arm Treasure Data
○ Scala Programmer
● Open Source
○ GitBucket
○ Apache PredictionIO
○ Scalatra

3. My Scala Experience
● 2012 My first Scala in Production
● 2013 GitBucket
● 2014 Scala in large team for web services
● 2017 PredictionIO committer
All of them are still maintained!

4. Two difficulties
● Programming style
● Upgrade

5. Programming style

6. Programming styles
● Functional or Procedural?
● Functional or Object oriented?
Depends on your team organization

7. Just my opinion
● Procedural OOP + FP features is good
○ Pattern matching, Type class, Macro, etc...
○ Easy to understand for non-FP guys
● Share the reason why we use Scala
○ For Functional Programming is OK
○ Otherwise, What's the reason why we use Scala,
not Java or Kotlin

8. Upgrade

9. Three types of upgrade
● Upgrade frameworks
● Upgrade Scala
● Upgrade Java
Usually, they cannot be isolated

10. Case Studies

11. Case #1: Upgrade to Scala 2.12
● Why?
○ Advantage in compilation speed, etc…
● Obstacles
○ Needed upgrading Play and Slick at the same time
■ Both had large breaking API changes
○ Libraries hadn't supported Scala 2.12 yet
■ Wait for their release, Pull request or Fork?

12. Case #2: Upgrade to Java8
● Why?
○ Java's commercial support matter
● Obstacles
○ Needed upgrading Scala to work on Java8
■ Same as Case #1
○ Upgrade after long abandon was really tough
■ Migration guides don't cover jumping multiple
versions at once

13. Scala specific difficulties
1. Backward compatibility of frameworks
2. Binary compatibility of Scala versions

14. Scala specific difficulties
1. Backward compatibility of frameworks
2. Binary compatibility of Scala versions

15. Backward compatibility of frameworks
● Play
○ Play1 (Java) → Play2 (Scala)
○ Dependency Injection
● Slick
○ ScalaQuery → Slick
○ IO Monad
● Spray
○ Spray → Akka HTTP

16. Solutions
● Don't mind because it's Scala culture
● 2.12.x era is stable
● Using Java frameworks with Scala
● Scala3: new storm of breaking changes?

17. Scala specific difficulties
1. Backward compatibility of frameworks
2. Binary compatibility of Scala versions

18. Backward compatibility policy in Scala
● Minor upgrade (e.g. 2.12.1 → 2.12.2)
○ Binary compatible
● Major upgrade (e.g. 2.12 → 2.13)
○ Includes binary incompatible

19. Library dependency in build.sbt
● Group ID: com.typesafe.akka
● Artifact ID: akka-actor_2.12
● Version: 2.5.17
Scala version

20. Another Scala version library can be used
● Scala version is determined automatically
● Specify Scala version explicitly
libraryDependencies +=
"com.typesafe.akka" %% "akka-actor" % "2.5.17"
libraryDependencies +=
"com.typesafe.akka" % "akka-actor_2.12" % "2.5.17"
Of course, there is no guarantee!

21. ● build.sbt
● Create jar files
Cross build to support multiple Scala version
crossScalaVersions := Seq("2.11.11", "2.12.2")
$ sbt +package

22. Cross build to support multiple Scala version
● Switch configuration by Scala version
libraryDependencies +=
"org.apache.spark" %% "spark-core" % {
scalaVersion.value match {
case x if x.startsWith("2.10.") => "1.6.3"
case _ => "2.1.1"
}
}

23. Cross build to support multiple Scala version
● Switch source code by Scala version

24. Binary incompatibility causes
● Risk of unmaintained libraries
○ Possibility of being unavailable in the future
version of Scala
● Move to another library? or Keep maintain
by yourself?
○ Unexpected costs

25. Solutions
● Reduce library dependencies
● Use popular libraries as much as possible
● Create a tiny library by yourself
● Java library might be a great option

26. Appendix

27. at GitBucket...
● Maintain frameworks by myself
○ Became a Scalatra committer
○ Made blocking-slick which offers Slick2
compatible API on the top of Slick3
● Made some core components with Java
○ Markedj (GitHub compatible Markdown parser)
○ Solidbase (Multi tenant DB migration tool)

28. at Treasure Data...
● Airframe (https://github.com/wvlet/airframe)
○ Lightweight building blocks based on dependency
injection
○ Centralizing dependent libraries enables us to
focus to maintain a single library

29. Cost and Resource for maintenance
● Basic issues
○ Lack of Scala programmers
○ Low motivation for maintaining legacy applications
● Sudden upgrading costs a lot
○ Security issues
○ Commercial support for JVM
● Scala is not good for applications which
cannot be maintained regularly

30. Apache Spark as obstacle
● Spark is killer application in Scala
○ But often be a blocker of upgrading
● Doesn't support new Scala version shortly
○ Scala 2.12 support is coming in Spark 2.4
● Huge dependencies to old libraries
○ Causes version conflicts in many libraries

31. Summary

32. Summary
● Do upgrade regularly
● Reduce library dependencies
● Sometimes, Java might help you
● Have a strong mind!

33. Change or Stop?
● Scala chooses to keep changing (with ease
of upgrading as much as possible)
● Enjoy changing with Scala!

34. Thank you for listening!