Bean Validation, Hibernate Validator (its Reference Implementation) and the Test Compatibility Kit have been handed over to the JCP for what is called the Final Approval Ballot. That's when the expert committee votes for the go / no-go of the specification going final as it is.

We have found a few glitches when working on both the RI and the TCK in the last month but everything is in order now. The biggest visible change for you is that we renamed @ValidateExecutable into @ValidateOnExecution and we added a way to disable method validation entirely via the XML deployment descriptor.

We worked hard to make a stellar TCK. Let's speak numbers: the specification has 549 assertions including 492 testable. We cover 98,8% of them with 1500 tests. Good luck to all future Bean Validation 1.1 implementors :)

Everything is already available for you to use:

• the specification
• Hibernate Validator (the RI)
• the TCK

Enjoy!

PS: If you want regular info on Bean Validation, you should go to the Bean Validation website and enlist to the RSS.

Hibernate Search 4.2.0.Final is ready for download; grab the distribution from Sourceforge or use the Maven artifacts.

Release Highlights

• Hibernate Search now supports Spatial queries: search in a geographic area, sort by distance, and all that good jazz. Check the documentation: we just reorganized to make it clearer and more action focused.
• Apache Lucene 3.6: this version of Hibernate Search is compatible with any 3.6 version of Lucene; the suggested version is 3.6.2.
• Indexing files like MP3, Word documents etc via our integration with Apache Tika for easy extraction and indexing of (meta)data from a large collection of file types.
• Simplified support for JBoss AS 7: we now release a set of tested modules for the JBoss Application Server 7 to simplify your integration.
• Performance improvements for the Near Real Time support.
• General improvements: many minor fixes and some important ones for the MassIndexer functionality.
• Compatibility with the latest Hibernate ORM 4.1.9.Final.

Upgrading

We took care to make it easy to upgrade from the previous stable version; in case of trouble make sure to check the Migration Guide, as we use it to keep track of any change which could have an impact on backwards compatibility. As always when changing versions of Lucene it is recommended to rebuild the indexes.

Get in touch

The easiest way to get in touch with us and other Hibernate Search users is the forums, this is where we provide volunteer-based help (which includes you as well if you can), or if you are a veteran and know you have found a problem you can open a JIRA issue directly. Patches are welcome in any form, but the easiest way is to provide a pull request from GitHub.

Little known fact: you can get support for Hibernate Search when you use JBoss Enterprise Application Platform and JBoss Web Framework Kit from Red Hat.

What's next?

We would like to hear your opinion on what you want next in Hibernate Search. Please share your stories and use cases on the forums to help us shape the future.

Sanne's idea is to work more on the Infinispan integration to cluster your indexes more easily and then upgrade to Apache Lucene 4.x.

Thanks

... to all contributors and everyone else for the motivating suggestions!

Many special thanks to Guillaume Smet and his coworkers for their tests and bug reports and to Nicolas Helleringer for his work on the spatial feature. We have iterated to much on this one it's already at least in version 2 :D

I will be at Devoxx this year again - this starts to look like a pilgrimage ;). But I am particularly excited as I have given it a participating twist: less @OneToMany talks more @Code and @ManyToMany interactions. What can you expect from Devoxx?

Ceylon labs

Monday afternoon 13:30-16:30, I will co-host a Ceylon lab with my fellow Ceylon gang members Stéphane Épardaud and Gavin King.

This is your chance to get your hands on Ceylon. Come with your laptop, we will start with the installation and walk you through your first few Ceylon programs.

Hackergarten

Tuesday all day, I will be there for the Hackergarten. Want to contribute to Ceylon, Hibernate Search, Hibernate OGM, Bean Validation? Bring your laptop and we will hack together. Secret tip: the hackergarten is open to all, not only to Devoxx attendees.

Bean Validation update

I will also speak about Bean Validation 1.1 on Thursday morning to give you an update now hat we have been working on and what you could expect soon in this area.

Les Cast Codeurs

Finally, if I'm not dead by then, I will co-host an episode of Les Cast Codeurs podcast Friday morning with my buddies Antonio Goncalves, Vicent Massol and Guillaume Laforge. It's in French and it's awesome.

Big JBoss presence

I hear that this year JBoss is coming en masse. If you are a JBoss technology consumer or contributor, come and talk to us. If you are not a JBoss technology consumer or contributor, what are you waiting for, come and talk to us ;)

We have been quiet for too long on Hibernate OGM. It is time for us to speak up because we have a lot to show. And to celebrate, we are releasing its first beta.

What is Hibernate OGM

Hibernate OGM is for NoSQL datastores what Hibernate ORM is for relational databases. A way to persist your objects into a native datastore. The good thing is that Hibernate OGM aims at supporting all of JPA features (and the Hibernate native APIs):

• all the mapping annotations, not a selected few
• the APIs
• the semantic (cascade etc)
• and JP-QL

Work on the NoSQL side

We initially started with Infinispan as single backend and we worked our way to abstract it to support more:

• Infinispan
• Ehcache
• MongoDB

Infinispan

We did not stand still on Infinispan. We greatly improved the backend in particular by using the FineGrainedAtomicMap class to store data and benefit from its increased scalability. See more in the performance section later on.

