It is easy to use a generic class such as ArrayList. Most Java programmers will simply use types such as ArrayList<String> as if they had been built into the language, just like String[] arrays. (Of course, array lists are better than arrays because they can expand automatically.)

However, it is not so easy to implement a generic class. The programmers who use your code will want to plug in all sorts of classes for your type parameters. They expect everything to work without onerous restrictions and confusing error messages. Your job as a generic programmer, therefore, is to anticipate all the potential future uses of your class.

How hard can this get? Here is a typical issue that the designers of the standard class library had to grapple with. The ArrayList class has a method addAll to add all elements of another collection. A programmer may want to add all elements from an ArrayList<Manager> to an ArrayList<Employee>. But, of course, doing it the other way around should not be legal. How do you allow one call and disallow the other? The Java language designers invented an ingenious new concept, the wildcard type, to solve this problem. Wildcard types are rather abstract, but they allow a library builder to make methods as flexible as possible.

Generic programming falls into three skill levels. At a basic level, you just use generic classes—typically, collections such as ArrayList—without thinking how and why they work. Most application programmers will want to stay at that level until something goes wrong. You may encounter a confusing error message when mixing different generic classes, or when interfacing with legacy code that knows nothing about type parameters. At that point, you need to learn enough about Java generics to solve problems systematically rather than through random tinkering. Finally, of course, you may want to implement your own generic classes and methods.

Application programmers probably won’t write lots of generic code. The folks at Sun have already done the heavy lifting and supplied type parameters for all the collection classes. As a rule of thumb, only code that traditionally involved lots of casts from very general types (such as Object or the Comparable interface) will benefit from using type parameters.

In this chapter, we tell you everything you need to know to implement your own generic code. However, we expect most readers to use this knowledge primarily for help with troubleshooting, and to satisfy their curiosity about the inner workings of the parameterized collection classes.

When you program a call to a generic method, the compiler inserts casts when the return type has been erased. For example, consider the sequence of statements

Pair<Employee> buddies = . . .;
Employee buddy = buddies.getFirst();

The erasure of getFirst has return type Object. The compiler automatically inserts the cast to Employee. That is, the compiler translates the method call into two virtual machine instructions:

Casts are also inserted when you access a generic field. Suppose the first and second fields of the Pair class were public. (Not a good programming style, perhaps, but it is legal Java.) Then the expression

Employee buddy = buddies.first;

also has a cast inserted in the resulting byte codes.

Type erasure also happens for generic methods. Programmers usually think of a generic method such as

public static <T extends Comparable> T min(T[] a)

as a whole family of methods, but after erasure, only a single method is left:

public static Comparable min(Comparable[] a)

Note that the type parameter T has been erased, leaving only its bounding type Comparable.

Erasure of method brings up a couple of complexities. Consider this example:

class DateInterval extends Pair<Date>
{
   public void setSecond(Date second)
   {
      if (second.compareTo(getFirst()) >= 0)
         super.setSecond(second);
   }
   . . .
}

A date interval is a pair of Date objects, and we’ll want to override the methods to ensure that the second value is never smaller than the first. This class is erased to

class DateInterval extends Pair // after erasure
{
   public void setSecond(Date second) { . . . }
   . . .
}

Perhaps surprisingly, there is another setSecond method, inherited from Pair, namely,

public void setSecond(Object second)

This is clearly a different method because it has a parameter of a different type—Object instead of Date. But it shouldn’t be different. Consider this sequence of statements:

DateInterval interval = new DateInterval(. . .);
Pair<Date> pair = interval; // OK--assignment to superclass
pair.setSecond(aDate);

Our expectation is that the call to setSecond is polymorphic and that the appropriate method is called. Because pair refers to a DateInterval object, that should be DateInterval.setSecond. The problem is that the type erasure interferes with polymorphism. To fix this problem, the compiler generates a bridge method in the DateInterval class:

public void setSecond(Object second) { setSecond((Date) second); }

To see why this works, let us carefully follow the execution of the statement

pair.setSecond(aDate)

The variable pair has declared type Pair<Date>, and that type only has a single method called setSecond, namely setSecond(Object). The virtual machine calls that method on the object to which pair refers. That object is of type DateInterval. Therefore, the method DateInterval.setSecond(Object) is called. That method is the synthesized bridge method. It calls DateInterval.setSecond(Date), which is what we want.

