Personal opinion on software development in general, development methodologies, tools and best practices in particular

Archive for the ‘Web’ Category

Vaadin: what’s new

It’s been a while since my last blog post about Vaadin. Summertime you know ūüėČ

But Vaadin was still evolving towards an even better framework. I’ll summarize the new fancy features.

Last week I went to a very interesting talk about Android. THe programming language isn’t Java but is very similar to Java. Creating fancy applications seems still a bit difficult but one can only develop webapps of course. Vaadin also has a framework to develop smartphone applications (webapps) called Touchkit.


A lot of people don’t know that you can develop applications for smartphones with Vaadin TouchKit . These applications have an iPhone look and feel but will run on iPhone, iPad and Android.

TouchKit is optimized to run on smartphones so it’s optimized for low low performance and low memory (ROM) devices.

The well known Vaadin sampler, which demonstrates all Vaadin components along with the Java source code, is also available for Vaadin TouchKit:

If you want to know more about TouchKit (who developed it, why, what’s the roadmap,…) you can read these blog posts:

Add-on directory

The add-on directory that was released this year is a marketplace where themes, UI components, tools, data components and miscellaneous add-ons are distributed to the community. Most of them are free, for some of them you’ll need to have a license.

It’s a very good initiative, no need to write a fancy component because there’s a big chance you’ll find it in the add-on directory. Most of the add-ons have a demo site, source code, project homepage, issue tracker and forum attached. But there was 1 shortcoming: maven integration.

Most Java projects are based on Maven, Spring and Hibernate and Vaadin supported all of these. But if you wanted to use an add-on in your project, you had to download the jar and add it to the classpath. Since I use Maven I do not longer like the idea of commiting jar’s in Subversion. So I added a script to SVN which contained the code to install the add-on jar in the local repository. Next I installed it on Nexus and added the dependency to the pom.xml.

But times change and the guys from Vaadin really listen to the community. They know very well that a framework on itself isn’t good enough. Integration with other common used frameworks is a must these days. So the guys set up a Maven repository, add all existing add-ons to it and all newly added add-ons will be automatically added to that repo.

More info about the add-on maven support can be found here. The code that must be added to the pom.xml file is also available on the add-on directory site.  Easy huh?


Another proove of the fact that Vaadin is still evolving are the amount of talks that cover this framework. Joonas Lehtinen, CEO of Vaadin will present on Devoxx on 17/11/2010:

Another more detailed talk about Vaadin will be the success-story of the conversion of Black Belt Factory (aka Java Black Belt) to Vaadin. It’s scheduled on 30/03/2011 in Brussels and is organised by the¬†¬†Brussels Java User Group (BruJUG).

The talk will take 3h and will be presented by the CEO of Black Belt Factory.

I will attend the talk, and you?


Vaadin, Maven and Spring

Vaadin is a Rapid Application Development (RAD) framework for RIA applications. I only know it for a few months but since I started experimenting with it, I’m really in favor of it.

I see a lot of advantages compared to Sun’s Java EE standard front-end framework JSF.

  • First of all Vaadin is a java library, so you only have to write Java to build a complete frontend. No need for a specific frontend language, no need for converters (for comboboxes),… This also implies that you can use the full Java power on the frontend side and that’s an huge advantage because frontend code is now type-safe and easily refactorable. You can unit test your frontend with JUnit. You can also use all existing java libraries on the frontend side, for example LOG4J.
  • Another advantage is the fact that Vaadin is easy to learn (JSF isn’t!) and to use: it’s straigtforward. It feels like developing desktop apps and for me developing desktop apps feels much more intuitive than developing web-apps the way I’m used to.
  • Vaadin uses convention over configuration. No need to register new components, validators or whatever in different xml files. Themes have a default folder and a default folder structure.
  • Vaadin is very well documented. There’s the book of Vaadin wich explains every aspect of the framework very clear. On the site there’s a blog, a FAQ section, a wiki, a forum, examples with Java source code, …
  • It’s very easy to extend. Want to create your own Validator? Just implement an interface or extend another Validator and use it. Want to create your own custom server side component? Just extend the CustomComponent class or extend from another component. There’s also an add-on directory where you can download UI components, data components, tools, themes, …

