Generic methods in Java


public static void main(String[] args) {
genericMethod("abc");
}

static void overloadedMethod(Object o) {
System.out.println("overloadedMethod(Object) called");
}

static void overloadedMethod(String s) {
System.out.println("overloadedMethod(String) called");
}

static void overloadedMethod(Integer i) {
System.out.println("overloadedMethod(Integer) called");
}

static <T> void genericMethod(T t) {
overloadedMethod(t);
}


produces output "overloadedMethod(Object) called"; this is because the generic method doesn't know what kind of argument will be passed in at compile time [DBL-CHECK REASON]

Parameterizing Wicket tables

Constructors for DefaultDataTables — including AjaxFallbackDefaultDataTables — include one or the other of:


IColumn<T>[] columns
java.util.List<IColumn<T>> columns


In other words, the parameter of the table — T — should be the same as the parameter of its columns.

Wicket ChoiceRenderers should take the same parameter as their DropDownChoices

From the Wicket 1.4.1 API:


new DropDownChoice("users", new Model(selectedUser), listOfUsers, new ChoiceRenderer("name", "id"));


Java generics, name clash and erasure

In progress: Adding to this post

General Overview

http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html

FILL IN fancy term

It is not legal to use List<SubtypeOfFoo> as a subtype of List<Foo>. This is counterintuitive, especially because it IS legal to treat SubtypeOfFoo[] as a subtype of Foo[]. (Aside: new Integer[] { 1, 2, 3 } instanceof Number[] returns true.) This makes sense, because it prevents the following error from occurring:

// Bicycle and Train are subclasses of Vehicle
public void foo() {
List<Bicycle> bikes = new ArrayList<Bicycle>
addVehicle(bikes);
}

public void addVehicle(List<Vehicle> vehicles) {
vehicles[0] = new Train();
}



The matching code using arrays, shown below, compiles okay but will throw an ArrayStoreException at runtime. This works for arrays but not for generified collections because type erasure (see next section) makes it impossible for the JVM to throw a generified-collection equivalent of the ArrayStoreException.


// Bicycle and Train are subclasses of Vehicle
public void foo() {
Biycle[] bikes = { new Bicycle(), new Bicycle(), new Bicycle() };
addVehicle(bikes);
}

public void addVehicle(Vehicle[] vehicles) {
vehicles[0] = new Train(); // Compiles, but will explode at runtime
}


ADD MORE INFO HERE

Type Erasure

This is basically a fancy term for "all information about generics goes away before runtime." To give slightly more detail, a modern compiler will check generics for correctness to the best of its ability and insert casts where needed. As soon as that's done, it discards — or, erases — the generics and finishes compilation. By runtime, the JVM has no idea that generics were ever used; the code looks the same as it would have before J2SE 5, when generics were introduced.

The name clash error

Remember parameters for parent classes! From http://elliottback.com/wp/name-clash-the-method-blah-has-the-same-erasure-as-type-blah-but-does-not-override-it/:

Name clash: The method [foo] of type [some generic type] has the same erasure as [foo again] of type [some other generic type] but does not override it

In some cases, this can be fixed by adding parameters to the superclass name in the class containing foo. That is, change

class Bar<T> extends SuperBar

to

class Bar<T> extends SuperBar<T>