Bridge methods can get even stranger. Suppose the DateInterval method also overrides the getSecond method:

class DateInterval extends Pair<Date>
{
   public Date getSecond() { return (Date) super.getSecond().clone(); }
   . . .
}

In the erased type, there are two getSecond methods:

Date getSecond() // defined in DateInterval
Object getSecond() // defined in Pair

You could not write Java code like that—it would be illegal to have two methods with the same parameter types—here, no parameters. However, in the virtual machine, the parameter types and the return type specify a method. Therefore, the compiler can produce bytecodes for two methods that differ only in their return type, and the virtual machine will handle this situation correctly.

Note

Bridge methods are not limited to generic types. We already noted in Chapter 5 that, starting with JDK 5.0, it is legal for a method to specify a more restrictive return type when overriding another method. For example,

public class Employee implements Cloneable
{
   public Employee clone() throws CloneNotSupportedException { ... }
}

The Object.clone and Employee.clone methods are said to have covariant return types.

Actually, the Employee class has two clone methods:

Employee clone() // defined above
Object clone() // synthesized bridge method, overrides Object.clone

The synthesized bridge method calls the newly defined method.

In summary, you need to remember these facts about translation of Java generics:

Lots of Java code was written before JDK 5.0. If generic classes could not interoperate with that code, they would probably not be widely used. Fortunately, it is straightforward to use generic classes together with their raw equivalents in legacy APIs.

Let us look at a concrete example. To set the labels of a JSlider, you use the method

void setLabelTable(Dictionary table)

In Chapter 9, we used the following code to populate the label table:

Dictionary<Integer, Component> labelTable = new Hashtable<Integer, Component>();
labelTable.put(0, new JLabel(new ImageIcon("nine.gif")));
labelTable.put(20, new JLabel(new ImageIcon("ten.gif")));
. . .
slider.setLabelTable(labelTable); // WARNING

Note

The Hashtable class is a concrete subclass of the abstract Dictionary class. Both Dictionary and Hashtable have been declared as “obsolete” ever since they were superseded by the Map interface and the HashMap class of JDK 1.2. Apparently though, they are still alive and kicking. After all, the JSlider class was only added in JDK 1.3. Didn’t its programmers know about the Map class by then? Does this make you hopeful that they are going to adopt generics in the near future? Well, that’s the way it goes with legacy code.

In JDK 5.0, the Dictionary and Hashtable classes were turned into a generic class. Therefore, we are able to form Dictionary<Integer, Component> instead of using a raw Dictionary. However, when you pass the Dictionary<Integer, Component> object to setLabelTable, the compiler issues a warning.

Dictionary<Integer, Components> labelTable = . . .;
slider.setLabelTable(labelTable); // WARNING

After all, the compiler has no assurance about what the setLabelTable might do to the Dictionary object. That method might replace all the keys with strings. That breaks the guarantee that the keys have type Integer, and future operations may cause bad cast exceptions.

There isn’t much you can do with this warning, except ponder it and ask what the JSlider is likely going to do with this Dictionary object. In our case, it is pretty clear that the JSlider only reads the information, so we can ignore the warning.

Now consider the opposite case, in which you get an object of a raw type from a legacy class. You can assign it to a parameterized type variable, but of course you will get a warning. For example,

Dictionary<Integer, Components> labelTable = slider.getLabelTable(); // WARNING

That’s ok—review the warning and make sure that the label table really contains Integer and Component objects. Of course, there never is an absolute guarantee. A malicious coder might have installed a different Dictionary in the slider. But again, the situation is no worse than it was before JDK 5.0. In the worst case, your program will throw an exception.

It is unfortunate that you can’t turn off the warnings after you reviewed them. It seems impractical to review every warning every time you recompile a source file. The Java language designers are planning to add a more flexible warning mechanism to a future version of the JDK.

You cannot substitute a primitive type for a type parameter. Thus, there is no Pair<double>, only Pair<Double>. The reason is, of course, type erasure. After erasure, the Pair class has fields of type Object, and you can’t use them to store double values.

