Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Taming Tiger, Part 2

Understanding generics

By Tarak Modi, JavaWorld.com, 06/07/04

Welcome to the second part of this three-part series on Sun Microsystems' latest release of the Java 2 Platform, Standard Edition (J2SE). To refresh your memory, Part 1 was a quick introduction to J2SE 1.5 and covered many new additions to the Java language: auto-boxing and -unboxing of primitives, enumerations, static imports, the enhanced "for" loop, variable method arguments, and the newly formatted input method. I devote Part 2 entirely to generics, Java's counterpart to templates in C++ and a similar facility (also called generics) in C# 2.0.

Read the whole series: "Taming Tiger," Tarak Modi (JavaWorld):

• Part 1: An introduction to Java 1.5
• Part 2: Understanding generics
• Part 3: Decorate your code with Java annotations

Why generics?

To understand the problem that generics (short for generic types) solve, let's look at the following code fragment:

// Declare Class A
class A
{
}
// Declare Class B
class B
{
}
// Somewhere in the program create a Vector 
Vector v = new Vector();
// Add an object of type A
v.add(new A());
// And sometime later get the object back
B b = (B) v.get(0);

The above code will compile fine but will throw a runtime exception (java.lang.ClassCastException) when you execute it. This is obviously a serious problem and should be caught as early as possible. Preferably, the above code fragment should not even compile.

Enter Java generics

Now, let's rewrite the above code fragment using generics:

// Class A and B declared previously
// Somewhere in the program create a Vector 
Vector<A> v = new Vector<A>();
// Add an object of type A
v.add(new A());
// And sometime later get the object back
B b = (B) v.get(0);

That looks similar to the first fragment, except for the code in the angle brackets. The angle brackets are the syntax for providing type parameters to parameterized types. I talk more about both parameterized types and type parameters in this article's later sections.

Even though the code change is minimal, its impact is far from small. This code fragment will not compile. Compiling this program with J2SE 1.5 (remember to use -source 1.5) will give you the following error:

inconvertible types
found   : A
required: B
        B b = (B) v.get(0);

In plain English, the compiler tells us that to be able to use the line B b = (B) v.get(0); legally, the vector must be parameterized (in the declaration) to accept objects of type B.

Diving into generics

Generics were first proposed for Java in early 2001, and (after three long years) they have finally made their way into J2SE 1.5. As you saw above, generics provide a giant leap into solving a long-standing problem in Java; implementing compile-time type safety. One of the first places you will encounter generics in J2SE 1.5 (and in C++ and C#) are in the collection classes, such as the Vector class we used above. Such classes are called parameterized types. If a type is parameterized, then its declaration (i.e., when you declare an instance of that type) can optionally take a type with which to parameterize it. For example, we already know that Vector is a parameterized type, and hence, the declaration of v (in the example above) is as follows: