The trouble with Generics

This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis.

Generics Rock!

Java generics are good for type safety throughout your code. They document the code directly with intent: List<Person> leaves little to the imagination as to what goes into the list.

These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView:

Generics Suck!

TBD

Suggestion 1 - setResponsePage() signature

The initial issue that started this discussion was a problem with this method signature:

public final void setResponsePage(final Class<? extends Page<?>> cls, PageParameters parameters)
{
    getRequestCycle().setResponsePage(cls, parameters);
}

We could change this to:

@SuppressWarnings({"unchecked"})
public final void setResponsePage(final Class<?> cls, PageParameters parameters)
{
    final Class<? extends Page<?>> castCls = (Class<? extends Page<?>>) cls;
    getRequestCycle().setResponsePage(castCls, parameters);
}

This way (a) users migrating to 1.4 don't get tons of warnings/errors and (b) if they pass in the wrong thing, a class cast exception will be thrown quickly.

NOTE: This is just an example - we may wish to move the cast into the getRequestCycle() call ...

My idea is to dial back the generics on some of the API calls like this one and others that cause pain, but leave the generics for useful things like getModelObject().

-Doug Donohoe

Suggestion 2 - RestartResponseAtInterceptPageException constructor

I agree with Doug, and with suggestion 1 above on setResponsePage changing to take Class<?>

I think another example is the constructor of RestartResponseAtInterceptPageException (and similar classes) that take a class as an argument.

	public RestartResponseAtInterceptPageException(final Class< ? extends Page< ? >> interceptPageClass)
	{
		if (interceptPageClass == null)
		{
			throw new IllegalStateException("Argument pageClass cannot be null");
		}
		redirectToInterceptPage(interceptPageClass);
	}

We could change this to:

public RestartResponseAtInterceptPageException(final Class<?> interceptPageClass)
{
	if (interceptPageClass == null || !Page.class.isAssignableFrom(interceptPageClass))
	{
		throw new IllegalStateException("Argument pageClass cannot be null and must inherit from Page.class");
	}
	redirectToInterceptPage(interceptPageClass);
}

This, for the same reason as suggestion 1 - it's not very likely that someone is going to pass a non-page-child class into these methods or constructors, so the benefit is minimal, but the strictly generified versions penalize you if your page class is not also generified, which would be confusing to new users.