This is an annoyance, to be sure, but it is consistent with the separate status of primitive types in the Java language. It is not a fatal flaw—there are only eight primitive types, and you can always handle them with separate classes and methods when wrapper types are not an acceptable substitute.

Objects in the virtual machine always have a specific nongeneric type. Therefore, all type inquiries yield only the raw type. For example,

if (a instanceof Pair<String>) // same as a instanceof Pair

really only tests whether a is a Pair of any type. The same is true for the test

if (a instanceof Pair<T>) // T is ignored

or the cast

Pair<String> p = (Pair<String>) a; // WARNING--can only test that a is a Pair

To remind you of the risk, you will get a compiler warning whenever you use instanceof or cast expressions that involve generic types.

In the same spirit, the getClass method always returns the raw type. For example,

Pair<String> stringPair = . . .;
Pair<Employee> employeePair = . . .;
if (stringPair.getClass() == employeePair.getClass()) // they are equal

The comparison yields true because both calls to getClass return Pair.class.

You can neither throw nor catch objects of a generic class. In fact, it is not even legal for a generic class to extend Throwable. For example, the following definition will not compile:

public class Problem<T> extends Exception { /* . . . */ } // ERROR--can't extend Throwable

You cannot use a type variable in a catch clause. For example, the following method will not compile:

However, it is ok to use type variables in exception specifications. The following method is legal:

You cannot declare arrays of parameterized types, such as

Pair<String>[] table = new Pair<String>(10); // ERROR

What’s wrong with that? After erasure, the type of table is Pair[]. You can convert it to Object[]:

Object[] objarray = table;

We discussed in Chapter 5 that an array remembers its component type and throws an ArrayStoreException if you try to store an element of the wrong type:

objarray[0] = "Hello"; // ERROR--component type is Pair

But erasure renders this mechanism ineffective for generic types. The assignment

objarray[0] = new Pair<Employee>();

would pass the array store check but still result in a type error. For this reason, arrays of parameterized types are outlawed.

Tip

If you need to collect parameterized type objects, simply use an ArrayList: ArrayList<Pair<String>> is safe and effective.

You cannot instantiate generic types. For example, the following Pair<T> constructor is illegal:

public Pair() { first = new T(); second = new T(); } // ERROR

Type erasure would change T to Object, and surely you don’t want to call new Object().

Similarly, you cannot make a generic array:

public <T> T[] minMax(T[] a) { T[] mm = new T[2]; . . . } // ERROR

Type erasure would cause this method to always construct an array Object[2].

However, you can construct generic objects and arrays through reflection, by calling the Class.newInstance and Array.newInstance methods.

You cannot reference type variables in static fields or methods. For example, the following clever idea won’t work:

If this could be done, then a program could declare a Singleton<Random> to share a random number generator and a Singleton<JFileChooser> to share a file chooser dialog. But it can’t work. After type erasure there is only one Singleton class, and only one singleInstance field. For that reason, static fields and methods with type variables are simply outlawed.

It is illegal to create conditions that cause clashes when generic types are erased. Here is an example. Suppose we add an equals method to the Pair class, like this:

public class Pair<T>
{
   public boolean equals(T value) { return first.equals(value) && second.equals(value); }
   . . .
}

Consider a Pair<String>. Conceptually, it has two equals methods:

boolean equals(String) // defined in Pair<T>
boolean equals(Object) // inherited from Object

But the intuition leads us astray. The erasure of the method

boolean equals(T)

is

boolean equals(Object)

which clashes with the Object.equals method.

The remedy is, of course, to rename the offending method.

The generics specification cites another rule: “To support translation by erasure, we impose the restriction that a class or type variable may not at the same time be a subtype of two interface types which are different parameterizations of the same interface.” For example, the following is illegal:

class Calendar implements Comparable<Calendar> { . . . }
class GregorianCalendar extends Calendar implements Comparable<GregorianCalendar> { . . . 
} // ERROR

GregorianCalendar would then implement both Comparable<Calendar> and Comparable<GregorianCalendar>, which are different parameterizations of the same interface.

It is not clear what this restriction has to do with type erasure. The nongeneric version

class Employee implements Comparable { . . . }
class Manager extends Employee implements Comparable { . . . }

is legal.

Wildcard bounds are similar to type variable bounds, but they have an added capability— you can specify a supertype bound, like this:

