I'm Petter Holmström and I work as a software architect at Vaadin Ltd. in Turku, Finland. My official title is "Vaadin Architect" since all of our titles start with Vaadin, but this does not mean that I'm the architect of the Vaadin framework.
The projects I'm working on are customer projects where Vaadin is used as the user interface. I actually do very little Vaadin coding in these projects since my speciality is all the stuff that happens below the user interface. I deal with matters like decomposition into modules and layers, intra-module communication, object persistence, integration with other systems, etc. For complex or large user interfaces, I'm also involved in designing the architecture of the user interface.
Why Vaadin is Special
Well, for starters, Vaadin is special because it is made by the company that I work for which naturally means that it is included in practically all projects that I work on. However, this is not the main reason why I like Vaadin and even if I left the company I'd still continue to use it.
To be completely honest, I had not heard of Vaadin until I joined the company back in the autumn of 2009. Before this, most of my applications had user interfaces written in Swing, since I thought that conventional page-based web user interfaces were not versatile enough for my needs. I used Java Web Start quite a lot as it provided a nice way of deploying the application and distributing updates. I still keep Swing and JWS in my toolbox and use them where I think a native UI is more suited than a web-based one.
- The thing I like most about Vaadin is that it allows me to easily do stuff in the browser that I previously used Swing for. A Vaadin application does not feel like a web application, it both feels and behaves like a native application running inside your browser and you don't need to know any HTML or CSS in order to accomplish this.
- Vaadin also takes care of the differences between browsers, making sure that all Vaadin components behave and look the same in the most popular browsers (IE, Firefox, Safari, Opera, Chrome, iOS and Android). For enterprise applications this is great news, as it is a lot easier to deploy and maintain web-based applications than native applications that have to be installed (and updated) on every workstation.
- Another thing I like about Vaadin is that it allows me to write user interfaces in pure Java, making it possible to utilize the full power of OOP in the UI-layer as well. Abstract classes can be used to implement common features that are required by several views, re-usable components are easy to write and you can use patterns such as Model-View-Presenter to separate user interface logic (e.g., what happens when the user clicks a button) from user interface construction (e.g., the creation and positioning of the button and registration of click listeners).
Vaadin, Maven, and NetBeans
Inside our company, Eclipse is still the dominating IDE for Vaadin application development. The primary reason for this is most likely that our Vaadin plugin is built for Eclipse. However, on my private or CF (Community Friday - every Vaadin employee may use 10% of their work time on their own projects, provided that they meet some conditions) I almost exclusively use NetBeans.
- First of all, NetBeans has a lot better Java EE support than Eclipse. It is more stable and I feel IDE-support for new features become available more quickly on NetBeans than on Eclipse. When it comes to writing JEE software, NetBeans makes the developer's life easier.
As for Vaadin, it is just as easy to write Vaadin applications with NetBeans as it is with Eclipse as long as you are not using the Visual Editor or custom widgets. The compilation of custom Vaadin widget sets is a bit more complicated in NetBeans. You have to manually configure your Ant or Maven scripts to do the compilation for you, whereas in Eclipse you just have to click a button.
- Second, NetBeans has a lot better Maven support than Eclipse. My relationship with Maven is two-sided. On the one hand, project dependency management is easy (most of the time at least). I don't like hunting JARs around the web and debugging ClassNotFoundExceptions and NoClassDefFoundErrors to satisfy the dependencies.
On the other hand, Maven forces you to use a certain project setup and a certain build-cycle. As long as you stick to the defaults, you're fine, but if you need to build a customized JAR or import dependencies that are not managed by Maven, you're in trouble. Another potential problem is maintainability. Let's say we have a Maven-project that will be maintained for 10 years. What guarantees do we have that the maven repositories are still available in 10 years and still contain the versions of the dependencies that we need? I know there are ways around this problem (such as local repositories), but it is still something that has to be taken into account.
Features Missing From Vaadin, Maven, and NetBeans
Since I know there are several improvements coming up in Vaadin 7 and I have not yet had the time to familiarize myself with them, I'm going to concentrate on Maven and NetBeans in this section.
There are a few features in Eclipse that I miss in NetBeans:
- A good plugin for unit test code coverage. I use Eclemma all the time in Eclipse when I write Unit tests. In NetBeans, code coverage is only available when using native NetBeans projects. For Maven-based projects there is no easy way of viewing the code coverage. Also, I'd like to be able to show the code coverage in a Maven-based project without having to configure some code coverage plugin in my POM.
- Save actions. In Eclipse, you can configure different things to happen every time a file is saved, such as formatting the code, fixing imports, cleaning up white space, etc. This I have not been able to do in NetBeans.
- Mac OS X integration. Eclipse feels better on Mac OS X than NetBeans. In my opinion, the native UI of NetBeans when running on OS X takes up too much space and seems to be a bit sluggish. I like the Metal-version better, it feels both more responsive and more compact. I'd like to be able to run NetBeans with a Mac OS X menu on the top of my screen, but with all other UI components using the Metal LoF.
The two screenshots below demonstrate the differences between the OS X look and feel and the Metal look and feel. The editor toolbars and the Projects window are more compact in the Metal LoF, whereas the main toolbar and editors are about equal in size. Visible is the code you have to (manually) write in order to use a custom widget set in a Vaadin application.
As for Maven, there are three main features I'd like to see:
- I'd like to be able to use a different markup language than XML when creating the POMs. There is just too much boilerplate code that is required to set up a JEE project (even though there are archetypes that can auto-generate most of it for you). Preferably the POMs should be written in a script language to allow for full customization. BuildR is a step in the right direction, but has limited IDE support.
- It should be easier to add JARs to the classpath that are not in the Maven repository but in a local lib-directory inside the project.
- It should be easier to completely customize the packaging of a JAR, e.g., by running a custom script.