Thursday, 20 October 2016

Potential heap pollution via varargs parameter

Reifiable versus Non-Reifiable

Type erasure is an important "feature" of Generics in Java. It means generics are not available at runtime, as they are effectively removed during compiling.

The reference in [1] has a much better explanation.

To quote:
“A reifiable type is a type whose type information is fully available at runtime.”
“Non-reifiable types are types where information has been removed at compile-time by type erasure.”

Generics versus Arrays

In Java, generics are non-reifiable and arrays are reifiable.

Problems can occur when we combine these two together.

Combining these two together can happen when using the varargs construction in Java.

The reason for this is that the varargs way of using method parameters is translated within the method as a array.

This can cause Heap pollution2 when combined with Generics.

As the compiler doesn't know when this happens (it depends on how the method deals with it), it throws out the warning.

Hence the need for the @SafeVarargs3 annotation for those methods where the software designers are certain the problem does not occur.


[1] Non-Reifiable Types
[2] @SafeVarargs
[3] Oracle JavaDoc - SafeVarargs
StackOverflow - Potential heap pollution via varargs parameter

Thursday, 13 October 2016

The Joel Test

I found a link regarding a job opportunity at a Banking establishment1. (I don't know how long that link is going to stay current, sorry about that.)

They included a little list of the software practices that they follow. Apparently it is called the "Joel Test"2.

So I thought I'd mention it here, for those interested about comparing companies.


[1] StackOverflow - Mid-Level Java Developer at Leading Sustainable Bank
[1] The Joel Test: 12 Steps to Better Code by Joel Spolsky