GENERICS
========
Suppose you're using a list of Objects to store Strings.  When you fetch a
String from the list, you have to cast it back to type "String" before you can
call the methods exclusive to Strings.  If somehow an object that's not a
String got into your list, the cast will throw an exception.  It would be nice
to have the compiler enforce the restriction that nothing but Strings can ever
get into your list in the first place, so you can sleep at night knowing that
your family is safe from a ClassCastException.

So Java offers _generics_, which allow you to declare general classes that
produce specialized objects.  For example, you can create an SList for Strings
only, and another SList for Integers only, even though you only wrote one
SList class.  To specify the class, SList takes a _type_parameter_.

class SListNode<T> {                         // T is the formal parameter.
  T item;
  SListNode<T> next;

  SListNode(T i, SListNode<T> n) {
    item = i;
    next = n;
  }
}

public class SList<T> {
  SListNode<T> head;

  public void insertFront(T item) {
    head = new SListNode<T>(item, head);
  }
}

You can now create and use an SList of Strings as follows.

  SList<String> l = new SList<String>();     // String is the actual parameter.
  l.insertFront("Hello");

Likewise, you can create an SList of Integers by using "SList<Integer>" in the
declaration and constructor.

What are the advantages of generics?  First, the compiler will ensure at
compile-time that nothing but Strings can ever enter your SList<String>.
Second, you don't have to cast the Objects coming out of your SList back to
Strings, so there is no chance of an unexpected ClassCastException at run time.
If some bug in your program is trying to put Integer objects into your SList,
it's much easier to diagnose the compiler refusing to put an Integer into an
SList<String> than it is to diagnose a ClassCastException occurring when you
remove an Integer from a regular SList and try to cast it to String.

Generics are a complicated subject.  Consider this to be a taste of them;
hardly a thorough treatment.  A good tutorial is available at
https://www.seas.upenn.edu/~cis1xx/resources/generics-tutorial.pdf .

Although Java generics are superficially similar to C++ templates, there's a
crucial difference between them.  In the example above, Java compiles bytecode
for only a single SList class.  This SList bytecode can be used by all
different object types.  It is the compiler, not the bytecode itself, that
enforces the fact that a particular SList object can only store objects of a
particular class.  Conversely, C++ recompiles the SList methods for every type
that you instantiate SLists on.  The C++ disadvantage is that one class might
turn into a lot of machine code.  The C++ advantages are that you can use
primitive types, and you get code optimized for each type.  Java generics don't
work with primitive types.