Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

The Curious Coder’s Guide to Java Web Frameworks: Wicket

Get the full report

Psst! Want to see the 8 most popular Java Web Frameworks compared? Since this post here, we’ve made The Curious Coder’s Java Web Frameworks Comparison: Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF. Grab the complete report in HTML and/or PDF. Win!

Dude, go for the Full Report instead!

This is our fourth post in our review of Java web frameworks, having already covered VaadinGrails and Spring MVC. Today we look at Wicket, which is maintained by the Apache Foundation. According to our latest Developer Productivity report,  Wicket holds a 7% share of the Java Web Framework space, comparable to Vaadin & Grails.

Apache Wicket is a stateful web framework focusing on keeping things simple and letting Java developers do what they know best – write Java code – instead of messing with tedious xml and other configuration files. It provides a clear separation of markup (html/xml) and logic (Java code), letting your web designers make changes to the markup templates of the application without worrying about breaking everything. Wicket follows the standard MVC pattern where pages and components are built up from Java classes/objects – the Controller and the Model respectively – and the corresponding HTML template – the View.

I want it! How can I get it?

The easiest way to set up a sample application on your local machine is to use the wicket-archetype-quickstart maven archetype. This will set up a simple Wicket project with a single page. Run this in your console (requires Maven):

mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=6.8.0 -DgroupId=org.zeroturnaround.labs.wicket -DartifactId=demo -DarchetypeRepository= -DinteractiveMode=false

What you will end up with is a small application with all the relevant plumbing already in place.

Let’s take a look at the various components that make up this plumbing in detail. The archetype generates a Maven project, so the first thing to look at is the generated pom.xml. This is pretty standard fare for those well-versed in Maven-ese, and the only thing special about the generated pom.xml is that there is the following dependency added to it:


    <version>${wicket.version}</version><!-- This is resolved to 6.8.0 -->

This means that we effectively have wicket-core.jar version 6.8.0 in our classpath and we can start using wicket goodness in our application.

Next we should take a look at the web.xml file that was generated. What we see is that Wicket is set up by having a servlet filter of type org.apache.wicket.protocol.http.WicketFilter in front of our application, so each time a request is made to a URL that matches this, Wicket will kick in and try to handle the request. Also what you should note is the applicationClassName argument. This is required and tells Wicket the name of your application configuration class (more on this later).




Looking into the WicketApplication class that was given to the applicationClassName parameter, we can see two (required) methods. The init() method is where your application configuration will happen. This is where you can specify various configuration options by calling methods in the WebApplication, set up mount paths to respond to your application URL-s and generally initialize the application in whatever way necessary. The getHomePage() returns a class that represents the “home” page of the application – i.e. the Page that is mounted to root / of the webapp context.


public class WicketApplication extends WebApplication {     

