Page History

...

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.