The unholy legacy of databases

When reading about the status of Qi4j on Rickards blog, I stumbled about

Entities are really cool. We have decided to split the storage from the indexing/querying, sort of like how the internet works with websites vs Google, which makes it possible to implement really simple storages. Not having to deal with queries makes things a whole lot easier.

We made the same experience when we developed the SnipSnap wiki application several years ago. We had a split in storages and search, each part with it's own Java interface (a component could implement both of course). This way we could have Lucene, database and in-memory search and database and file (XML, plain text) storage. We were very flexible with storage and search this way and people could easily implement different storage backends because developers have been freed from the search implementation. Rickard seems to have made the same experiences:

We have one EntityStore based on JDBM (persistent binary hashmap), one on JGroups (replicated cluster hashmap), one on Amazon S3 (for global storage), and one on iBatis (for RDBMS storage)

So today SnipSnap would easily be able to supply a S3 backend, because of the split, whereas others which rely on the storage/search combination have much more problems to support a storage-only backend. So they have problems to support S3 or WebDav out of the box.

Why don't more people split the problem of storage into storage and search? After some contemplation on the topic, perhaps it's the unholy legacy of databases. Databases make it easy to solve the search/storage problem with only one technology. After 30 years of databases the problems have merged in a way that most developers think of them as one problem. By splitting the problem again, projects will be freed for better backends and better search solutions. Open Source projects will emerge which adress each of the problems better than current databases do.

This of course breaks the DAO pattern and the usage of the EntityManager as an DAO replacement and should be replaced by a Storage and Search pattern. Free your mind! Storage and search are two different things, if you split them, you gain flexibility.

Thanks for listening.

Mutable, Immutable and Generics

Immutable objects help with avoiding bugs. Suppose I have two interfaces implementing the Immutable Interface pattern. One interface for Point and one with MutablePoint. The pattern suggests a cast to ImmutablePoint p; ((Point)p).setX( 1.0 ); get the mutable interface. This isn't safe and can be replaced with a Generics solution.

First we have the mutable point:

public interface MutablePoint {
   public void setX(int x); 
   public void setY(int y);

which we want to create from an Immutable object without a cast:

  Point point = point(10,10);
  MutablePoint mPoint = point.makeMutable();

The second benefit beside the missing cast is that users of the Point interface know there is a mutable interface which they can get in a defined way.

The makeMutable() method comes from a generic interface called Mutable

public interface Mutable<T> {
   public T makeMutable();

which is extended by the Point interface.

public interface Point extends Mutable<MutablePoint> {
   public int getX();
   public int getY();

Our Point implementation now only needs to implement MutablePoint and Point. Voila.

public class DefaultPoint implements Point, MutablePoint {
   private int x = 0;
   private int y = 0;
   public DefaultPoint(int x, int y) {
      this.x = x;
	  this.y = y;
   public int getX() { return this.x; }
   public void setX(int x) { this.x = x; }
   public int getY() { return this.y; }
   public void setY(int y) { this.y = y; }

   public Point point(int x, int y) {
		return new DefaultPoint(x,y);
   public MutablePoint makeMutable() {
      return this;


A negative side effect is that people who have a reference to a Point object can get a mutable version. When the main point is to have more immutable objects. The other way round is often better, have MutablePoint and create an immutable version.

Thanks for listening.

Update: As pointed out, making an mutable object from an immutable one will break the contract, as will making an immutable one from an mutable one. You do need to copy the object to be safe. For example with a BeanCopier or a copy constructor I've wrote about in Beautiful Java: Reflection and the BeanCopier. Better name the method asMutable than makeMutable

public MutablePoint asMutable() {
   return new DefaultPoint(this.x, this.y);

John Resig on ExtJS, the GPL fiasco and open source community style

It seems as it does not end.

Reading a comment from John Resig, the (or one of the geniuses, sorry if there are more 🙂 genius behind jQuery, a library which was for some time a basis for ExtJs (beside YUI), irritated me a lot.

We (the jQuery project) worked hard with them to try and fix bugs and add features for an ExtJS integration layer. They turned around and built their own, specialized, library (removing the need for any of our work) and then mutated the licensing into this bizzaro scheme that they have now. We can't, in good consciousness, even recommend their library anymore due to its very nature. On top of this they ended up hiring our lead evangelist to promote their work. I can't speak for everyone on the team but I feel quite frustrated and used.

I'm speechless about the style of ExtJS. Without the not correct comments on my blog by Jack I wouldn't believe someone could act this way.

I think you are missing the point. This has nothing to do with money, we are doing fine financially. It had to do with cleaning up what had until 2.1 been a hodge-podge of licenses that came out of necessity into a clean simple licensing structure that is aligned with what we expected all along.

says Jack. Sure it's about money, everything could be clear - or to most people is clear - with the LGPL. No need to switch to the GPL at all. When it's about being open source, switch to the ASL. And I find it highly irritating how Jacks kids are always dragged into this ydiscussion as in "my kids are waking up so I have to cut this short." and "With my third child due, and savings running low". I have no kids on my own but most certainly not drag them into a business discussion as an excuse.

Funny thing: "Ext JS is currently asking for input on two FLOSS exceptions to help make open source usage of Ext JS more flexible." if this plays out like the switch to LGPL or GPL, hooray another episode in this mind boggling soap opera.

Update: "The intention of this exception is to allow for more liberal licensing of extensions, language packs, themes and open source developer toolkits and frameworks for Ext libraries under a variety of open source licenses." on their blog.

Sure, because the more liberal the licenses of extensions are, the better it would be for the commercial side of ExtJS. Best to have the extensions as Apache licensed code and ExtJS to be GPL. The Ext LLC can reuse and resell the extensions without bothering. "(Note: this exception is not for applications and does not grant any exception for the library itself. A FLOSS exception on the libraries for open source applications will be addressed in the exception discussed in “Next Up” below)." This is so ridiculous and gives Open Source such a bad name. They hurt everyone who tries to make a living in the open source space.

Another ExtJS GPL thought – Should extensions switch to the GPL?

Sorry, this would better go to twitter - but I'm not twittering.

Another thought. And not because I want to bash ExtJS, but because I've been interested into the GPL, open source licensing and the implications for over a decade.

IANAL. The best situation for the company behind ExtJS would be if extension developers stay with the LGPL for their extension (or switch to a more liberal Apache license). The people who buy the OEM license from Ext can then use the extension. If someone releases his ExtJS extension as GPL, to be more "in line" with ExtJS, people with the OEM license cannot use the plugin, because it's GPL (they can use the extension in a way that their customer need to download and install the extension on his own, but this is most often too cumbersome for customers. They are not allowed to distribute their commercial application with the extension or any code which references the extension).

The plugin writers do not gain anything for staying with the LGPL license, but Ext LLC gains a lot. It makes their OEM license much more valuable. If every Plugin writer switches to the GPL version, this could have an impact on the OEM sale. Especially because most enterprise won't touch GPL software.

The best for a plugin author is to also go to a dual GPL/commercial license.

Very interesting situation.

Update: Very interesting