But enough about Vaadin itself. The purpose of this blog post is not to explain Vaadin itself in detail but how to integrate it with other commonly used frameworks: Maven and Spring.

Vaadin comes with a plugin for Netbeans and Eclipse. These plugins provide a wizard which makes the creation of a new Vaadin project, themes and components (also client side) very easy, it even provides a WYSIWYG editor but that’s still experimental.

But as expected (or not) the project structure created by the plugin is not the structure I want because Vaadin uses its own structure which differs from the well known Maven structure. Though this is not a big pain in the ass because Maven integration is extremely easy to accomplish. The easist way is by using Vaadin’s Maven archetype:

mvn archetype:generate

There are also archetypes¬†‘vaadin-archetype-sample‘ and¬†‘vaadin-archetype-widget‘. The first one generates a sample Vaadin app and the second one creates a project to illustrate how to create custom GWT widgets (yup Vaadin is based on GWT). Of course the Vaadin library itself can be found in several Maven repo’s. The only shortcoming at the moment is that the add-ons aren’t ‘Mavenized’ yet. You’ll have to download the jar’s manually. But an issue is created fror that and they’re working on it, so it will be there soon.

To enable Spring in a Vaadin app you’ll have to use SpringApplicationServlet as explained here. That’s all.

Since frontend and controller are now written in java, we can inject Spring managed beans into the Vaadin controller classes. Of course we would like to use annotations instead of all those XML config so we would like to make use of the @autowired annotation for example.

To do that we must put the <context:spring-configured /> element in our applicationcontext and enable component scanning by means of the <context:component-scan /> element to scan out controller classes.

The controller classes can be Spring managed by adding the @Component annotation but it sounds acceptable that you don’t want to make some front-end stuff Spring managed. If you don’t want to do that you can use the @Configurable annotation. It¬†marks a class as eligible for Spring-driven configuration.

Now the last thing that needs to be done is AspectJ weaving, otherwise using the injected Services will cause NullPointerExceptions. You could add the maven-aspectj-plugin to enable compile time weaving. The disadvantage of this approach is that you have to do a Maven compile because compiling in the IDE won’t trigger AspectJ weaving.
You could change the project ¬†into a Maven project instead in Eclipse but then everytime you save your file, Maven compilation will be executed and that’s not what we want.

We can use <context:load-time-weaver /> to enable AspectJ load time weaving. This way we don’t have to run a Maven compile to weave. You’ll have to pass spring-agent.jar to the application when running it to make loadtime weaving work. Once this is done, it’s pure AspectJ LTW which can be configured using ‘META-INF/aop.xml’ which is automatically loaded as AspectJ LTW is initialized by <context:load-time-weaver/>. The last step is to pass ‘-javaagent:path/to/aspectjweaver.jar’ to Tomcat’s VM arguments instead of using the aop.xml and load-time-weaver tag.

If you don’t like load time weaving (it makes hot redeployment fail from time to time), you can remove the <context:load-time-weaver> element and the aop.xml file. Instead you can install AJDT plugin for Eclipse. The project will be recognized as an AspectJ project and yhe only thing you need to do is adding spring-agent.jar to the project’s Inpath.

More Vaadin stuff in one of the next blog posts!

Why webapps?

Sometimes I wonder why we are always writing web applications instead of desktop applications. It seems that web applications have a lot of advantages that desktop applications don’t have. But is this really true? Is it because of these so called advantages that most applications are web applications nowadays?

Actually, I don’t know why customers prefer these kind of apps, all I know is that it can be quite frustrating to write them from time to time. First of all you have to know the underlying protocols TCP, IP, HTTP, …) by heart. In fact that’s not really complex but a lot of web frameworks put their specific flow logic on top of that.

