Reasons I like Wicket

I have been using Struts for a long time now. Also I have used other frameworks like JSF and WebWork. But Wicket seems to a breeze of fresh air. Lots of information is already available on Wicket and how it compares with other frameworks in general, so here I will try to focus on what I experienced. 1. Wicket uses plain Java with plain HTML. Goodbye to XML configuration files for building web applications (web.xml still remainsJ). You just need a good IDE. NetBeans and Eclipse already have some plug-in support to facilitate RAD.

2. Creating a component in Wicket is really easy and requires writing an HTML file and a plain Java class. Being a component oriented framework reusability of components can be achieved easily. In other frameworks reuse of components at the UI layer has been a big hassle. In wicket you make subclasses of existing components (e.g. Panel) and provide your own version of it leading to an OO design.

3. Wicket imposes minimal requirements on the mark-up templates. It does not introduce any special syntax to HTML. It extends HTML in a XHTML standards way via Wicket namespace. Thus the nice side-effect of using Wicket is a XHTML compliant web page. This promotes the almost as is use of templates from the UI designers. Changes if required in later stages can be done by UI designers easily in their favourite IDE. I’m sure that this is a big deal for most development teams. Wicket renders clean HTML code which can later be used for making adjustments to the UI.

4. Wicket provides a large set of components, not to forget their Ajax counterparts. Developing Ajax enabled applications has never been easier. If advanced functionality is required on top of the existing one existing components can be extended to build new custom components. Libraries for integration with well know JavaScript frameworks like script.aculo.us, Prototype and DOJO also exist. All of the above in few minutes with a few lines of Java code. The custom components and ideas are shared and thus the component palette is ever increasing.

5. Out of the box Ajax support is the most killer feature of Wicket. I tried playing around with DOJO and also DWR in some of my Struts applications. But the AJAX support in Wicket is refined with virtually no JavaScript to write. The very useful Ajax debug popup that automagically appears on your web pages in development mode. So using Ajax is as simple as telling Wicket that instead of showing or hiding a component using a full-page refresh do that using Ajax partial-updates to a page. And it just works on any kind of component.

6. Wicket has some cool features I explored out of necessity. Unlike other frameworks like Struts where you have to choose say commons-fileupload and manually include the JAR, I was pleasantly surprised to see that Wicket supports multipart forms / file uploading out of the box. Wicket also provides a download file link component specifically for this purpose. You can get those bookmarkable “friendly URLs” with the use of URL mounting feature provided in Wicket. Wicket provides a good form binding support for POJO’s. Component validation support in Wicket is good with Ajax validation easy to implement.

7. Very active community.

8. Fairy good documentation with working sample code.

Sure there is some learning curve but I think it’s worth the effort. Wicket is an excellent framework and seems that it has been developed keeping in mind the problems a common development team faces. Enjoy J

Singleton In Different Way

public class Singleton {
    private Singleton() {
    }
    private static class SingletonHolder {
        private static final Singleton singleton = new Singleton();
    }
    public static Singleton getInstance() {
        return SingletonHolder.singleton;
    }
}

Whenever a class is first loaded by JVM it's static variable and static initialiser bloacks are executed. In the above example when the class Singleton is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables and initializer blocks, the initialization completes simply. The JVM will not load the static class definition SingletonHolder within Singleton class until you touch something in the SingletonHolder class. Hence the static variable is not initialized until the JVM determines that SingletonHolder must be loaded or executed. The static class SingletonHolder is only executed when the static method getInstance is invoked on the class Singleton.

The first time when this class will be loaded by the JVM the static variable singleton will be initialized by executing the (private) constructor for the outer class Singleton. As per the Java Language Specification (JLS) the class initialization phase is guaranteed to be serial, i.e., non-concurrent, no further synchronization is required in the static getInstance method during loading and initialization. As the initialization phase initializes the static variable singleton in synchronized manner, all subsequent concurrent invocations of the getInstance will return the same correctly initialized singleton without incurring any additional synchronization overhead.