? super Manager

This wildcard is restricted to all supertypes of Manager. (It was a stroke of good luck that the existing super keyword describes the relationship so accurately.)

Why would you want to do this? A wildcard with a supertype bound gives you the opposite behavior of the wildcards described on page 721. You can supply parameters to methods, but you can’t use the return values. For example, Pair<? super Manager> has methods

void set(? super Manager)
? super Manager get()

The compiler doesn’t know the exact type of the set method but can call it with any Manager object (or a subtype such as Executive), but not with an Employee. However, if you call get, there is no guarantee about the type of the returned object. You can only assign it to an Object.

Here is a typical example. We have an array of managers and want to put the manager with the lowest and highest bonus into a Pair object. What kind of Pair? A Pair<Employee> should be fair game or, for that matter, a Pair<Object> (see Figure 13–4). The following method will accept any appropriate Pair:

public static void minMaxBonus(Manager[] a, Pair<? super Manager> result)
{
   if (a == null || a.length == 0) return;
   Manager min = a[0];
   Manager max = a[0];
   for (int i = 1; i < a.length; i++)
   {
      if (min.getBonus() > a[i].getBonus()) min = a[i];
      if (max.getBonus() < a[i].getBonus()) max = a[i];
   }
   result.setFirst(min);
   result.setSecond(max);
}

Figure 13–4. A wildcard with a supertype bound

Intuitively speaking, wildcards with supertype bounds let you write to a generic object, wildcards with subtype bounds let you read from a generic objects.

Here is another use for supertype bounds. The Comparable interface is itself a generic type. It is declared as follows:

public interface Comparable<T>
{
    public int compareTo(T other);
}

Here, the type variable indicates the type of the other parameter. For example, the String class implements Comparable<String>, and its compareTo method is declared as

public int compareTo(String other)

This is nice—the explicit parameter has the correct type. Before JDK 5.0, other was an Object, and a cast was necessary in the implementation of the method.

Because Comparable is a generic type, perhaps we should have done a better job with the min method of the ArrayAlg class? We could have declared it as

public static <T extends Comparable<T>> T min(T[] a) . . .

This looks more thorough than just using T extends Comparable, and it would work fine for many classes. For example, if you compute the minimum of a String array, then T is the type String, and String is a subtype of Comparable<String>. But we run into a problem when processing an array of GregorianCalendar objects. As it happens, GregorianCalendar is a subclass of Calendar, and Calendar implements Comparable<Calendar>. Thus, GregorianCalendar implements Comparable<Calendar> but not Comparable<GregorianCalendar>.

In a situation such as this one, supertypes come to the rescue:

public static <T extends Comparable<? super T>> T min(T[] a) . . .

Now the compareTo method has the form

int compareTo(? super T)

Maybe it is declared to take an object of type T, or—for example, when T is GregorianCalendar— a supertype of T. At any rate, it is safe to pass an object of type T to the compareTo method.

To the uninitiated, a declaration such as <T extends Comparable<? super T>> is bound to look intimidating. This is unfortunate, because the intent of this declaration is to help application programmers by removing unnecessary restrictions on the call parameters. Application programmers with no interest in generics will probably learn quickly to gloss over these declarations and just take for granted that library programmers will do the right thing. If you are a library programmer, you’ll need to get used to wildcards, or your users will curse you and throw random casts at their code until it compiles.

You can even use wildcards with no bounds at all, for example, Pair<?>. At first glance, this looks identical to the raw Pair type. Actually, the types are very different. The type Pair<?> has methods such as

? getFirst()
void setFirst(?)

The return value of getFirst can only be assigned to an Object. The setFirst method can never be called, not even with an Object. That’s the essential difference between Pair<?> and Pair: you can call the setObject method of the raw Pair class with any Object.

Why would you ever want such a wimpy type? It is useful for very simple operations. For example, the following method tests whether a pair contains a given object. It never needs the actual type.

public static boolean hasNulls(Pair<?> p)
{
   return p.getFirst() == null || p.getSecond() == null;
}

You could have avoided the wildcard type by turning contains into a generic method:

public static <T> boolean hasNulls(Pair<T> p)

However, the version with the wildcard type seems easier to read.

Let us write a method that swaps the elements of a pair:

