Wicket 8: What’s New and What’s Next for the Server-Side Java Web Framework
Hot on the heels of the release of Apache Wicket 8, the project has more work on its hands: Oracle announced it will be removing serialization from Java at some as-yet-unspecified date.
Wicket, one of the few survivors of the “Java server-side web framework wars” of the mid-2000’s, relies heavily on serialization.
The popular component-oriented server-side Java web framework helps developers create complex web applications using fewer lines of code. It’s widely used in organizations including the Brazilian Air Force, the German National Library of Science and Technology, Japan National Police Agency and Norwegian Ministry of Foreign Affairs.
It’s different from other Java server-side frameworks. Instead of thinking about requests coming into your application and handling the requests, Wicket allows the developer to think in interface components, such as “Pages,” “Panels,” “Buttons,” “Links,” “Forms,” and “ListViews.”
The new version includes full support in the Wicket API for Java 8 idioms. Everything has been upgraded, making Java 8 the minimum required version.
It has added support for lambdas in some, but not all, cases. Subclassing remains the primary extension mechanism for Wicket components.
Factories for lambdas have been provided for various forms of models (databinding) and behaviors (adapters for components).
If you use Lambdas, you need to store the dynamic functionality and keep a reference to it, which takes additional memory, explained Martijn Dashorst, software engineer at Topicus, The Netherlands, and vice president of Apache Wicket.
Since Wicket pages typically consist of thousands of components, the memory required can add up, he said, explaining why the project opted not to use Lambdas previously.
Features called behaviors allow modification of a component externally. For instance, you can add a behavior to a label component — a label component displays text — and add click behavior to it. When a user clicks on the label, if the behavior is attached to it, it will issue a one-click on the Java side, so developers can add additional behaviors to it.
“It’s very flexible and powerful way to extend the functionality of components. These behaviors are well-suited for using Lambdas. They have limited methods you can implement, so the additional memory burden for using Lambdas for these are not as severe as for components,” he said.
One of the biggest changes in Wicket 8 is data binding for components. Previously, you would use a text string for binding this property. IModel in Wicket 8 is designed as a functional interface, allowing developers to use Lambdas wherever models can be used. The new LambdaModel allows for type- and refactoring-safe data binding of components. It’s a safer and faster way to evaluate Java code, Dashorst said.
In addition, Wicket 8:
- Adds native support for new types for handling dates and times in Java 8. They can be converted, validated and bound to components
- Uses of Java’s Optional type in places needed to clarify the API.
- Requires Servlet 3.1.- a modern server like Tomcat 8.x, Jetty 9.1+ or a Java EE 7-compatible server.
Although developers shouldn’t have to rewrite applications for Wicket 8, the team urges users to consult the migration guide.
In light of Oracle’s plans to eliminate serialization, the project will be looking at other frameworks to handle it, Dashorst said.
The project has long been focused on security at the component and data level, he said, enabling developers to add security checks every step along the way.
Asked how Wicket was secure, given the security vulnerabilities associated with serialization, Dashorst explained that the stored data resides on the servers and is not dependent on Java serialized data that comes from the client. The attacker would have to have access to the server.
The storing of state is not remotely accessible through Wicket — such as from browsers connecting to the Wicket application, he said.
Wicket was one of the projects found to have a vulnerability in the open source project “ysoserial,” but it was only exploitable in a proof of concept and the payload could not be delivered through Wicket.
“So while Wicket is highly dependent on serialization and serialization has security issues, we don’t consider our use of Java serialization/deserialization an exploitable attack vector. Any assailant would need additional access mechanisms outside the control of Wicket to deliver the payload and trick the server into executing the exploit,” he said.
“That said, we are looking forward to implementing new data storage for Wicket’s state-keeping if only because Java’s default serialization is an all-around solution that is relatively slow, uses a large file format and as mentioned earlier is fraught with vulnerabilities.”
Feature image via Pixabay.
