The Apache Wicket PMC has released Apache Wicket 7.2.0. This release is a minor release, but does contain new features. To learn more about this release and the state of Apache Wicket, InfoQ interviewed Apache Wicket PMC member Martijn Dashorst.
InfoQ: First of all, congrats on the release! In the New and noteworthy section of your release notes, you mention two notable features: 1) the ability to read resources from file systems using Java’s NIO API and 2) loading images from external servers. Can you explain to InfoQ readers why these are important?
Dashorst: The first feature makes it easy to directly stream media content from the file system to the browser. For example when you have a video file stored in a zip archive, you can stream this directly using the Java NIO API's:
The Java code:
URI uri = URI.create("jar:file:///videosFolder/videos.zip!/folderInZip/Video.mp4"); Path path = FileSystemResourceReference.getPath(uri); FileSystemResourceReference ref = new FileSystemResourceReference("video", path); Video video = new Video("video", ref); add(video);
The HTML markup:
<video wicket:id="video"></video>
The Video component will create the appropriate media tags in the HTML document and the
FileSystemResourceReference
will allow the direct streaming of the video content when the browser asks for it.Wicket is for example used by the Apache OpenMeetings project so this feature will come in handy for them.
The
ExternalImage
component is more of a repurposing of an existing component and bringing it up to speed with current web-best-practises. TheExternalImage
supports cross-origin resource sharing (CORS) and thesrcSet
attribute when it is provided with a list of external URLs.This allows applications to use responsive multi-resolution images.
InfoQ: It looks like Wicket’s mailing list traffic is way down (averaging 6 messages per day according to http://wicket.markmail.org). Do you feel this is caused by a rise in JavaScript MVC frameworks?
Dashorst: I think that there are many contributing factors for mailing list traffic going down.
As you can see with several other frameworks shutting down -- a couple of weeks ago JBoss announced the end of life for RichFaces -- the server-side web framework landscape has lost much of its appeal. As I noted in the State of Apache Wicket just over a year ago, Wicket is one of the few survivors of the server-side web framework of the mid-2000's: barely 15 have survived, where I note that 'survive' means made a release in the last year.
Of course having books, and having a user guide online available removes the need for some questions, the advent of Stack Overflow for asking and answering questions another.
Wicket has been around for a long time and lots of applications rely on it to work. Therefore we adopted semantic versioning since 6.0 and strive to keep major API changes to a minimum. This slows down the evolution of our framework, and hence commit traffic.
That said, the server-side frameworks are done, complete. There's not much to add to those frameworks to improve them an order of magnitude, and I doubt our current users would like us to completely rewrite Wicket even if it would provide a new compelling API for new developers.
Does this spell gloom and doom for the future of Wicket? No, I am confident that we'll be supporting and developing Wicket for the foreseeable future! We constantly add new developers to the core team to keep the project moving forward. Our downloads have been stable at 70,000 per month for the last couple of years, and there are still projects being started with Wicket.
InfoQ: What features do you plan to add to Wicket in the future?
Dashorst: Good support for Java 8: lambda's seem like a natural fit for our event handling and bindings between components and your domain objects. However we want to make sure we keep the memory requirements low. This is something we plan for Wicket 8, but there's not a set timeline.
We'll keep an eye on Java EE technologies and keep integrating with those, for example CDI and the bean validation framework.
We're also looking at parts of Wicket that can be improved to get even higher performance. We recently replaced a core functionality of Wicket where adding components to a page had 3 levels of O(N^2) complexity, and replaced it with an algorithm that's roughly O(1). This was a holdover from the old days where we optimized for memory consumption rather than CPU cycles.
Then there's my personal wishlist for the Wicket core. Wicket uses server-side state for much of its AJAX processing, and I want to make stateless AJAX happen. I want to revisit the Wicket examples project and integrate it with the user guide, so the user guide can import living code.
InfoQ: What do you think of the Spring Boot starter for Apache Wicket?
Dashorst: It is great! A lot of work went into creating that project, but I have yet to play with it. It is a nice departure of the quick start project we provide from our website, and looks like nice place to start for getting up and running with a new project based on Wicket.
I think this is a great example of the liveliness of our community. There are lots of open source integrations with Wicket, for example our Wicket Stuff project consists of almost 100 projects. The Wicket Bootstrap project is keeping up with the newest Bootstrap and Wicket releases. Another contributor works on JQuery UI and Kendo UI integration with Wicket. So while interest in server-side frameworks is waning, the rumors of our demise are greatly exaggerated.
InfoQ: Anything else you’d like to add?
Dashorst: If you have read this far, and never played with Wicket, or your experience is from a long time ago, try it! Starting with Wicket was never this easy. You can use the aforementioned Spring Boot integration, or our Maven Quick Start.
If you want to find out more about who is using Wicket you can look at our Built with Apache Wicket tumblr site, or follow our Twitter account, @apache_wicket, that publishes anything that happens in our community, and finds all the Wicket built websites.