Nicolas Fränkel is a Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Currently working for Exoscale. Also double as a teacher in universities and higher education schools, a trainer and triples as a book author.
Unfortunately, I must admit I have a hard time reading the documentation of Scala collections e.g.:
trait LinearSeq [+A] extends Seq[A] with collection.LinearSeq[A] with GenericTraversableTemplate[A, LinearSeq] with LinearSeqLike[A, LinearSeq[A]]
Hence, I will only describe collections from the Kotlin side.
At the root of Kotlin’s Collection API lies the
Iterator interface, similar to Java’s. But the similitude stops after that.
java.util.ListIterator features are broken down into different contracts:
ListIteratorto move the iterator index forward and backward
MutableIteratorto remove content from the iterator
MutableListIteratorinherits from the 2 interfaces above to mimic the entire contract of
在Kotlin的Collection API的根源是Iterator接口，类似于Java。但在此之后，相似之处就停止了。java.util.ListIterator 功能分为不同的协议：
Collection, List and Set
The hierarchy of collections in Kotlin are very similar as in Java:
Set. (I won’t detail maps, but they follow the same design). The only, but huge, difference is that it’s divided between mutable and immutable types. Mutable types have methods to change their contents (e.g.
add() andset()`), while immutable types don’t.
Of course, the hierarchy is a bit more detailed compared to Java, but that’s expected from a language that benefits from its parent’s experience.
IMHO, the important bit about Kotlin collections is not their hierarchy - though it’s important to understand about the difference between mutable and immutable.
As Java developers know, there’s no such things as out-of-the-box immutable collection types in Java. When an immutable collection is required, the mutable collection must be wrapped into an unmodifiable type via a call to the relevant
Collections.unmodifiableXXX(). But unmodifiable types are not
public, they are
Collections: types returned are generic ones (
Set interfaces). It means they implement all methods of the standard collections. Immutability comes from the mutable-related methods throwing exceptions: at compile time, there’s no way to differentiate between a mutable and an immutable collection.
On the opposite, Kotlin offers a clean separation between mutable and immutable types. It also provides dedicated functions to create objects of the relevant type:
As opposed to Scala, Kotlin doesn’t implement its own collection types, it reuses those from Java. That means that even when the compile-time type is immutable, the runtime type is always mutable. The downside is that it’s possible to change the collection elements by casting it to the correct runtime type. IMHO, this is no more severe than what allows standard reflection. There are several advantages, though:
To go further:
The build file is configured to download and use an embedded Tomcat server. So t...
IBM i has evolved overtime and organizations are modernizing their existing lega...