Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to keep maintainability of long life Scala applications

3,418 views

Published on

at Scala Kansai Summit 2018 #scala_ks

Published in: Software
  • Be the first to comment

How to keep maintainability of long life Scala applications

  1. 1. How to keep maintainability of long life Scala applications Naoki Takezoe @takezoen Arm Treasure Data
  2. 2. Who? ● Naoki Takezoe ○ Arm Treasure Data ○ Scala Programmer ● Open Source ○ GitBucket ○ Apache PredictionIO ○ Scalatra
  3. 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. 4. Two difficulties ● Programming style ● Upgrade
  5. 5. Programming style
  6. 6. Programming styles ● Functional or Procedural? ● Functional or Object oriented? Depends on your team organization
  7. 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. 8. Upgrade
  9. 9. Three types of upgrade ● Upgrade frameworks ● Upgrade Scala ● Upgrade Java Usually, they cannot be isolated
  10. 10. Case Studies
  11. 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. 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. 13. Scala specific difficulties 1. Backward compatibility of frameworks 2. Binary compatibility of Scala versions
  14. 14. Scala specific difficulties 1. Backward compatibility of frameworks 2. Binary compatibility of Scala versions
  15. 15. Backward compatibility of frameworks ● Play ○ Play1 (Java) → Play2 (Scala) ○ Dependency Injection ● Slick ○ ScalaQuery → Slick ○ IO Monad ● Spray ○ Spray → Akka HTTP
  16. 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. 17. Scala specific difficulties 1. Backward compatibility of frameworks 2. Binary compatibility of Scala versions
  18. 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. 19. Library dependency in build.sbt ● Group ID: com.typesafe.akka ● Artifact ID: akka-actor_2.12 ● Version: 2.5.17 Scala version
  20. 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. 21. ● build.sbt ● Create jar files Cross build to support multiple Scala version crossScalaVersions := Seq("2.11.11", "2.12.2") $ sbt +package
  22. 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. 23. Cross build to support multiple Scala version ● Switch source code by Scala version
  24. 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. 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. 26. Appendix
  27. 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. 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. 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. 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. 31. Summary
  32. 32. Summary ● Do upgrade regularly ● Reduce library dependencies ● Sometimes, Java might help you ● Have a strong mind!
  33. 33. Change or Stop? ● Scala chooses to keep changing (with ease of upgrading as much as possible) ● Enjoy changing with Scala!
  34. 34. Thank you for listening!

×