Tuesday, 27 July 2010

Comparing approaches to Vaadin and OSGi

Some time ago, inspired by an attempt I saw on their forums, I set about enabling Vaadin (a pretty amazing RIA derivative of GWT) so that it would work in an OSGi container. You can read about that here.

As it happens Peter Kriens and Neil Bartlett both set about doing the same thing, all our efforts completely independent of each other. In this post, I'll compare and contrast the three approaches.

Firstly, Peter and I both decided to use Declarative Services (DS), where as Neil decided to create a light-weight service driven API.

In that regard, the approaches fragment and it becomes difficult to compare Neil's approach with the approach taken by Peter and myself. The main advantage of the service driven approach is that you don't need to use DS. You create an instance of the service interface and register it, then the rest of Neil's code makes that implementation available as a Vaadin application. This is a great approach if you might not want to use DS and doesn't stop you from using it if you want. The main disadvantage here is that there is an extra dependency on the API that Neil has created.

With the DS approach there's no additional hard-dependency, though there is a dependency on DS implied. In both Peter's approach and mine, we simply extend com.vaadin.Application and mark the implementation as a component factory. After this, things differ slightly between my approach and Peter's.

My code looks for components with the property "component.factory=vaadin.app" and once I find matching component factories I take the "component.name" of the factory and use that for the HTTP alias against which to register the servlet that does the work. Peter's approach is to look for "component.factory=com.vaadin.Application/*" and take the name from the part represented by the wildcard. This seems like a more sensible approach, as the component name tends to be more unique and use a domain name type structure, if not the component classname, period. A classname is not really an appropriate HTTP alias.

Vaadin uses a fair amount of static resources. My view here is that in most cases a dedicated web-server should be used to handle static resources (e.g. Apache), in a classic n-tier setup where static content web servers sit in front of 'application servers'. As such I've created a second bundle called staticres which will proxy static resources from the Vaadin bundle, but the recommended approach is to use a web-server. Further more, if your app has additional static resources that are not in the Vaadin bundle then these can be added by creating a fragment containing those resources and setting the host to the Vaadin bundle. My "staticres" bundle won't know the difference.

However, this highlights another major difference between my approach and Peter's. In Peter's approach, he expects wraps the Vaadin jar and turns it in to an internal library, exporting it's packages to the container. However, the Vaadin is already a bundle, so this seems unnecessary to me. The additional downside of this is that if the Vaadin jar is updated by the Vaadin folks, then people using Peter's bundle will either need to rebuild it for themselves, or wait for Peter to release a new version. The approach I have taken allows people to update the Vaadin bundle independently of the OSGi code I've written.

The remaining differences between my approach and Peter's are at the code level. Peter's experience shines through showing much better concurrency handling and support for multiple HttpService implementations, where as mine only supports a single HttpService.

So in Conclusion, Vaadin must be an interesting technology (personally I love it) for three individuals to decide to skin that cat in their own way. While the DS approach I've taken is considerably different from Neil's service approach, there are definitely enhancements to what I have produced that I can make based on Peter's code. To summarise the pros and cons of all three:

Neil's approach:
+ no dependency on DS and does not preclude it either
+ not coupled to any specific version of Vaadin
+ lightweight easy to use API
- additional dependency on non-standard API
- no clear way to handle additional static resources
- may end up using DS anyway

Peter's approach:
+ well defined and sensible use of DS
+ high quality implementation
- no clear way to handle additional static resources
- tight coupling to a specific version of Vaadin

Brindy's approach:
+ not coupled to any specific version of Vaadin
+ additional static resources easily handled
- limited to one HttpService
- use of DS needs to be better defined
- needs better concurrency handling

If you're interested in working with Vaadin and OSGi and want a forum in which to discuss your ideas or get help feel free to join our Google Group.

Tuesday, 6 July 2010

functional programming and java - no thanks!

If this is a sign of things to come in Java-land I suspect I'll be moving on:


Ugly. Very ugly. So ugly in fact, I want to swear. I haven't looked at the strawman proposal yet, and really don't want to, but I suspect there will all kinds of problem with scope.

Functional programming has it's usefulness, it's great for languages like JavaScript for instance, which I think needs it in order to make up for lack of proper OO syntax or semantics.

What would be really useful in Java is autosynthesis of properties. What the hell do I mean by that?

Well any Java programmer knows that they'll end up writing getters and setters for properties, or ignoring them all together and making the instance variables public (I don't!). A useful feature in Java would be a way to reduce the need for getters and setters while retaining binary compatibility.

It's really not hard:

public class Person {
public property String firstname;
public property String lastname;

Which can then be accessed in *either* of the following ways:


And if you really want a getter or setter ... just add it!

public class Person {

public property String firstname;

public property String lastname;

public String getFirstname() {
// Do something funky, return something completely different, or just return the property itself.
return firstname;


public class Person {

public property String firstname;

public property String lastname;

public String setFirstname(String firstname) {
if (firstname == null){
throw new NullPointerException("firstname cannot be null");
this.firstname = firstname;


That's the kind of thing I want added to Java.