public static void swap(Pair<?> p)

A wildcard is not a type variable, so we can’t write code that uses ? as a type. In other words, the following would be illegal:

? t = p.getFirst(); // ERROR
p.setFirst(p.getSecond());
p.setSecond(t);

That’s a problem because we need to temporarily hold the first element when we do the swapping. Fortunately, there is an interesting solution to this problem. We can write a helper method, swapHelper, like this:

public static <T> void swapHelper(Pair<T> p)
{
   T t = p.getFirst();
   p.setFirst(p.getSecond());
   p.setSecond(t);
}

Note that swapHelper is a generic method, whereas swap is not—it has a fixed parameter of type Pair<?>.

Now we can call swapHelper from swap:

public static void swap(Pair<?> p) { swapHelper(p); }

In this case, the parameter T of the swapHelper method captures the wildcard. It isn’t known what type the wildcard denotes, but it is a definite type, and the definition of <T>swapHelper makes perfect sense when T denotes that type.

Of course, in this case, we were not compelled to use a wildcard—there is nothing wrong with using a type parameter, as in the swapHelper method. However, consider this example in which a wildcard type occurs naturally in the middle of a computation:

public static void maxMinBonus(Manager[] a, Pair<? super Manager> result)
{
   minMaxBonus(a, result);
   PairAlg.swapHelper(result); // OK--swapHelper captures wildcard type
}

Here, the wildcard capture mechanism cannot be avoided.

Wildcard capture is only legal in very limited circumstances. The compiler must be able to guarantee that the wildcard represents a single, definite type. For example, the T in ArrayList<Pair<T>> can never capture the wildcard in ArrayList<Pair<?>>. The array list might hold two Pair<?>, each of which has a different type for ?.

The test program in Example 13–3 gathers up the various methods that we discussed in the preceding sections, so that you can see them in context.

  1. import java.util.*;
  2.
  3. public class PairTest3
  4. {
  5.   public static void main(String[] args)
  6.   {
  7.      Manager ceo = new Manager("Gus Greedy", 800000, 2003, 12, 15);
  8.      Manager cfo = new Manager("Sid Sneaky", 600000, 2003, 12, 15);
  9.      Pair<Manager> buddies = new Pair<Manager>(ceo, cfo);
 10.      printBuddies(buddies);
 11.
 12.      ceo.setBonus(1000000);
 13.      cfo.setBonus(500000);
 14.      Manager[] managers = { ceo, cfo };
 15.
 16.      Pair<Employee> result = new Pair<Employee>();
 17.      minMaxBonus(managers, result);
 18.      System.out.println("first: " + result.getFirst().getName()
 19.        + ", second: " + result.getSecond().getName());
 20.      maxMinBonus(managers, result);
 21.      System.out.println("first: " + result.getFirst().getName()
 22.         + ", second: " + result.getSecond().getName());
 23.   }
 24.
 25.   public static void printBuddies(Pair<? extends Employee> p)
 26.   {
 27.      Employee first = p.getFirst();
 28.      Employee second = p.getSecond();
 29.      System.out.println(first.getName() + " and " + second.getName() + " are buddies.");
 30.   }
 31.
 32.   public static void minMaxBonus(Manager[] a, Pair<? super Manager> result)
 33.   {
 34.      if (a == null || a.length == 0) return;
 35.      Manager min = a[0];
 36.      Manager max = a[0];
 37.      for (int i = 1; i < a.length; i++)
 38.      {
 39.         if (min.getBonus() > a[i].getBonus()) min = a[i];
 40.         if (max.getBonus() < a[i].getBonus()) max = a[i];
 41.      }
 42.      result.setFirst(min);
 43.      result.setSecond(max);
 44.   }
 45.
 46.   public static void maxMinBonus(Manager[] a, Pair<? super Manager> result)
 47.   {
 48.      minMaxBonus(a, result);
 49.      PairAlg.swapHelper(result); // OK--swapHelper captures wildcard type
 50.   }
 51. }
 52.
 53. class PairAlg
 54. {
 55.    public static boolean hasNulls(Pair<?> p)
 56.    {
 57.       return p.getFirst() == null || p.getSecond() == null;
 58.    }
 59.
 60.    public static void swap(Pair<?> p) { swapHelper(p); }
 61.
 62.    public static <T> void swapHelper(Pair<T> p)
 63.    {
 64.       T t = p.getFirst();
 65.       p.setFirst(p.getSecond());
 66.       p.setSecond(t);
 67.    }
 68. }
 69.
 70. class Employee
 71. {
 72.    public Employee(String n, double s, int year, int month, int day)
 73.    {
 74.       name = n;
 75.       salary = s;
 76.       GregorianCalendar calendar = new GregorianCalendar(year, month - 1, day);
 77.       hireDay = calendar.getTime();
 78.    }
 79.
 80.    public String getName()
 81.    {
 82.       return name;
 83.    }
 84.
 85.    public double getSalary()
 86.    {
 87.       return salary;
 88.    }
 89.
 90.    public Date getHireDay()
 91.    {
 92.       return hireDay;
 93.    }
 94.
 95.    public void raiseSalary(double byPercent)
 96.    {
 97.       double raise = salary * byPercent / 100;
 98.       salary += raise;
 99.    }
100.
101.    private String name;
102.    private double salary;
103.    private Date hireDay;
104. }
105.
106. class Manager extends Employee
107. {
108.    /**
109.      @param n the employee's name
110.      @param s the salary
111.      @param year the hire year
112.      @param month the hire month
113.      @param day the hire day
114.   */
115.   public Manager(String n, double s, int year, int month, int day)
116.   {
117.      super(n, s, year, month, day);
118.      bonus = 0;
119.   }
120.
121.   public double getSalary()
122.   {
123.      double baseSalary = super.getSalary();
124.      return baseSalary + bonus;
125.   }
126.
127.   public void setBonus(double b)
128.   {
129.      bonus = b;
130.   }
131.
132.   public double getBonus()
133.   {
134.      return bonus;
135.   }
136.
137.   private double bonus;
138. }

