Java Generics and Type Safety

When I learned to code in Java, there was no such thing as generics to ensure type safety. Casting objects was part of the routine, and CastClassException was a familiar message. But Java now comes with Generics to help us avoid those runtime exceptions (when the application runs). Generics look like MyClass. Instead of having runtime exceptions, the compiler shows errors. Generics specify the type of what is within a container class (in this case MyClass). For example, we can define Cart to represent a cart of product from a shopping website.

Here are a few guidelines to use them:

1. Avoid using raw type. It is only there for backward compatibility. If necessary, use unbounded wildcards.

Cart cart; --> raw type: No!
Cart<?> cart; --> Unbounded wildcard type: Better!
Cart<E extends Item> --> Bounded type parameter: Better!
Cart<Item> cart; --> Generic: Better!

Wildcards are useful to ensure type safety even when the type is unknown. However, we cannot assume the type of object that we get out of our container… and we cannot put any element (other than null) into our container. If these restrictions are unacceptable, we can use generic methods or bounded wildcard types.

Cart<?> cart = Cart.empty();
cart.add(something); --> do not compile
Object something = cart.get(0); --> cannot assume the type of something

Unbounded wildcards are ok when nothing specific to the element type is used. For example, list.size() does need to know the type of objects in the list.

If for whatever reason, you use a raw type, a good practice is to test before with instanceof or isAssignedFrom.

2. Remove unchecked warning. If for whatever reason, you use raw types or cast such as:

Set<E> exaltation = new HashSet();
Set exaltation = new HashSet<>();

Add @SuppressWarnings(“unchecked”) on the smallest scope possible. For example, add the annotation on a method instead of a whole class. Otherwise, it will mask warnings you need to see. Also comment to explain why it is safe.

3. Use generic types – obviously – whether generic classes or methods. A static method can even be generic:

static <E> List<E> asList(E[] a)

However, a generic class cannot infer a static method, which means that:

class Cart<E extends Item> {
   public add(E item) {
     // E must extend Item because of the class declaration
     …
   }

   public static <E> List<E> asList(E[] a) {
     // E here does not depend from the class declaration.
     // the solution is: <E extends Item> static List<E> asList(E[] a)
     …
   }
}

4. Use bounded wildcard to add flexibility. Bounded wildcards look like: Iterable. It specifies the possible boundaries of the parameters. Let’s illustrate this. We want to create a Cart class:

public class Cart<E> {
   public Cart();
   public void add(E e);
   public E pop();
   public boolean isEmpty();
   public void addAll(Iterable<E> src) {
      for (E e : src)
         add(e);
      }
   }
}

Cart<Item> cart = new Cart<>();
Iterable<Fruit> fruits = … ; // Fruit extends Item
cart.addAll(fruits); // Won't work because Iterable<Fruit> cannot be converted to Iterable<Item>

The solution is:

public void addAll(Iterable<? extends E> src)

Use wildcard types on input parameters. Avoid bounded wildcard types as return types. Instead of providing flexibility, it would force you to use wildcard types in client code. You should not need to think about wildcards in the client code. If you have to return a wildcard, remember: Wildcards means “anything” so treat it that way. It implies you do not need to know what is manipulated. For example:

Cart<?> getCart();

It may be ok if what you do is simply call methods on the Cart object that can be type agnostic, such as getting the total sum of the cart:

Cart<?> cart = getCart();
double sum = cart.getSum(); // does not depend on the type of product in the cart

if a type parameter appears only once in a method declaration, replace it with a wildcard. If it’s an unbounded type parameter, replace it with an unbounded wildcard; if it’s a bounded type parameter, replace it with a bounded wildcard.

Generics are great, but it can quickly get messy with polymorphism… but this is for another post.

Constructors vs Static Factory Method

I have wondered if this topic was relevant. I have often seen both ways to create an object. Why bother choosing between a static factory method and a constructor? It seemed to me that they do more or less the same, and the advantages of the static factor method were not so obvious. Why not using the constructor to do what it was invented for: constructing objects?! The choice did and still does feel a bit artsy (=preference). But let me list a few pros for the static method, and you may change your mind.

Advantage #1: name it!

How the heck is this more advantageous? Well, clarity. You can name your static method in a way that means what it is doing. For example, if you want to build a new garden, you can write:

Salad salad = Salad.from(lettuce);

instead of

Salad garden = new Salad(lettuce);

Hmm?? Was it better? Ok, fine. Not that much. But if you need arguments to create your object, you may have factor methods with different names. It can be particularly useful when the parameters are of the same type. For example, I want to make a salad:

public Salad(Green lettuce, Green spinach) {
// do something
}

Now if I want to make a salad with a different mix of green assuming it requires a different behavior, it will look like:

public Salad(Green lettuce, Green roman) {
// do something else
}

The signature is the same. Of course, we could figure out something else. If we have static methods, it will look more elegant:

Salad salad = Garden.makeDarkGreenMix(lettuce, spinach);
Salad salad = Garden.makeLightGreenMix(lettuce, roman);

Well, this example was not very elegant…

Advantage #2: save resources!

A static factory method does not have to create an object. The common example is the getInstance() method Java developers often use to create Singletons.

public static SaladChef getInstance() {
  if (chef == null) { // chef = private SaladChef property
    chef = new SaladChef();
  }
  return chef;
}

Another example would be a pool of connections. etc. It might help to avoid using resources.

Advantage #3: return a subclass!

A static method can return a subclass, but not the constructor. It may help to manage the types of objects return depending on the parameters.

public static Macbook buy(double amount) {
  if (amount < 1000) {
    return new MackbookAir();
  } else {
    return new MacbookPro();
  }
}

But there are two cons: classes without public or protected constructors cannot be inherited, and static factory methods are harder to find than constructors.

Honestly, I still question the systematic use of static factory methods. It is a nice way to code, but it must be used with caution. And I think it is still a matter of art.

Mockk framework: Could not initialize class io.mockk.impl.JvmMockKGateway

If you are looking for a mock framework for Kotlin tests, Mockk is definitely on first on the list. I wrote my first test following a simple example on the official website (https://mockk.io/#dsl-examples). In my case, I am testing an export class using a parser to deserialize a file into an object:

@Test
fun `test export excluding sub-folders`() {
    // given
    val path = "my/new/path"
    val parser = mockk()
    every { parser.buildObject("$path/data.xml") } returns MyObject("first name", "last name", "title", "manager")

    // when
    var myObject = exporter.parse(
            parser,
            getResourceFile(path),
            mutableListOf()
        )

    // then
    verify { parser.buildObject("$path/data.xml") }
    confirmVerified(parser) // verifies all the verify calls were made
    assertEquals("first name", myObject.firstName)
    assertEquals("last name", myObject.lastName)
    assertEquals("title", myObject.title)
    assertEquals("manager", myObject.manager)

}

Wunderbar! I ran my test… and it failed:

java.lang.NoClassDefFoundError: Could not initialize class io.mockk.impl.JvmMockKGateway

What in the world is that?! I checked my pom file and verified I had the latest version:

<dependency>
  <groupId>io.mockk</groupId>
  <artifactId>mockk</artifactId>
  <version>1.9.3</version>
  <scope>test</scope>
</dependency>

After a while, I figured out the issue resides in the IDE (https://github.com/mockk/mockk/issues/254). Mockk has issue when running on JDK 11. I went to Intellij IDEA -> File -> Project Structure, and changed the Project SDK to JDK 8 (which I use for my current project). You can probably find another version that would work for your own project.

Browsing folders with Kotlin

Kotlin offers significant improvements to Java. But coming from a Java background, it can sometimes get tricky. I was looking at browsing folders and I found Kotlin’s method walkTopDown:

fun File.walkTopDown(): FileTreeWalk

I used it recursively to find pom.xml files.

fun findPomFiles(
        folder: File,
        pomTrees: MutableList,
        includeDependencyManagement: Boolean,
        searchSubFolders: Boolean
    ): MutableList {

        // find pom file in the current folder
        val pomFile = folder.listFiles().find { it.name == "pom.xml" }

        pomFile?.let {
            println("Found pom file in $folder")
            pomTrees.add(PomNode(pomParser.deserialize(it), includeDependencyManagement))
        }

        if (searchSubFolders) {
            folder.walkTopDown() // HERE IS THE METHOD
                .filter { it.isDirectory && it != folder && it.name != "target" && it.name != "src"} // ignore src and target folders for performance
                .forEach {
                    findPomFiles(it, pomTrees, includeDependencyManagement, searchSubFolders)
                }
        }

        return pomTrees
    }

I also found the function onEnter of FileTreeWalk that can be used to avoid exploring useless branches.

fun onEnter(function: (File) -> Boolean): FileTreeWalk

folder.walkTopDown() // HERE IS THE METHOD
    .onEnter { it.name != "target" && it.name != "src"}

However, the result was not what I expected. The program was looking at the folders multiple times. I realize walkTopDown is not made for exploring folders recursively.
What it actually does is to browse folders and for each folder, we can do whatever we need to.

So two possibilities:

A. keeping the code recursive and using listFiles() from File – like we used to do it in Java

    if (searchSubFolders) {
        folder.listFiles()
            .filter { it.isDirectory && it != folder && it.name != "target" && it.name != "src"} // ignore src and target folders for performance
            .forEach {
                findPomFiles(it, pomTrees, includeDependencyManagement, searchSubFolders)
            }
    }

B. using walkTopDown

fun findPomFiles(
        folder: File,
        pomTrees: MutableList,
        includeDependencyManagement: Boolean,
        searchSubFolders: Boolean
    ): MutableList {

        // find pom file in the current folder
        addPomNode(folder, includeDependencyManagement)?.let { pomTrees.add(it) }

        if (searchSubFolders) {
            folder.walkTopDown()
                .onEnter { it.name != "target" && it.name != "src" }
                .forEach {
                    addPomNode(it, includeDependencyManagement)?.let { pomNode -> pomTrees.add(pomNode) }
                }
        }

        return pomTrees
    }

    fun addPomNode(folder: File, includeDependencyManagement: Boolean): PomNode? {
        val pomFile = folder.listFiles()?.find { it.name == "pom.xml" }

        pomFile?.let {
            println("Found pom file in $folder")
            return PomNode(pomParser.deserialize(it), includeDependencyManagement)
        }

        return null
    }