If you are new to Scala, we recommend that you carefully follow this REPL session as it will give you a lot of useful knowledge for programming with Scala.
Let's dive into some of the most apparent differences between Java and Scala in order to get acquainted with the Scala syntax.
Declaring val/var variables
In Java, you would declare a new variable by putting in order its type, followed by the name, and then the optional value:
In Scala, the order of declaring the variable name and type is inverted, with the name appearing before its type. Let's enter the following line into the REPL:
Inverting the order of declaring the variables, type, and name as compared to Java might at first seem a strange idea if you want to make it as easy as possible for a Java developer to grab the Scala syntax. However, it makes sense for several reasons:
The Scala compiler, in this case, is able to deduct the type automatically. You could (and probably should, for conciseness) omit this type by entering the equivalent but shorter line of code instead:
This is the most basic illustration of what is called Type Inference, and you will see that the Scala compiler will try to deduct types whenever it can. If we had omitted this optional type but followed the Java syntax, the parsing done by the compiler would have been more difficult to implement.
In our opinion, it is more important to know a variable name than its type in order to understand the flow of a program (and therefore make it appear first); for instance, if you deal with a variable representing a social security number (ssn), we think the term ssn is more valuable than knowing if it is represented as a string or an integer or any other type.
You probably noticed the val
variable in front of the declaration; it means that we explicitly declare the variable as immutable. We can try to modify it as shown in the following code snippet:
The preceding code will not only give you a clear explanation of what was wrong but also the exact place where the parser did not agree (notice the ^
character precisely showing where the error lies in the line).
If we want to create a mutable variable instead, we should declare it with var
as shown in the following code snippet:
In summary, you cannot change yourPast
but you can change yourFuture
!
The semicolon at the end of the lines is optional in Scala; a small but pleasant feature of the language.
Let's move on to an important difference. In Java, you have primitive types such as int
, char
, or boolean
(eight in total), as well as operators to manipulate data such as +
or >
. In Scala, there are only classes and objects, making Scala more "object-oriented" than Java in some way. For instance, enter the following value into the REPL:
By default, the compiler created an immutable Int
(integer) variable with the res1
name (that is, result 1) in case you need to reuse it later on.
Now, enter the following line in REPL:
The preceding code resembles the usage of an operator (as in Java) but is in fact the invocation of a method named +
called on object 3
with the input parameter 2
, equivalent to the slightly less clear statement:
Syntactic sugar (that is, syntax designed to make things easier to read or express) was added here by removing the necessity to specify the parenthesis. This also means that we can now implement similar methods on our own defined types to express code elegantly. For example, we can express the addition of two Money
objects of different currencies (note that the Money
type does not exist in the default Scala library) by simply stating Money(10,"EUR") + Money(15,"USD")
. Let's try to do that in the REPL.
First, we can define a new class Money
that has a constructor parameter named amount
of type Int
as follows:
Note
Scala has a special syntax for declaring constructor parameters that will be explored in more depth later.
Now, we can create a Money
instance as shown in the following code snippet:
You get back an object with its displayed reference. The REPL provides you with TAB completion, so type notMuch.
and hit the Tab key:
By using the preceding autocompletion, you will get suggestions of the available methods for that class, as you will get with most Java IDEs.
As shown previously, you can construct new instances of Money
by invoking the constructor, but you do not have access to the amount
variable since it is not a field. To make it a field of the Money
class, you have to add a 'val
' or 'var
' declaration in front of it, as shown in the following code snippet:
This time, instead of again typing the line that created an instance, we will use the up arrow (the shortcut to display previous expressions: the history of the console) and navigate to it:
Note
The Tab key can be pressed at any time in the REPL and provides autocompletion.
Invoking autocompletion on this new instance will display the following:
So, we can simply read the value of the getter for this amount
field by referring to it:
Similarly, if we had declared the amount to be a var
variable instead of val
, we would also have access to the setter
method:
The setter
method is invoked when we use the following code snippet:
As Java developers, we are accustomed to the JavaBean style domain classes that not only include fields with getters and setters but also constructors as well as hashCode
, equals
, and toString
methods, as shown in the following code snippet:
Achieving this in Scala is very straightforward and only requires the addition of the case
word in front of the class declaration:
We have just defined a class Money
with two immutable fields named amount
and currency
with default values.
Without going too much into the details of the case
classes, we can say that in addition to the preceding features of a traditional JavaBean style domain class, they have a powerful mechanism for pattern matching. The case
word is analogous to the switch
statement in Java, though it is more flexible, as we will see later on. The case
classes contain additional features among which one is a factory method to create instances (no need to use the new
keyword to create one).
By default, the fields declared in Scala classes are public, unlike Java, where they have a package-private scope, defined between private and protected. We could have written case class Money(private val amount: Int, private val currency: String)
to make them private instead, or used var
instead of val
to make the fields mutable.
The shortest way to create an instance of Money
is very straightforward:
In the previous instance declaration, since only one parameter is given instead of two, the compiler matched it against the first declared field, that is, amount
. Since the value 15
is of the same type as amount
(that is, Integer
), the compiler was able to populate the instance with this amount, using the default value "USD"
as the currency.
Unlike the amount
variable, invoking the Money
constructor with the sole currency parameter will fail, as seen in the following statement:
The preceding code does not work because the compiler could not guess which parameter we were referring to, and therefore tried to match them in order of declaration. To be able to use the default value for amount
with the given "EUR"
string, we need to include the parameter name explicitly, as shown in the following code snippet:
We could therefore also mark all parameters explicitly, which can be recommended when there are many parameters as shown in the following code snippet:
An additional useful method when constructing instances is the copy
method, which creates a new instance out of the original and eventually replaces given parameters:
We can use the copy
method with explicitly named parameters, as follows:
The copy
method can be very useful when writing test fixtures, in particular, when the mockup instances to be initialized have constructors with many fields that are similar.
Let's move on by creating an addition
operation of our Money
class. For simplicity, we will pretend for a moment that we only deal with amounts of the same currency, the default USD.
In Java, we would probably add such a method with the following signature and simple content:
In Scala, we use the def
keyword to define a class method or a function. In the REPL, we can have multiline expressions. The following case
class declaration, containing the implementation of a summing method +
is an example of such features:
Notice that we can use +
as a method name. We have also included the return type Money
in the signature declaration, which is only optional since the type inference of Scala will deduct it, but including it explicitly is a good documentation practice for public methods (and methods are public by default if no other scope is specified). Moreover, in Scala, since the return
word at the end of the method is optional, the last statement is always the one that is returned to the caller of the method. Furthermore, it is generally considered a good practice to omit the return
keyword since it is not mandatory.
We can now write the addition of two Money
instances with the following simple expression:
Things start becoming exciting once we start manipulating collections of objects, and the functional programming part of Scala helps very much for that matter. Since generics are part of the language (Java 5 onwards), Java can, for example, iterate over a list of integers by writing the following code snippet:
The preceding code produces the following output:
In Scala, the declaration of a list can be written as follows:
Scala collections systematically distinguish between immutable and mutable collections, but encourage immutability by constructing immutable collections by default. They simulate additions, updates, or removals by returning new collections from such operations instead of modifying them.
One way to print out the numbers is that we can follow Java's imperative style of programming and iterate over the collection by creating a for
loop:
Another way to write the code in Scala (as well as many other languages on the JVM, such as Groovy, JRuby, or Jython) involves a more functional style, using lambda expressions (sometimes referred to as closures). In brief, lambdas are just functions that you can pass around as parameters. These functions take input parameters (in our case, the n
integer) and return the last statement/line of their body. They are in the following form:
A typical example of lambda to iterate over the elements of the numbers
list we have defined earlier, is given as follows:
In that case, the body consists of only one statement (println...
), and therefore returns Unit
, that is, an empty result roughly equivalent to void
in Java, except that void
does not return anything.
As the time of writing this book, lambda expressions in Java are around the corner and will be introduced very soon as part of the JDK8 release, adopting a Scala-like style. Some of the functional constructs will therefore soon be available to Java developers.
It should become possible to write our tiny example in the following way:
As we stated previously, Scala collections are, by default, immutable. This is a very important aspect for making them behave as expected when dealing with multiprocessor architectures. One unique feature of the Scala collections compared to Java is that they include support for running operations in parallel.