It is sometimes useful to match the type variable of a Class<T> parameter in a generic method. Here is the canonical example:

public static <T> Pair<T> makePair(Class<T> c) throws InstantiationException, 
IllegalAccessException
{
   return new Pair<T>(c.newInstance(), c.newInstance());
}

If you call

makePair(Employee.class)

then Employee.class is an object of type Class<Employee>. The type parameter T of the makePair method matches Employee, and the compiler can infer that the method returns a Pair<Employee>.

One of the notable features of Java generics is the erasure of generic types in the virtual machine. Perhaps surprisingly, the erased classes still retain some faint memory of their generic origin. For example, the raw Pair class knows that it originated from the generic class Pair<T>, even though an object of type Pair can’t tell whether it was constructed as a Pair<String> or Pair<Employee>.

Similarly, consider a method

public static Comparable min(Comparable[] a)

that is the erasure of a generic method

public static <T extends Comparable<? super T>> T min(T[] a)

You can use the reflection API enhancements of JDK 5.0 to determine that

In other words, you get to reconstruct everything about generic classes and methods that their implementors declared. However, you won’t know how the type parameters were resolved for specific objects or method calls.

Note

The type information that is contained in class files to enable reflection of generics is incompatible with older virtual machines.

In order to express generic type declarations, JDK 5.0 provides a new interface Type in the java.lang.reflect package. The interface has the following subtypes:

Figure 13–5 shows the inheritance hierarchy. Note that the last four subtypes are interfaces—the virtual machine instantiates suitable classes that implement these interfaces.

Figure 13–5. The Type class and its descendants

Example 13–4 uses the generic reflection API to print out what it discovers about a given class. If you run it with the Pair class, you get this report:

class Pair<T extends java.lang.Object> extends java.lang.Object
public T extends java.lang.Object getSecond()
public void setFirst(T extends java.lang.Object)
public void setSecond(T extends java.lang.Object)
public T extends java.lang.Object getFirst()

If you run it with ArrayAlg in the PairTest2 directory, the report displays the following method:

public static <T extends java.lang.Comparable> Pair<T extends java.lang.Comparable> minmax
(T extends java.lang.Comparable[])

