On Feb 19, 5:14 am, Kevin Wright <[email protected]> wrote: > For the most part, qi4j functionality has been more effectively subsumed > into other jvm languages with a great deal more elegance, this was actually > one of the stronger drivers behind my interest in Scala.
This is not correct, on many levels. First of all, the COP part of Qi4j, allowing the developer to use mixins/concerns/constraints for things like entity modeling, is at this point really only the core of the project. It does these things in an easier way than for example AOP, and Scala cannot do some of these things, especially not if you consider that we have specially designed entities to be easily backed by persistence, which is not the case with Scala or any other language as they don't have that design constraint. Mixins in entities, for example, are lazyloaded so you can easily have 20-30 in one object without problems. They are also tied to the UnitOfWork concept, so concurrency is built-in. Any solution starting from a language point of view will not have this, as they need to be more generic in nature. So if you want to compare the COP part to anything, it would be more fair to compare it to EJB's or things like that. Secondly, as pointed out above, the COP part is just one piece of the puzzle. Then you have the whole layering/modularity features, which I am not aware of is available anywhere else, as a built-in concept. This makes visibility rules really explicit, and makes it possible to really have an architecture in your software that is not just in a Word document, but actually enforced actively. Third, the Qi4j Core deals with all the COP/OOP/DCI stuff, which is important 'n all as a foundation, but we then have an pretty decent set of extensions and libraries on top of it, which is not available anywhere else. Our EntityStore SPI is implemented for roughly 10 backends (mostly NOSQL databases, but also SQL), the Index/Query SPI similarly (I just added Solr as one extension). On the library side I'm personally most excited by the recent CircuitBreaker, JMX management and EventSourcing additions, which help build applications easily with those kinds of features. So, all in all I would suggest that to look at Qi4j and say that it is implemented more nicely in other languages is simply to miss the point, probably due to ignorance of what it actually does. It's a lot more than just the composite thing. At this point in time, one key thing that I want to deal with, apart from the DCI goodness that gives COP a theoretical framework for why it is necessary, is the fact that so many want to work with NOSQL databases, but run into various problems such as lack of querying and reporting. With the inclusion of EventSourcing as a key library we can now integrate a whole bunch of data sources that each does its thing (snapshot storage, index/query, reporting), and with the possibility to replace any of them easily. This is as far as I know a unique opportunity that Qi4j presents, and which should make it very attractive for developers who want to use those kinds of technologies. It is somewhat frustrating then to see comments like the above, that misses the point entirely, but c'est la vie. If you have any more questions on this, please let me know, and I'll try to fill in the details. /Rickard Qi4j founder Java Champion -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
