Summary

The provided content discusses the problems with Java collections, particularly their mutable-by-default nature, and how Kotlin addresses these issues by inverting the collection hierarchy to prioritize immutability.

Abstract

The article titled "Basic Collections: Introduction" critically examines the design of Java collections, pointing out that their mutable-by-default design leads to violations of the Liskov Substitution Principle and increases the risk of runtime errors due to the inability to enforce immutability at the declaration site. It highlights the significant drawback of Java collections, which is their encouragement of passing immutable implementations where mutable ones are expected, leading to potential runtime errors. In contrast, Kotlin's approach to collections is praised for reversing this paradigm, making immutability the norm and providing a safer and more robust collection framework. The article outlines Kotlin's collection interfaces, which are immutable by default, and explains various methods for constructing collections in Kotlin, including the use of xOf() methods, builder functions, and invoking functions on other collections. It emphasizes that Kotlin's collections are fully compatible with Java while offering a more logical and secure design.

Opinions

The author believes that Java's decision to make collections mutable by default is a significant failure, as it leads to a breach of the Liskov Substitution Principle and makes it difficult to ensure type safety and immutability.
The article suggests that Java's approach to collections encourages practices that can lead to runtime errors, which are considered to be a developer's worst enemy.
Kotlin's collection design is seen as a superior alternative to Java's, as it correctly models immutable collections as the base type, with mutable collections as extensions, thus aligning with the true nature of these data structures.
The author expresses that Kotlin's collection interfaces, such as List, Set, and Map, provide a more intuitive and error-proof way of handling collections, as they ensure that mutable implementations can safely be used wherever an immutable interface is expected.
The article conveys a clear preference for Kotlin's collection construction methods, which include both immutable and mutable options, as well as functions for creating empty collections and copying existing ones.
The author's opinion is that Kotlin's approach to collections not only improves upon Java's design but also integrates well with existing Java code, making it a practical choice for Java-centric organizations looking to adopt Kotlin.

Basic Collections: Introduction

Why Java collections are extremely problematic, and how Kotlin takes a different approach. A description of all the different methods to create collections — construction from elements, builder functions, concrete type constructors/initializer functions, copying and invoking functions on other collections.

— — — — — — — — — — — — — — —

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

— — — — — — — — — — — — — — —

Tags: #FYI++

This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.

It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.

The Java status quo

One of the biggest failures of Java collections is that they are mutable by default — for example, java.util.List describes a mutable list. This is a pretty serious problem, because it breaks the ‘L’ (which stands for Liskov Substitution Principle) in SOLID, namely that subclasses are always usable in place of their superclasses.

To see how, think about how you would implement an immutable list in Java. Naturally, you’d want it to implement the java.util.List interface, because that’s what everyone uses, but that interface describes a mutable list — it defines methods such as add, remove etc. In order to conform to this interface, you have no choice but to implement these by throwing an exception, which is exactly what e.g. Guava does in its ImmutableList implementation.

Unfortunately, what this means is that your implementation cannot be used safely wherever it’s parent (e.g. List) can. You can call add on List, but you can never be sure it won’t throw an exception. I can pass a Guava ImmutableList anywhere a List is expected with no complaint from the compiler, and introduce a runtime error just like that. And as we’ve said many times before, runtime errors are your worst enemy!

What’s even worse is that Java actively encourages you to do this, which is just beyond comprehension. So, to sum it up, in Java:

When implementing an immutable list, we have the choice of either implementing List, thereby breaking the Liskov Substitution Principle, or not implementing List, thereby making our implementation practically unusable
We have no way to enforce immutability at the declaration site (e.g. when defining a method parameter) without tying our declaration to a specific implementation
We risk causing runtime errors when we pass an immutable implementation at the call site (e.g. when calling a method). To prevent this, we need to study all code that will interact with our implementation, which breaks encapsulation.

And, worst of all, there’s no fixing this without breaking backwards compatibility — Java has no choice but to stick with this sad state of affairs.

Kotlin to the rescue

The core problem is that, in Java, immutable collections are modeled as subclasses of mutable collections, when in reality, it’s the other way around. A mutable collection contains more functionality than an immutable version — it’s an immutable collection + methods that allow it to be mutated. It needs to be a subclass of its immutable variant. And this is exactly how Kotlin defines its collections.

It should be noted that so far, we’re only talking about interfaces. Iterable, List, MutableMap etc. are all interfaces, not actual implementations. The actual implementations are always mutable, but that doesn’t matter — if a method is expecting a List<T>, and List is an immutable interface, then we can safely send in a mutable implementation (e.g. ArrayList<T>) and everything will be fine, because every mutable implementation implements List. And by implements, I mean actually, safely implements, as opposed to implements but throws exceptions sometimes.

Naturally, Kotlin collections are compatible with Java. Java versions will get cast to the appropriate platform type when used in Kotlin code.

As can be seen above, the fundamental collections are List, Set and Map, and a quick overview can be found in the docs.

Constructing collections

The most basic, and most often used, way to construct collections are using the xOf() methods — listOf() for an immutable List instance, mutableSetOf() for a mutable Set instance, and so on. For the most part, their usage is fairly straightforward. The only nontrivial aspect is constructing instances of Map, where you specify key-value pairs using instances of Pair. The to infix function, which we mentioned briefly in the article on data classes, can be taken advantage of:

There are also functions that specify the actual implementation to use, such as arrayListOf(), hashSetOf(), and others.

There are dedicated functions to create empty immutable collections. To create empty mutable variants, just use the above functions and pass no arguments. In both cases, since we aren’t passing any elements, we need to specify the type explicitly, either via a type hint or by explicitly specifying the generic parameter.

There are various other methods of constructing collections you should be aware of:

using builder functions (which we touched upon when talking about DSLs)
concrete type constructors (and, for List, initializer functions)
copying
invoking functions on other collections

Of those, invoking functions on other collections is by far the most used.

Go back to Programming with Result: Combining and Composing Results, jump to the Table of Contents, or continue to Functional vs.? Object Oriented Programming.