Skip to main content

The Scala's Equivalent of Java ArrayList

ArrayList is a widely misused "default" List in Java. It has terrible performance when elements are added/removed frequently, but works pretty well as a replacement for Array


But what about Scala?
  • What is Scala's default collection?
  • What Scala collection has characteristics similar to ArrayList?
  • What's a good replacement for Array in Scala?
So here are the answers for these:

What is Scala's default collection?

Scala's equivalent of Java's List interface is the Seq. A more general interface exists as well, which is the GenSeq -- the main difference being that a GenSeq may have operations processed serially or in parallel, depending on the implementation.
Because Scala allows programmers to use Seq as a factory, they don't often bother with defining a particular implementation unless they care about it. When they do, they'll usually pick either Scala'sList or Vector. They are both immutable, and Vector has good indexed access performance. On the other hand, List does very well the operations it does well.

What Scala collection has characteristics similar to ArrayList?

That would be scala.collection.mutable.ArrayBuffer.

What's a good replacement for Array in Scala?

Well, the good news is, you can just use Array in Scala! In Java, Array is often avoided because of its general incompatibility with generics. It is a co-variant collection, whereas generics is invariant, it is mutable -- which makes it's co-variance a danger, it accepts primitives where generics don't, and it has a pretty limited set of methods.
In Scala, Array-- which is still the same Array as in Java -- is invariant, which makes most problems go away. Scala accepts AnyVal (the equivalent of primitives) as types for its "generics", even though it will do auto-boxing. And through the "enrich my library" pattern, ALL of Seqmethods are available to Array.
So, if you want a more powerful Array, just use an Array.

What about a collection that shrinks and grows?

The default methods available to all collections all produce new collections. For example, if you do this:
-- 


--
Then 
newCollection will be a new collection, while xs will still be the same as before this command. This is true no matter what firstCollection was: ArrayList, etc.
Naturally, this has a cost -- after all, you are producing a new collection. Scala's immutable collections are much better at handling this cost because they are persistent, but it depends on what operation is executed.
No collection can do much about filter, but a List has excellent performance on generating a new collection by prepending an element or removing the head -- the basic operations of a stack, as a matter of fact. Vector has good performance on a bunch of operations, but it only pays if the collection isn't small. For collections of, say, up to a hundred elements, the overall cost might exceed the gains.
So you can actually add or remove elements to an Array, and Scala will produce a new Array for you, but you'll pay the cost of a full copy when you do that.
Scala mutable collections add a few other methods. In particular, the collections that can increase or decrease size -- without producing a new collection -- implement the Growable and Shrinkabletraits. They don't guarantee good performance on these operations, though, but they'll point you to the collections you want to check out.


Comments

Popular posts from this blog

Always Use StringBuilder while concatenating Strings within loops

A common tendency of Java programmers is to always concatenate Strings using + operator. Which is actually very good, and simplifies the code by improves readability, since we would have to use StringBuilder.append(String), if the single + operator was not allowed. In fact if we look in byte code generate from such concatenation style, we will see a StringBuilder being used to perform the action. Check the JSL:    JLS Now , the point is, although this facility, you should not use the + operator in loop concatenation. Why? A new  StringBuilder  Object will be constructed at every single loop iteration (with initial value of str) and at the end of every iteration there will be concatenation with initial String (actually  StringBuilder  with initial value of  str ). So you need to create StringBuilder by yourself only when you work with String concatenation in loop. Let us procuce the evidence First, run this code, and see how long it takes to be executed: Now, bellow is th

Maven Tips... and Tricks

Maven, one of the central actors in the Java World, resposible for managing the building life-cycles of many projects, is full of little features, that sometimes we forget to explore. Let us go straight away and take a look at some very useful Maven features that will make your builds shine. From where it stopped Sometimes it is needed to build a bunch of projects all together, artifact-a , artifact-b and so on. What do we usually do when one of them fail? Build it all again! But not anymore: By using this option you can run the build from the project that failed. Two out of ten Ok, suppose you have 10 projects, and you only want to build 2 of them, how would you do? The option -pl will do the job Multi-threaded Build If in the machine you run the build you have many Cores, tou can take advantage of them by using the following option(it means 2 Threads per Core): It is also possible to define 3 Threads per Core(T3C) Skip your Tests when you want to With a lot of test