Apache Wicket 1.4 takes typesafety to the next level

30 Jul 2009

The Apache Wicket project is proud to announce the release of Apache Wicket 1.4. Apache Wicket is an open source, component oriented Java web application framework. With overwhelming support from the user community, this release marks a departure from the past where we leave Java 1.4 behind and we require Java 5 as the minimum JDK version. By moving to Java 5 as the required minimum platform, we were able to utilize Java 5 idioms and increase the type safety of our APIs. Using Java generics you can now write typesafe web applications and create typesafe, self documenting, reusable custom components.

Download Apache Wicket 1.4

You can download the release here: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0

Or use this in your Maven pom’s to upgrade to the new version:

<dependency>
  <groupId>org.apache.wicket</groupId>
  <artifactId>wicket</artifactId>
  <version>1.4.0</version>
</dependency>

You will need to upgrade all modules (i.e. wicket, wicket-extensions) to their 1.4 counterparts. It is not possible to mix Wicket 1.3 libraries with 1.4 libraries due to API changes.

Most notable changes

From all the changes that went into this release, the following are the most important ones:

• Generified IModel interface and implementations increases type safety in your Wicket applications
• Component#getModel() and Component#setModel() have been renamed to getDefaultModel() and setDefaultModel() to better support generified models
• The Spring modules have been merged (wicket-spring-annot is now obsolete, all you need is wicket-spring)
• Many API’s have been altered to better work with Java 5’s idioms
• Wicket jars are now packaged with metadata that makes them OSGI bundles

Apart from these changes, the release is mostly compatible with Wicket 1.3 and upgrading shouldn’t take too long. Early adopters report about a days work to upgrade medium to large applications to Wicket 1.4. Read the migration guide to learn more about the changes in our APIs. To learn more about all the improvements and new features that went into this release, check the solved issue list in our JIRA instance.

Increased type safety

Moving towards Java 5 has given us the opportunity to utilize generics and clarify our API’s. For example, take a look at DropDownChoice—one of the components with the most questions on our list prior to 1.4. A DropDownChoice component is a form component that displays a list of available choices in a drop down box, and allows one selection to be made. DropDownChoice components are typically used to display a list of countries, nationalities, credit card processors, etc.

The signature of a constructor for the DropDownChoice component in Wicket 1.3 was:

public class DropDownChoice extends ...
    public DropDownChoice(String id, IModel model, IModel choices)
}

As you can see, this constructor doesn’t give much insight into what goes where (other than the names of the parameters). The first parameter is the component identifier, the second parameter is the model that contains the selection, and the third parameter is a model that contains the list of choices from which the user can select one. You’ll have to read the JavaDoc to assign the right IModel values to the right parameters. Now take a look at the same constructor, but now in Wicket 1.4. The signature for our generified constructor looks like the following example.

public <T> DropDownChoice extends ...
    public DropDownChoice(String id, IModel<T> model, IModel<? extends List<? extends T>> choices)
}

Here we communicate that the first IModel parameter is a T, which is the single value that will be provided when the DropDownChoice selects one value. The second parameter provides a List of objects that extend T, the choices from which to select one value. This was not apparent in the Wicket 1.3 API, and the type safety brought by generics make this much more clear, albeit much more verbose.

Removal of default model from component

In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even WebMarkupContainer had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that either do not use a model or use two different model types: which one should be in the lead? We chose to generify only the components that clearly benefited from the extra type information, leading to clean code like this:

ListView<Person> peopleListView = new ListView<Person>("people", people) {
        protected void populateItem(ListItem<Person> item) {
            item.add(new Link<Person>("editPerson", item.getModel()){
                public void onClick() {
                    Person p = getModelObject();
                    setResponsePage(new EditPersonPage(p));
                }
            });
        }
    };