Why I won't use Qi4j (yet)

Several months ago I've published short series about Qi4j basics. I was impressed not only by the long list of interesting features, but also by the overall concept of the application architecture that Qi4j offers. Unfortunately I've recognized it's very difficult for me to write an application using Qi4j quickly and here is why. 1. Mixins. When Mixins are very useful feature the way they are implemented in Qi4j doesn't work for me. I had to write a lot of nested classes and was loosing my focus because of this. I'm wondering what was theirs motivation to create this framework in Java not in Scala which has traits already built-in. 2. Lack of good relational DB support. Another obstacle is that it's strongly focused on the object oriented data stores. Well, that's not bad actually, probably in the future we'll use them mostly. But today when at work I've to deal with relational databases this is serious disadvantage. Hiding these relational databases behind anti-corruption layers would work but it also makes usage of Qi4j's UnitOfWork impossible. 3. Testability. Mocking interfaces with properties modeled with Property<T> needs endless effort. (Maybe I didn't find the right tool to do this) 4. Poor documentation. Why the Spring framework is so popular? Because it's very well documented and its codebase is fairly readable - that's for sure one of the reasons. Nothing more to add here. Anyway it's not as bad as it might look like. I appreciate Qi4j's developers for their innovating approach to software development and I'm tracking theirs mailing list carefully as there is a lot of interesting discussions I can learn from. Qi4j is definitely worth to give it a try also to feel the taste of BDD for a while. It's amazing in how many different ways it's possible to write an application in Java.