    public Class<? extends WebPage> getHomePage(){
        return HomePage.class;

    public void init() {
        // add your configuration here

Next up is the HomePage.class. This is the “controller” part of the HomePage component responsible for setting up the component model of the page (more on components later). Since the ideology behind Wicket is that java developers should write java code, then it only makes sense that the component model is set up in the class constructor and that components are “added” to the page. For this page we only add a single component to it – a Label with an id of “version”, and as a “model” (we will go into details of models later) value of whatever is returned from the call to getApplication().getFrameworkSettings().getVersion().


public class HomePage extends WebPage {
    private static final long serialVersionUID = 1L;

    public HomePage(final PageParameters parameters) {
        add(new Label("version", getApplication().getFrameworkSettings().getVersion()));
        // TODO Add your page's components here

Moving on, let’s check out the HomePage.html, there is a bunch of stuff there, so I took the liberty of clearing out the generated HomePage.html for clarity and left only the following:


<!DOCTYPE html>
<html xmlns:wicket="">
        <title>Apache Wicket Quickstart</title>
        Wicket version: <span wicket:id="version">WILL BE REPLACED</span>

The html file makes up the “view” part of the home page and this is standard html, with a

<span wicket:id="version">...</span>

thrown into the mix. The wicket:id="version" corresponds to the id of the Label component added to the page and when a request is made to render the home page, it will be replaced by the value of the model for that given component


As we briefly saw in the HomePage, Wicket pages are built up of components added to the page. There we only used a Label component which is a very simple example of a component. Components can be everything from simple Labels to Lists to Panels and Containers. A single component can be made up of multiple smaller components and building these complex custom components for your pages is something that makes up the beauty and power of Wicket. In the end your application will consist of complex reusable components like UserDetailsPanel, ProductsList or SearchForm, each manipulating the models associated with the component and using their own markup for detailing their visual representation.

The following is an example component class for a user details panel. The panel has three Label components added to it – a static firstName and lastName and a dynamic isActive – and a Link component that toggles the “active” property of the User model object passed to our component whenever that link is clicked.


public class UserDetailsPanel extends Panel {
    public UserDetailsPanel(String id, final IModel<User> userModel) {
        add(new Label("firstName", userModel.getObject().getFirstName()));
        add(new Label("lastName", userModel.getObject().getLastName()));
        add(new Label("isActive", new AbstractReadOnlyModel<String>() {
            public String getObject() {
                return userModel.getObject().isActive() ? "true" : "false";
        add(new Link("toggle") {
            public void onClick() {


Models are allegedly one of the trickier aspects to understand about Wicket development, but actually very straightforward. The IModel interface is defined as such:

public interface IModel extends IDetachable {
    T getObject();
    void setObject(final T object);

Virtually every standard component in the Wicket library has a constructor that takes in (at least) two arguments – a String id and an IModel value. The component uses this model object to retrieve data from it to be displayed (or otherwise used) or to push data into it after some updates on the page – submitting a form is a prime example of this, however that definitely does not stop there. The models can range from very simple ones where getObject() just returns a static object (reference) or very complex where the getObject()/setObject() methods interact with some data in a cache or database.

A word of warning when using components and models. You should make your models as lightweight as possible, meaning that they should either be made “detachable”, and both your models and components should not hold hard references to huge object trees that are not used in other parts of the application. Since Wicket is a stateful framework, the component hierarchy of a page, the corresponding model hierarchy, and the page itself, can be saved in your session object into what is called a “page map”. Given a sufficient number of pages holding references to large objects trees, this can make your application run out of memory very quickly.

HTML templates

Behind every component is a markup (html, xml, etc.) file, acting as the “view” part of a component – which is basically a regular html/xml file where certain tags include a special wicket:id="some_id" attribute. This attribute ties an element in the document (or DOM) to an object in the component hierarchy of a given page. This way of laying out and binding elements in your view to the controller gives you a clear separation of concerns between the controller deciding what to display (for example for the following example the number of elements rendered to the final result depends on the controller) and the view that specifies how to display the elements that are displayed. Also, if you have a separate role in your project for generating (and later modifying) the markup files – like a web designer – then he can generally feel confident modifying the html code provided that the wicket:id tags stay in place.

Here is the html markup template corresponding to our UserDetailsPanel component. Note how we are binding the ID-s of the components in our UserDetailsPanel.class to the different elements in the markup.


<html xmlns:wicket="">
        <span wicket:id="firstName">Test</span>
        <span wicket:id="lastName">User</span> 
        Active: <span wicket:id="isActive">Yes/No</span>
        <a href="#" wicket:id="switch">switch</a>

What is cool about Wicket and why should I use it?

There are a bunch of cool things about Wicket and it is definitely one of my favorite frameworks for web development. Keeping things in Java code instead of tedious configuration files, a clear MVC model, clean html and a wicked component model means that you will be creating reusable components and building things up from these components in your next project in no time. In fact, if you want to get started right now, I wouldn’t blame you: here are some links on the introduction and motivation behind Wicket, some useful code examples and a component reference as well.

What should you keep in mind when considering Wicket for your application?

There are however some drawbacks and gotchas one should keep in mind when considering Wicket as the web framework for your next project. As said before, Wicket is inherently a stateful framework – this means that you, as a developer, should note that Wicket might save the entire page object and component hierarchy for every page you visit either in the session object of a user (for the last rendered page) or the disk (for older pages), unless that page is considered “stateless”. This means you should keep an eye on your disk capacity and (to a lesser extent, the session size). This is especially important in a clustered environment where replicating big session objects can be troublesome, and different nodes may have different information about the page history. A possible solution here would be to use a distributed cache like Memcached/Hazelcast for storing the page.

Wicket is a server-side framework which means that building the resulting page to be rendered to the user is done on the server and will thus consume server resources. Compare this to a client-side/Ajax/Restful application (like GWT, Vaadin, etc), where most of the rendering is done on the client’s browser and you can see that Wicket might not be the best option for applications where throughput is a top priority. Here however, Wicket could be used to render the initial page skeleton and have the rest of the communication with the server done via Ajax requests. Wicket does have great Ajax support built into it, and makes building pages with Ajax components a breeze – just configure your components to use Ajax if possible – with no messing with the client side JavaScript required (however you could always use your favorite client-side JS library to do things and have Wicket server the data in any required format).

Wicket’s performance is definitely comparable to other server-side java web frameworks and in my humble opinion, the developers of Wicket have been pretty successful in keeping things simple for the developer and the API usually works how you expect it to work, with close to no surprises.

Please leave your opinions and ideas below in the comments section, or tweet us @ZeroTurnaround with your story!

  • Martin Grigorov


    Thanks for the article!

    Few notes on the gotchas:

    *) might save the entire page object and component hierarchy for every page you visit (up to a limit)

    The limit is 1, i.e. only the last used page by a user is saved in the http session. All older pages are stored in the disk.

    *) in a clustered environment where replicating big session objects can be troublesome

    Here one can use distributed cache like Memcached/Hazelcast for storing the page

    *) Compare this to a client-side/Ajax/Restful application …

    Wicket can serve only the initial page skeleton and from there on the application developer can use her favorite JavaScript library to do any further manipulations. With Wicket’s IResource the application can deliver any kind of data (JSON, XML, …). Even Wicket’s Ajax support can let you serve custom response and render it manually, i.e. with some JS templating solution.

  • Sven Laanela

    Hi Martin,

    Thanks for the great feedback, I have clarified my original post with the details from your comment. It is always good to have this kind of insight straight from the source.

    As I said before, I think Wicket is a fantastic framework, so keep up the good work!