The API notes at the end of this section describe the methods used in the example program.

  1. import java.lang.reflect.*;
  2. import java.util.*;
  3.
  4. public class GenericReflectionTest
  5. {
  6.    public static void main(String[] args)
  7.    {
  8.       // read class name from command-line args or user input
  9.       String name;
 10.       if (args.length > 0)
 11.          name = args[0];
 12.       else
 13.       {
 14.          Scanner in = new Scanner(System.in);
 15.          System.out.println("Enter class name (e.g. java.util.Date): ");
 16.          name = in.next();
 17.       }
 18.
 19.       try
 20.       {
 21.          // print generic info for class and public methods
 22.          Class cl = Class.forName(name);
 23.          printClass(cl);
 24.          for (Method m : cl.getDeclaredMethods())
 25.             printMethod(m);
 26.       }
 27.       catch (ClassNotFoundException e)
 28.       {
 29.          e.printStackTrace();
 30.       }
 31.    }
 32.
 33.    public static void printClass(Class cl)
 34.    {
 35.       System.out.print(cl);
 36.       printTypes(cl.getTypeParameters(), "<", ", ", ">");
 37.       Type sc = cl.getGenericSuperclass();
 38.       if (sc != null)
 39.       {
 40.          System.out.print(" extends ");
 41.          printType(sc);
 42.       }
 43.       printTypes(cl.getGenericInterfaces(), " implements ", ", ", "");
 44.       System.out.println();
 45.    }
 46.
 47.    public static void printMethod(Method m)
 48.    {
 49.       String name = m.getName();
 50.       System.out.print(Modifier.toString(m.getModifiers()));
 51.       System.out.print(" ");
 52.       printTypes(m.getTypeParameters(), "<", ", ", "> ");
 53.
 54.       printType(m.getGenericReturnType());
 55.       System.out.print(" ");
 56.       System.out.print(name);
 57.       System.out.print("(");
 58.       printTypes(m.getGenericParameterTypes(), "", ", ", "");
 59.       System.out.println(")");
 60.    }
 61.
 62.    public static void printTypes(Type[] types, String pre, String sep,  String suf)
 63.    {
 64.       if (types.length > 0) System.out.print(pre);
 65.       for (int i = 0; i < types.length; i++)
 66.       {
 67.          if (i > 0) System.out.print(sep);
 68.          printType(types[i]);
 69.       }
 70.       if (types.length > 0) System.out.print(suf);
 71.    }
 72.
 73.    public static void printType(Type type)
 74.    {
 75.       if (type instanceof Class)
 76.       {
 77.          Class t = (Class) type;
 78.         System.out.print(t.getName());
 79.       }
 80.       else if (type instanceof TypeVariable)
 81.       {
 82.          TypeVariable t = (TypeVariable) type;
 83.          System.out.print(t.getName());
 84.          printTypes(t.getBounds(), " extends ", " & ", "");
 85.       }
 86.       else if (type instanceof WildcardType)
 87.       {
 88.          WildcardType t = (WildcardType) type;
 89.          System.out.print("?");
 90.          printTypes(t.getLowerBounds(), " extends ", " & ", "");
 91.          printTypes(t.getUpperBounds(), " super ", " & ", "");
 92.       }
 93.       else if (type instanceof ParameterizedType)
 94.       {
 95.          ParameterizedType t = (ParameterizedType) type;
 96.          Type owner = t.getOwnerType();
 97.          if (owner != null) { printType(owner); System.out.print("."); }
 98.          printType(t.getRawType());
 99.          printTypes(t.getActualTypeArguments(), "<", ", ", ">");
100.       }
101.       else if (type instanceof GenericArrayType)
102.       {
103.          GenericArrayType t = (GenericArrayType) type;
104.          System.out.print("");
105.          printType(t.getGenericComponentType());
106.          System.out.print("[]");
107.       }
108.
109.    }
110. }

java.lang.Class<T> 1.0

java.lang.reflect.Method 1.1

java.lang.reflect.TypeVariable 5.0

java.lang.reflect.WildcardType> 5.0

java.lang.reflect.ParameterizedType 5.0

java.lang.reflect.GenericArrayType 5.0

You have now reached the end of the first volume of Core Java. This volume covered the fundamentals of the Java programming language and the parts of the standard library that you need for most programming projects. We hope that you enjoyed your tour through the Java fundamentals and that you found useful information along the way. For advanced topics, such as networking, multithreading, security, and internationalization, please turn to the second volume.