On the project I work on, we have an in memory model of some particularly useful data (a POJO model as it were). A situation that regularly occurs with this useful data is that various groups want the data sliced and diced in various manners.
Each time a request comes in we have to write a new method that iterates through our collection, sometimes making a new comparator and then return a subset of the objects. I've often wished for a way to just query those objects without having to put them in a database or writing my own domain specific language. Anyone who tells you domain specific languages (DSLs) are a good idea is trying to sell you a DSL framework.
Hibernate's HQL looks pretty sweet, and if there was a way I could just toss objects into a second level cache without a database and do HQL on the cache, that would solve my problem. But I can't.
Java 6's jmap tool has OQL support, but it seems to be a custom OQL implementation for jmap. I did some digging around and the closest thing I could find that would OQL on a collections of objects was db4o which is effectively commercial for my purposes.
Then I ran across JoSQL. It's exactly what I'm looking for. From some poking around, it's fairly decent performing. A large amount of time is spent parsing queries so preparsed queries are in order. Plus, the query objects are not thread safe, so those preparsed queries will need to be in an object pool. Not a big deal.
Lastly, its syntax for handling objects with lists is a bit awkward. As an example, instead of "SELECT * FROM recipes WHERE ingredients.name = 'butter'", you would need to write "SELECT * FROM recipes WHERE (SELECT * FROM ingredients WHERE name='butter')". These sub-selects continue to nest as long as your model has collections of collections.
It's nice since most decent developers know enough SQL to get by, and it's a lot faster to write a query to say "show the top five most popular recipes with butter in them posted in the past 30 days" in SQL than it is in Java. JoSQL supports returning queries as a TableModel too, which could potentially solve some "I want to see my data in fifteen different configurations" issues I'm dealing with too.
Overall, I was quite impressed! If I get time to add it into my project, I'll post an update.
