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:
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:
IModelinterface and implementations increases type safety in your Wicket applications
Component#setModel()have been renamed to
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
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.
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
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
Component which has a model property). When we generified
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: