A Wicket Diary

About half a year ago the core Wicket team decided that we needed a radical new way of constructing our component hierarchies. This led to the infamous ‘constructor change’. Basically this change requires you to provide the parent of your new component at construction time. The benefit is that the hierarchy for your component is available in the constructor, which opens up a lot of possibilities:

• line precise error reporting in your Java files: can’t find the component in the markup, throw an exception and you know exactly which component violates the hierarchy
• markup attributes available in the constructor: you can manipulate the tag’s attributes directly instead of using an AttributeModifier
• functions as getPage() and getForm() work in the component’s constructor, allowing you to generate JavaScript at construction time, instead of render time (the full path, and markup identfier are available at construction time)
• …

So we embarked on a journey that would define the future of our framework: Wicket 2.0 would be tha bomb, our own shark with frickin‘ lasers on top of their heads, not genetically mutated, bad tempered sea bass. However, the proof of the pudding is always in the tasting and it appeared that more things were harder and less clear to do.

By requiring the parent of a component at construction time, we ‘fix’ the hierarchy and reparenting components, moving them around across the page is really dangerous: what should you do with the markup attributes that are already set in the constructor? Suddenly you needed factories to create dynamic component structures instead of just adding the component to a list…

And if this is not enough, the change is such a major break that existing projects building on Wicket 1.x would never cross the 2.0 barrier. You’d have to rewrite your whole UI layer, which is not very economical. We already realized this, so we kept Wicket 1.x alive and kicking by backporting key features into that development stream. Basically we had 3 branches to keep alive:

1. Wicket 1.2 (our current stable release)
2. Wicket 1.x (head for Java 1.4 and pre-constructor change Wicket)
3. Wicket 2.0 (trunk, using Java 5 and constructor change)

This severely slowed us down. Estimates are for about 25%, but I think it is closer to 50% or even 60%.

So when serious development with the 2.0 changes were done, the culprit that first came up with the change came to the conclusion that the benefits were not as great as the disadvantages.

In my opinion the biggest disadvantage is that we create a rift between the two versions, basically doing a ‘Tapestry’ on our users: changing the whole project between major versions.

When a project decides to completely change, then your users will also look around. If they have to change their application anyway, why not see if there is anything else, maybe even better?

Creating a rift in our community is really not good and therefore I won’t veto discontinuing the constructor change.

We have discussed this change in direction for our framework the last couple of days, and need your input. If you have an investment in Wicket 2.0, then please let it be heard on our user list. We want to know that you use Wicket 2 (our trunk) so that we can use your experience in deciding whether to continue or not with our current roadmap, or that we need to discontinue the constructor change.

PS the Java 5 enhancements will be kept either way. We like them and think they are good for the framework. So if we decide to discontinue 2.0, we will backport the remaining changes in trunk to make the change as smooth as possible.

I’ve been using JMeter 2.2 for recording and running a couple of load tests on our new server. Now a lot of people are suggesting that Swing is ready for the desktop, at least for Linux. Well, my experience with JMeter on OS X is far from stellar:

• copy/paste/etc are not compatible with OS X defaults, but use the *shudder* Windows bindings
• there is no undo
• I can’t get the data copy/pasted into other applications (textmate)
• you never know if jmeter has saved any test script, there is no feedback, and I’ve lost a couple of hours worth of proxied test script generation
• it is a true memory hog

As far as I can see, JMeter is a showcase of everything people expect from a Java desktop application. There is a whole world open for new and better open source projects to build a decent load testing application.

What would constitute good Wicket improvement projects for Google’s Summer of Code 2007? Here’s a list I just came up with:

• add support for new markup languages: WML, XUL, …?
• create visual editor for Eclipse, Netbeans or IntelliJ?
• create comprehensive scalability/performance tests between Wicket, JSF and Tapestry
• expand/improve on Wicket Kronos, a Wicket based CMS
• write a reference manual or a doclet for generating one from our JavaDoc
• write a conference planner for ApacheCon in Wicket
• …

I think this is just a short list, and I guess there are much better ideas than what I came up with. Share your ideas!

Eelco writes on the mailinglist after some (luke warm) discussion on how to test the new custom serialization Johan is building into the next Wicket versions. This is what he wrote:

Hi all,

We’re (Johan mostly) are experimenting with custom serialization to
see whether we could speed things up a bit (which doesn’t mean what we
have now is bad btw).

For anyone working on 1.3: we could use your help testing that
feature. The only thing you need to do is turn it on on your
development machine, by doing this in e.g. your application’s class
init method:

Objects.setObjectStreamFactory(new wicket.util.io.WicketObjectStreamFactory());

And then just report any issues you encounter to this list or the
developers list. Of course, if you have tweaks, test reports etc,
that’d be even cooler.

The default can be set like this:

Objects.setObjectStreamFactory(new IObjectStreamFactory.DefaultObjectStreamFactory());

which is based on JDK’s serialization. If you don’t configure
otherwise, that is what is used.

Thanks,

Eelco

So please help us out here and use the new WicketObjectStreamFactory in your development efforts and create bug reports if/when you find anything wrong.

The promise of this custom serialization is that it will improve the throughput and memory footprint of your Wicket application considerably. So help yourself, your employer and the Wicket community by testing the new serialization.

It seems that around Valentine’s day and carnival the Java open source community is very generous with sending gifts to the general public: first Wicket 1.2.5 saw the light, and now we can reap the benefits of months of ploughing through issues by the Maven team.

The Maven project released the long awaited Maven 2.0.5. Congratulations and celebrations.