Scala
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Object-Oriented Scala
-
Section 4: Functional Scala
-
Section 5: Collections in Depth
-
Section 6: Type System
-
Section 7: Concurrency and Ecosystem
-
Section 8: Practical Projects
-
Section 9: Interview Practice
-
Section 10: Data Structures and Algorithms in Scala
-
Section 11: More Practice Exercises
-
Section 12: Advanced Functional Patterns
-
Section 13: More Ecosystem
-
Section 14: Scala Collections Library Deep Dive
-
Section 15: Scala Standard Library Deep Dive
-
Section 16: Akka Ecosystem Deep Dive
-
Section 17: Cats and Cats Effect Deep Dive
-
Section 18: Play Framework Deep Dive
-
Section 19: Apache Spark with Scala Deep Dive
-
Section 20: Scala Build Tools Deep Dive
-
Section 21: Scala 3 Specific Features
-
90: Union and Intersection Types
-
Section 22: Scala Testing Deep Dive
-
Section 23: Functional Domain Modeling
-
Section 24: More Data Structures and Algorithms in Scala
-
Section 25: Scala for Data Engineering
-
Section 26: More Practical Projects
-
Section 27: More Interview and Review
-
Section 28: ZIO Ecosystem Deep Dive
-
Section 29: Scala for Machine Learning
-
Section 30: Scala Microservices Architecture
-
Section 31: Scala Type System Deep Dive
-
Section 32: More Practice and Drills
-
Section 33: Scala Performance Deep Dive
-
Section 34: Scala Ecosystem Tooling
-
Section 35: Scala for Reactive Systems
-
Section 36: More Real-World Case Studies
-
Section 37: Scala for Financial Systems
-
Section 38: Scala GraphQL and gRPC
-
Section 39: More Final Projects
-
Section 40: More Interview and Final Review
-
Section 41: Scala for Streaming Data
-
Section 42: Scala Security Practices
-
Section 43: More Language Deep Dive
-
Section 44: Scala Command-Line Tools
-
Section 45: Scala Documentation and Style
-
Section 46: Scala Dependency Management
-
Section 47: More Practical Backend Patterns
-
Section 48: Scala for Event-Driven Architecture
-
Section 49: More Practice Drills Round 2
-
Section 50: Scala Compiler Deep Dive
-
Section 51: Scala for Web Frontends
-
Section 52: More Data Engineering Practice
-
Section 53: Scala Observability
-
Section 54: More Advanced Practice Projects
-
Section 55: Scala for Legacy Java Integration
-
Section 56: More Testing Practice
-
Section 57: Final Mastery Review
-
Section 58: Scala History and Ecosystem Context
-
Section 59: More Concurrency Patterns
-
Section 60: Scala for Configuration Management
-
Section 61: More Domain Modeling Practice
221: Converting Java Collections to Scala Collections
In a perfect world, every library you use would be written in pure Scala. In the real world, you're going to spend a significant amount of time interfacing with Java libraries. Whether it's a database driver or a legacy payment SDK, these libraries will hand you java.util.List, java.util.Map, or java.util.Set. The problem is that these Java collections don't have the rich functional API we love in Scala—no filter, map, or foldLeft without some awkward jumping through hoops.
The temptation to manually migrate
When I first started mixing Java and Scala, my instinct was to just "move" the data. I'd get a java.util.List back from an API, and I'd write a loop or a manual transformation to shove everything into a Scala List. It looks something like this:
import java.util.ArrayList
// Imagine this comes from a Java SDK
val javaTransactions = new ArrayList[Double]()
javaTransactions.add(100.0)
javaTransactions.add(50.0)
// The naive way: manually building a new Scala list
var scalaList = List[Double]()
val it = javaTransactions.iterator()
while (it.hasNext) {
scalaList = scalaList :+ it.next()
}
This is painful to write and even more painful to read. More importantly, it's inefficient. By using :+ in a loop, I'm creating a new list object on every single iteration. If that Java list has ten thousand entries, the garbage collector is going to have a very bad day. Even if you use a mutable.ArrayBuffer and then call .toList, you're still performing a full copy of the data just to get access to Scala's methods.
Wrapping instead of copying
The professional way to handle this is using scala.jdk.CollectionConverters. Instead of copying the data into a new structure, Scala provides a way to "wrap" the Java collection. This wrapper implements the Scala collection interfaces but delegates the actual data storage to the original Java object.
import scala.jdk.CollectionConverters._
val javaTransactions = new java.util.ArrayList[Double]()
javaTransactions.add(100.0)
javaTransactions.add(50.0)
// This is the magic: .asScala
val scalaTransactions = javaTransactions.asScala
// Now I have the full power of Scala
val highValue = scalaTransactions.filter(_ > 75.0).toList
Notice that .asScala doesn't actually move any elements. It creates a lightweight wrapper. This is an O(1) operation, regardless of whether the list has five elements or five million. I've seen developers avoid this because they're afraid of the "magic," but it's the standard way to bridge the two languages.
The cost of the wrapper vs. the cost of the copy
There is one critical trade-off you need to keep in mind: the wrapper is a live view. Because asScala doesn't copy the data, if the original Java list is modified by some other part of the system, your Scala wrapper will reflect those changes. This is usually what you want, but it can lead to ConcurrentModificationException if you're iterating over the Scala wrapper while another thread is mutating the Java list.
If you need a "snapshot" of the data that is guaranteed not to change, you should chain .asScala with a conversion to an immutable collection, like .toList or .toSeq. This does perform the copy, but it gives you the safety of Scala's immutability. I generally recommend .asScala` for internal transformations and .asScala.toList when the data is leaving a method and moving into a part of the app where you can't trust the source to stay static.
📋 Practical Task
Filtering Legacy Java Transaction Logs
You are working with a legacy Java accounting library that returns a java.util.Map[String, Double] where the key is a Transaction ID and the value is the amount. Your task is to process this Java map using Scala's functional tools.
Requirements:
- Create a
java.util.HashMap[String, Double]and populate it with at least four entries (e.g., "TXN001" -> 120.50, "TXN002" -> 45.00, etc.). - Use
scala.jdk.CollectionConvertersto wrap this Java map into a Scala collection. - Using the Scala wrapper, filter the map to keep only transactions greater than 100.00.
- Convert the final filtered result into an immutable Scala
Map. - Print the final immutable map to the console.
There are no comments for now.