Ehcache

Ehcache was the first to jump on the wagon and propose an alternative backend implementation. Kudos to Alex Snaps and Greg Luck for taking this bet and help us improve our abstraction API.

MongoDB

MongoDB was the first non key-value based NoSQL solution we supported and we worked very hard to make sure the mapping was akin to what a developer would have designed without Hibernate OGM. For example, identifiers are mapped to the _id property and association information is embedded in the entity by default.

    {
        "_id" : "owner0001",
        "name": "Emmanuel",
        "twitter": "emmanuelbernard",
        "bankAccounts" : [
            { "bankAccounts_id" : "accountXYZ" }
        ]
    }

You can override that setting with various other mapping strategies.

We have more ideas we want to implement to optimize the Hibernate OGM - MongoDB integration and we will be working with folks like Jeff Yemin from 10gen to make sure we do the most natural mapping for MongoDB and that our access layer is as efficient as possible.

Note that we have decided to enable the MongoDB safe mode by default in Hibernate OGM as we thought it made more sense for models persisted with Hibernate OGM and because we don't want to be responsible for killing kittens. You can switch this back off of course.

Other NoSQL engines

Expect the list of supported NoSQL engines to grow as we continuously strive to integrate more and more engines to cover the full bandwidth of NoSQL solutions. Come and talk to us if you want to help out! You can either contribute to any ongoing effort or even start a new one. It's not that hard.

Performance considerations

We worked a lot around performance. The project started as an experiment but we did not manage to make it fail ;) So this time around we worked on performance optimizations.

By side effect, we also improved performance of Hibernate ORM - we reuse the same core engine. We also entered a chase with the Infinispan team to see which of Hibernate OGM or Infinispan was consuming the most time in the call stack. We went back and forth a few times and both projects reduced their overhead by a lot!

At the moment, the profiler does not show much overhead on using Hibernate OGM's stack compared to directly using the underling NoSQL datastore.

Query support

While you won't unfortunately see much in this release, we have been hard at work on the JP-QL query support. Sanne wrote a JP-QL query parser that will be flexible enough for our needs. In fact this is also likely going to be the foundation for the next-gen parser of Hibernate ORM.

He has also worked on the first steps to convert a JP-QL query into an Hibernate Search query. This will let you use Hibernate Search as an internal index and query system besides your NoSQL store. This can either replace or complement the query capability of the NoSQL solution.

Today, this solution can answer simple queries already (make sure to use the Hibernate Session API).

We also have been working on integrating Teiid's query engine which will be our way towards complex queries not natively supported by the underlying NoSQL engine. The plan is to combine the JP-QL parser, the Teiid query engine and write native support for the various NoSQL query options.

We have a great plan but that would take a lot of words to explain so let me save that for a future post.

In the mean time, you can use Hibernate OGM and do queries in two ways:

1. use Hibernate Search to index your entities and write Hibernate Search queries directly. What is nice about this model is that it's a natural extension to the Hibernate or JPA APIs (managed entities are returned etc)
2. use the native query capability of your underlying NoSQL store. Because Hibernate OGM tries to map data in a natural way, it's easy to simply query the NoSQL store directly

We hope to show you JP-QL support very soon as the foundations are now built. If you are interested in how we plan on doing queries, come talk to us or go read the architecture chapter in our reference documentation

Community, documentation and download

We worked on many more stuff like better JPA support, better ease of use, less redundant data structures, etc but this post is too long already. Check out the changelog if you are interested.

This project would be nowhere without the help from our community and contributors. Special thanks to:

• Guillaume Scheibel who literally made MongoDB's support happen
• Alan Fitton and Oliver Carr for their work on MongoDB associations support
• Nicolas Helleringer - he is always around somewhere
• Khanh Maudoux for his experimentation around Cassandra
• Davide D'Alto for his experimentation on Neo4J and a few other things
• Seiya Kawashima for his experimentation around Redis and Voldemort

If you are interested in contributing, come talk to us, we have many plans and a humongous todo list.

And guys we took great pain - literally - to write a very good reference guide, so go read it and go download Hibernate OGM.

Enjoy

Every now and then, I am asked if a JPA for NoSQL JSR should be started. Let me share my opinion on the subject.

In short, probably at some point but certainly not today.

I do think there is something to offering an Object X Mapper for NoSQL engines and Hibernate OGM is proof of my belief but jumping on the standardization wagon is a whole different thing.

Trying to standardize something not mature enough or without practical experience on the subject very often go wrong and for good reasons. Cemeteries are filled with dead cold standards that hurt developers. I am a strong believer in standards and Mark our CTO too. But look at what we did for JPA and Bean Validation: take solid and useful techs and standardize them to improve integration with the rest of the ecosystem. That's the same model we use for the data grid JSR.

In Hibernate OGM, we are barely exploring how to properly map data and discovering interesting possibilities such a layer offers. Now would be a bad time to try and set in store rules. Heck, we might even arrive to the conclusion that such tool turns out not being useful after all.

I am of course open to discuss and exchange on the subject and more than happy to change my mind :) You know where I stand, what's your position on the subject?