JSF for example, Sun’s current web application technology standard: if you do not know the JSF lifecycle by heart, you can spend a lot of hours on fixing stupid bugs which could have been avoided by knowing each part of the lifecycle very well. A common heard complaint is that JSF is just too complex, and I admit, it really is. And wait until you use it together with Spring Webflow, for example to add some extra scopes like page scope, flash scope, flow scope and conversation scope because request scope, session scope and application scope don’t meet your needs. Trying to access JSF’s FacesContext will fail because you need to use Webflow’s ContextHolder. Yet another example of leaky abstractions.

Browser incompatibility
Enough about complexity now, I think I made a point here. Another big disadvantage of web frameworks -maybe the biggest one- is the browser incompatibility. We need to support Internet Explorer (ouch) and firefox in most of the cases and if possible Chrome, Opera and Safari too. The biggest pain in the ass is IE6 -every developer knows that- and still a lot of people and companies use it as their default browser. It has a lot of security problems, doesn’t have tabs, it’s just outdated, but what I hate about it are all the css hacks you need to tackle specific IE6 problems wich can introduce problems in other browsers. Why do customers still ask to support this crappy piece of software? It’s 9 years old! Drop it please!

To solve the browser incompatibility issues a lot of frameworks are created with the aim of letting the programmer only focus on the requirements, the business, the use cases, the functionality, without the need to spend a lot of time and money on fixing these issues. Richfaces, GWT, Wicket, Vaadin, you name it. It’s a rarity but sometimes these frameworks don’t tackle all the browser incompatibility issues very well which means you have to solve it yourself and again, you need to know how the framework works and what it does. So as I said before, the problem of leaky abstractions can never be solved. They will always be there.

Web 2.0 issues
The fact that you sometimes need to fix bugs in those web application frameworks is not the main problem, the real problem is that those bugs are javaScript or css bugs. Ever tried to debug javaScript? Yes there are tools like Firebug but what if the bug does only occur in IE? Good luck! And the web 2.0 evolution makes it even worse, everyone wants Rich Internet Applications (RIA) because they want the rich experience of desktop applications… Why not just writing desktop applications? I guess that would be too easy ūüėČ Oh and then I’m not talking about the need to install a browser plugin to make these rich features available (Flex for example).

AJAX can do a lot, but again, it’s based on javaScript ūüė¶ It’s not only difficult to debug, it’s a client side scripting language. And what I dislike about client side scripting languages is the absence of compile-time safety, it’s untestable and can not be refactored.
GWT’s aim is very good. Just write Java code which will be compiled to javaScript. You can test, debug and refactor it with ease and there’s compile-time safety.
Wicket drops the need to use and know custom tags (like jsp’s core tags, JSF’s default tags, richfaces tags) and lets you write plain HTML. So the markup is done with HTML while the business logic is done in Java code. Components are added to the view in Javacode too. This code is linked to the html page by means of wicket:id.
But Vaadin goes even further, it’s based on GWT which means that there’s no need to use HTML. LayoutManagers are used to do create complex layouts. IMHO the biggest advantage is that Vaadin has very clear documentation (Book of Vaadin) and provides commercial support, something a lot of companies really want and are willing to pay for.

Model View Controller
It seems that finally the strict MVC pattern is introduced into webapps , something I really missed (I don’t wanna think about Servlets: ‘HTML in Java code’ and plain JSP: ‘Java code in HTML pages’). So it’s a good evolution. The core evolution is bringing all features and richness of desktop applications to the web but still I wonder why we just cannot use desktop applications. It’s less complicated, you don’t need any plugins, you can use plain MVC, there’s no browser incompatility, it’s easy testable, dubuggable and refactorable, there’s compile-time safety, you can use events (loose coupling) you have all features available and you can set it up as a client-server application by means of Java Webstart.