Qi4J the next Java? Forget Scala
Published January 9th, 2008 in Beautiful Java, JavaQi4J 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.
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!
Thought about the property when reading on your blog and the examples.
Setting the property does look like this then?
person.name().set(”Stephan”)?
Not sure if that’s a good idea.
person.setName(”Stephan”) seems shorter, so I’d like to have that in the interface but my PersonBean could have a Property name() which is automatically mapped from the interface by Qi4j.
person.name!(”Stephan”) could be done too.
Attributes in interfaces are final, but could they be declared?
public interface Name {
public String name;
}
and Qi4j maps a person.name=”Stephan” call to a setName() in the bean?
Good look with solving the decade old Java property problem.
I wrote about a @Getter annotation
http://stephan.reposita.org/archives/2007/11/24/getter-annotation/
before. get/set should no longer be needed for Java. Wasn’t it just so that GUI builders could detect attributes by looking at the method name? Annotations should solve that.
What I especially like about the Qi4J examples is the @NoEmpyString annotation in the interface instead of the class definition. It’s more like a contract that way.
Just for completeness there is:
Naked Objects
JMaki
Those are both in the same category as Qi4j.
I think they go into a similar direction but differ form Qi4j.
You had me until “JBoss”
:)
@Doug: The brain you know, compared to say Marc. Before it went down. Well intellectually at least. The money went up. But isn’t that always the case? Brains out, money in? Or is it the other way round?
Lots of opinions, less facts.
I spoke to several of the Qi4j-members at the announcement at ÖreDev, and unfortunately I think they’re trying to implement the idea in the wrong language.
Regarding “They implemented Qi4J in the wrong language”. Qi4J is an idea and can be implemented in any language. Qi4R? Qi4P? Qi4S? My only complaint is, they should try to implement this on top of Guice instead of doing their own DI. Sure that would mean compromises but increase adoption. Evolution instead of revolution will win the heart of the enterprise.
> I spoke to several of the Qi4j-members at the announcement at ÖreDev, and unfortunately I think they’re
> trying to implement the idea in the wrong language.
Similar argument we had in a JUG meeting with the presence of Rickard. Some people think that Qi4J is merely a hack and why Java at the first place?
Qi4J is just an implementation of COP and you can implement it with any language. Java is a stronger platform for enterprise development in comparison with other languages and it therefore worth investing. I’m sure a lot of the enterprise folks will welcome this.
- yc
mama keroro hentai mama hentai kazama