Java to Kotlin

Chapter 6. Java to Kotlin Collections

On the face of it, Java and Kotlin have very similar collections libraries; they certainly interoperate suspiciously seamlessly. What are the differences, what motivates them, and where do we have to take care as we move from Java to Kotlin collections?

Java Collections

In Chapter 5 we saw how Java grew up in the days when we saw objects as fundamentally stateful and mutable. This was particularly true for collections—I mean, what is the point of a list if you can’t add to it? We build collections by creating an empty one and adding to it. Need to remove an item from a shopping cart? Mutate the list. Shuffle a pack of cards? Obviously that changes the order of the deck. We wouldn’t create a new paper to-do list every time we need milk or take the cat to the vet. Mutable collections mirror our real world experience.

On its release, the quality of its built-in collections was a good reason to adopt Java. In those days many languages had no resizable collections in their standard library. Object technology allowed us to define and use mutable collections safely. It was only natural to use this superpower now that it had been given to us, so we went ahead and used Vector and HashTable as Sun intended. Which is to say, we created them and then mutated them. There was no choice, because all the constructors created empty collections.

Java 2 (which was version 1.2 until Java had to compete with C# version numbers) introduced a revised collections ...