One of the things I’ve noticed lately are some discussions regarding how cumbersome generics can be. They can take time to get right or figure out and some folks have gone as far as to stipulate that if you can’t do it without generics then something is borked.
While reading a lot of this, I’ve also being writing the MVC for JCatapult. I’m a big generic fan and I’m on the opposite side of the fence from a lot of the folks that have been generic bashing lately. I think that if you can’t get rid of all the unchecked warnings and use generics everywhere, you’re probably not doing something correctly. Of course this isn’t always possible, but I try to get there.
I’ve done some Rails work and some Grails work over the past few years. When it comes to dynamic languages, you are almost always getting the incoming HTTP request parameters into your actions as simple Strings. Therefore, if you want to do some math or pass them along, you might have to convert them a bit. This is how most first generation Java MVCs also worked. A few more modern MVCs did it a bit better. Struts2 for example uses OGNL and can populate JavaBeans with the values using a specific syntax like this:
user.address.city
These MVCs also go so far as to provide type conversion support. If you have an action like this:
public class MyAction {
private int age;
public int getAge() {...}
public void setAge(int age) {...}
}
you can pass in the age parameter and the MVC will convert it to an integer. Most of these also handle type conversion failures decently well. Here is an example URL:
http://www.example.com/my-action?age=42
In many cases, these more modern MVCs will also instantiate classes for you and set them into JavaBean properties. The user.address.city example might map to this code (getters and setters have been left out):
public class MyAction {
private User user;
}
public class User {
private Address address;
}
public class Address {
private String city;
}
Since the MyAction member variable named user is null, the MVC will instantiate the User class and set it into the MyAction class. Most of these MVCs hit a limitation when it comes to complex object modeling that uses collections. One of the main reasons is that from a legacy perspective (i.e.JDK 1.4) it was impossible to know what types of objects were being stored in a collection. Here’s an example:
public class MyAction {
private User user;
}
public class User {
private Map addresses;
}
public class Address {
private String city;
}
There was no way for the MVC to understand that the Map contains addresses and that the keys are Strings like home and work. However, if you changed this code like this:
public class MyAction {
private User user;
}
public class User {
private Map<String, Address> addresses;
}
public class Address {
private String city;
}
some modern MVCs can figure it out. The issue is that they don’t do a good job and many times fail horribly. So, I decided for JCatapult to fix this. JCatapult supports all flavors of generic programming when it is converting HTTP request parameters into objects. It supports arrays, Collections, Lists, Sets, SortedSets, Queues, and Maps. It also handles nested collections like:
Map> crazyAddresses;
It also supports handling multiple request parameters of the same name and converting them into generic collections. Let’s say you want to pass in a list of IDs using checkboxes like this:
<input type="checkbox" name="ids" value="1"/>Choice 1 <input type="checkbox" name="ids" value="2"/>Choice 2 <input type="checkbox" name="ids" value="3"/>Choice 3
These will come into the Servlet container as a single parameter that is an array of Strings. Your action can then look like this:
public class MyAction {
private Set ids;
}
You could also nest these IDs inside another class. The nice thing about this is that using generics can reduce the amount of code you have to write to get access to a Set of Integers.
So, the moral of the blog post, generics are good things and can reduce overhead considerably.
