Skip to main content

A Generic class – And why is it confusing


Go to start of metadata

Generics came into java from Java 5 and has changed the way we use Collections. You now find people using and building generic classes more and more. For those who don’t know what generics is, please read the below link:

My gripe with generics is not with generics itself, but the convention of using placeholders as single letters like this:
public class HashMap<K,V> implements Map<K,V>{}
With collections, since we have been using these classes before generics came in we know that K represents the key and V represents the value. Now imagine you have class such as below:
public abstract class SwingWorker<T, V> implements RunnableFuture<T> {}

Now without having a look at the gory innards of SwingWorker would you be able to reliably interpret what T and V actually mean? Once you go through the class you will understand that T actually represents the return type of the doInBackground() method and V represent the type of the class that you can use to show intermediate results on the screen.
This, people can argue can be obtained out of the java docs as well. Well now everyone knows that java docs go quickly out of date in any project and the only source of truth remains your code. People who read the java doc would go through the code anyway to understand how to use the class. And all of this just to understand what T and V represents. When we are all for descriptive method, field and class names why cryptic placeholder values?

The java tutorial on generics state that the convention is because if we use a descriptive placeholder name we might confuse them with class names. I find that a little hard to take in. What if you use the $.. like this:

public abstract class SwingWorker<$ReturnValue, $IntermediateResult> implements RunnableFuture<$ReturnValue> {}
public class HashMap<$Key,$Value> implements Map<$Key,$Value>{}

Now it becomes instantly clear to me how these generic types are used within that class and what I need to pass into the class declaration. No one names their classes starting with a $ sign. In fact in most templating languages, velocity, struts, spring using the dollar sign to signify a placeholder. Why can’t we do the same? I for one am going to start and will seek to turn other people as well to start using descriptive placeholders in generic classes.

Comments

Popular posts from this blog

JUnit – Run unit test in an Sequence / Order

In JUnit, we can use @FixMethodOrder(MethodSorters.xxx) to run the test methods in a sequence or order.

import org.junit.FixMethodOrder;import org.junit.Test;import org.junit.runners.MethodSorters;importstatic org.hamcrest.CoreMatchers.is;importstatic org.junit.Assert.assertThat;//Sorts by method name@FixMethodOrder(MethodSorters.NAME_ASCENDING)publicclassExecutionOrderTest{@TestpublicvoidtestB(){assertThat(1+1,is(2));}@Testpublicvoidtest1(){assertThat(1+1,is(2));}@TestpublicvoidtestA

Create Runnable Jar - Eclipse Options

When exporting to a Runnable Jar, there are three options in eclipse Helios. Extract required libraries into JARPackage required libraries into JARCopy required libraries into sub folder next to JAR. What are differences : Extract required libraries into JAR - Extracts the actual .class files from the libraries your app uses and puts those .class files inside the runnable JAR. So, the runnable JAR will not only contain the .class files of your application, but also the .class files of all the libraries your application uses. Package required libraries into JAR - Puts the actual JAR files of the libraries into your runnable JAR. Normally, a JAR file within a JAR file cannot be loaded by the JVM. But Eclipse adds special classes to the runnable JAR to make this possible. Copy required libraries into sub folder next to JAR - Keeps the library JARs completely separate from the runnable JAR, so the runnable JAR will only contain the .class files of your application. Option #2 is convenient be…