What Scala adds to Java is a stronger type system, including generics that can span several levels, which means that you can have a generic of generics, and so on.

We won't cover the Scala type system here as it would take the rest of the book to get the gist of it, but we'll take an overview of what is often needed in templates when declaring the arguments they can take.

The two major differences between the Java syntax and the Scala syntax are as follows:

Let's see some examples:

Let's review the examples to figure out where the differences are and how Scala can offer more.

The first example is quite easy to get. We define a list that cannot be empty. For this purpose, we just defined a type that is instantiated using an element and a list. Of course, the list can be composed of anything of the same type; that's why it declares a generic G.

As we can see, the only difference (except the concision of Scala using case class) is the syntax used for declaring the generic.

The second example defines a type that can output adapted elements. The output W will be written with a version of the element s which W knows how to serialize—thanks to the adapt method.

The adapt method shows how to declare several bounded generics that are allowed using the inherited methods. Here again the syntax is the only difference; we used <: in Scala rather than extends which we used in Java. If we pay more attention to the type declaration, we will notice that the trait keyword appears in Scala whereas interface and abstract class were used in the Java code. A trait can be thought of as the conceptual union of an interface with an abstract class because they can be mixed together (like interfaces) and can define implementation (like abstract classes), but they cannot be instantiated (like interfaces and abstract classes).

The last example shows the limit of the Java type system. In Java, we started by defining Function1, which is just a "classic command" that accepts one parameter, that has both the parameter's and the result's types as generics.

This wasn't necessary in Scala because functions are first-class citizens (a function can be treated as an object). So what we can do out of the box is to declare a parameter as being a function such as A=>B, which means that a function taking one parameter of type A will result in a value of type B. So, a function in Scala can be passed to other functions because they are "thinkable" as variables.

Then, we tried to define a high-order type called Functor. In short, it means a functor should use generics such as Functor<F<?>> that are generics themselves. Two things that Java doesn't like, the first being the interrogation point which is not permitted at this depth (second generic level). The second thing is the real problem and is the fact that Java doesn't support embedded generics at all. Even if the fmap method is syntactically correct, we cannot use it efficiently because the F type cannot be declared correctly.

Switching to the Scala code now, we declared Functor[F[_]] that compiles perfectly. The _ is present in the definition of F because, at this level, we don't care what the inner type of F is; we just need to assert that F has a generic.