Qi4J the next Java? Forget Scala
Qi4J is the new kid on the block. Forget Scala (not although but because Bruce Eckel, the author who switches hypes faster than other people switch their underware, declares Scala to be the next big thing). Scala helps you solve CS problems nicely, but not business problems. Qi4j is about composite oriented programming. It’s designed to solve business problems. One of the brains behind Qi4J is Rickard Öberg, the brain behind JBoss. He is one of those geniuses who know that their cleverness hasn’t anything to do with the language they use. Other devlopers think that the tools they use make them into a genius (by association) and dismiss Java in favour of Ruby or Lisp or OCaml or Haskell or Lua. Some even think that Java spoils you for everything. What?
Another of those geniuses is Bob Lee, about whom I said in my Sourcekibitzer interview: “He wrote Dynaop, the best AOP for Java, Guice and now is part of the promising Web Beans project. A very friendly and extremly clever guy – swimming outside the mainstream with better ideas until all others get it too ;-) His style of coding looks aesthetically very pure to me and I like it very much.”[1] I guess the same thing could be said about Rickard.
Back to Qi4J. Why could Qi4J be the next Java? Qi4J tries to solve one of the holy grails of computer science: reuse. Their goal is to create applications by composing, not by writing code. Their solution is to decompose Java objects into fragments. This happens in two dimensions. Horizontally objects are decomposed into mixins. Vertically objects are decomposed into mixins, concerns, constraints and side effects. By splitting a Java class into much smaller fragments with specific roles they hope to increase the reuse of those fragments. So one does no longer write code but compose those fragments into bigger composites.
- Mixins: Containing state, e.g. Name, Person, Adress
- Concerns: Statelessm e.g. TransactionWrapper, Security
- Constraints: Checking parameters, e.g. NotNullConstraint
- SideEffects: Managing side effects, e.g. sending Mail
An example for a PersonComposite could look like this:
@Concerns({Security.class, Transaction.class})
@SideEffect({MailNotification.class})
public interface PersonComposite
extends Person, Name, Adress, Composite
{
}
The PersonComposite is build from a Person (handling e.g. gender), a Name (handling firstName and lastName) and Adress (handling street). The extension of Composite doesn’t look that nice, perhaps they change this in the future. A developer can now use PersonComposite and call getFirstName() and getLastName() on the composite. If he creates an Employee class he can compose it the same way and reuse Name. For storing a House he can reuse Adress.
Qi4J provides standard fragments like a PropertyMixin. With this mixin your Name only needs to look like this:
public interface Name
{
public void setName(@NoEmptyString String name);
public String getName();
}
and Qi4J will fill in the actual state-handling code.
Why is Qi4j probably the next Java? Java is an enterprise language. It solves enterprise problems best (technical, deployment and organisational/ socialogical problems). Other languages solve time-to-market-VC-funded-startup problems best. Still other languages solve computer science problems best. The next language needs to solve my enterprise problems better than Java does, which means fixing Javas holes. One hole is reuse, one is tight coupling, one is dependencies. JavaNG needs to solve those. Does Qi4J help? I might think yes. It has nice ideas and adresses some of the Java problems I have in the enterprise. If DDD takes off, Qi4J or frameworks like Qi4J will take off too.
Qi4j has lots of other goodies I’ll explore in another post.
Thanks for listening.
[1] Beautiful code doesn’t depend on the language. I like modern art. I can see beauty in modern art. Not in all, but in some. I’ve argued with a lot of people who do not see beauty in modern art. Those people believe only using oil on canvas drawing people can create beauty. The same goes for the argument that you need a special language to write beautiful code. You do not. I believe there is beautiful Cobol code around. And I wrote such beautiful programms in 68k.
You can leave a Reply here. Of course, you should follow me on twitter here.
Thanks for the kind words! The only thing I have to add really is that we are currently looking into explicit support for properties, which means that declaring the Name interface will look something like this instead:
public interface Name
{
Property name();
}
As you wrote, the implementation will be provided automatically, so this is all you have to do. This will allow you to work with properties much better, get meta-information about them easily (example: “person.name().getPropertyInfo(DisplayInfo.class).getLabel()”), do UI binding, etc.
It’s all work in progress, but I agree that I think this has good potential for solving a bunch of the problems with current software development in Java. Time will tell!