Red Hat

In Relation To

The Hibernate team blog on everything data.

Fourth bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The fourth bug-fix release for Hibernate ORM 5.0 has just been tagged and published.

There are 52 issues resolved in this release. 20 of those came out of the recent Jira cleanup. Initially that initiative pulled in roughly 750 issues. To date, 66 of those have been resolved - fixed or verified as out-of-date, unable-to-reproduce, etc. An additional 14 have been more propoerly reclassified as feature or enhancement requests rather than bugs. The really cool part is the amount of community help we have gotten in making that happen! Thanks to everyone responding, verifying and even fixing alot of these bugs!

The complete list of changes can be found here. People without a Hibernate Jira account will not be able to access the previous link and can access the changelog in GitHub; the issue I reported with Atlassian has been resolved and is ready for deployment into our hosted environment, I just do not know when that will happen.

For information on consuming the release via your favorite dependency-management-capable build tool, see

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

Red Hat 4 Kids

Posted by Emmanuel Bernard    |       |    Tagged as Off-topic Events

I am ending my day totally exhausted but happy. Today we organised Red Hat 4 Kids in the Red Hat France office.

Every year at Red Hat, we organise a Red Hat Week to celebrate our culture. And in good open source community way, each local office expresses how it pleases this event. This year, I proposed to do a Devoxx4Kids for the children of French Red Hatters.

Red Hat 4 Kids (aka a copy paste of Devoxx 4 Kids) initiates children from 6 to 12+ to the notion of programming. Sharing our knowledge to teach them what daddy or mummy does. Sounds cool.

Scratch workshop

I knew it was doable since the awesome Devoxx4Kids team has successfully declined these events around the world. But my engineering spider-senses told me it would be quite a humongous task. I was right but it’s one of those projects where you need to jump first and think later.

What did we do?

For the 6 to 10 years old boys and girls, we have done a Scratch workshop. Scratch is awesome, it has all the basics of programming: blocks, loops, conditions, events, event sharing, etc…​ Here, not need to prepare much, explain the basics and let the kids go (see below).

For the 10+ kids, we have done the Arduino workshop: programming electronics for the win :) We have reused the Devoxx4Kids one verbatim.

We were also lucky to have the Aldebaran team with us. So the kids moved up from the basics of programming to full Nao robot programming. Nao is a serious guest start and actually easier to program than Scratch :)

What are the challenges?

You need to prepare everything material wise

We installed a fresh Fedora 22 on all laptops to get everything set up the same: this really helped as we did not have to fight different environments. To be safe, we used ethernet and not WiFi: some WiFi routers don’t enjoy too many laptops at once.

Don’t go too long

For the 6-10 years old, they started to slowly drift after one hour. Don’t go over 1h30 per workshops and do breaks between them. For the 10+, they actullally went beyond our 1h30 and chose coding over cakes: success!

Limit the introduction and slides as much as possible

Developers don’t like slides. It turns out kids disregard them after 4 mins top. I had to cut the presentation quickly and instead…​

Do customized assistance

Show them by pair-kid-programming how to do the basic things and let them do what they want: help them achieve their goal: story, adventure, games etc…​ One grown up for one to two laptops, two kids per laptops. Max. They will be much more engaged.

Special thanks

It’s quite a special feeling to see a good chunk of the kids being that engaged, asking tougher and tougher questions over time and preferring coding to cakes.

I have many people to thank for this project. Hopefully I won’t forget too many of them:

  • the Devoxx4Kids team for putting their workshop in open source

  • Audrey and Arun from Devoxx4Kids for giving me customized advice and reassuring me along the way

  • the Red Hat French facilities team for saying yes to this project and putting up with all the material challenges (room size, power outlets, laptop hunt, mouse chasing, etc.)

  • the local Red Hat techies for gathering the hardware, installing the machines, testing everything and helping out during the workshops

  • last be not least, the Aldebaran team for being part of the fun

Nao in action

Just Fracking do it

Don’t think, do it. Go to and start from their workshops.

Third bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The third bug-fix release for Hibernate ORM 5.0 has just been published.

The complete list of changes can be found here. People without a Hibernate Jira account will not be able to access the previous link and can access the changelog in GitHub

For information on consuming the release via your favorite dependency-management-capable build tool, see

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

The Great Jira Cleanup of 2015

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM

What is happening?

In an effort to focus attention on 5.0 and moving forward we will be bulk updating bug reports in Jira which are not indicated to affect 5.0 to request help for folks to verify that the reported issue still affects 5.0

Why is it happening?

Now that ORM 5.0 has gone final, we need to focus our development efforts on 5.0 and beyond.,-Small-Team discusses why we do this. Put simply, versions prior to 5.x are no longer maintained and bug reports which do not affect 5.0 are outside that focus. We are asking your help to verify that the reported bug still affects version 5.0. This is a great help to the Hibernate team and to the Hibernate community.

We realize some of the issues caught up in this process may have already been caught up in the bulk clean up the last time we did it. We apologize, but the last time we did not do a great job setting up tracking for knowing when these issues were verified. This time we will be setting up filters so that we can see which issues are caught up in this process and which have been verified. We will tie those that have been verified into our weekly triage meeting amongst the development team and make sure that the verified issues get looked at.

How will it happen?

Essentially this will affect any issues which:

  • are a Bug report

  • are in the ORM (HHH) project

  • are Unresolved

  • have no fix-for version

  • do not list any 5.0 releases in affects version

This pool of issues is defined by a Jira filter:

These issues will have a bulk update applied to them to:

  1. add the label verify-affects-5.0

  2. change status to Awaiting Response

  3. add a comment indicating that the issue has been included in this process, along with a link to this announcement

What needs done?

As discussed in, we are hoping for someone to champion these bug reports. But really, even verifying them is a great step towards getting them resolved. defines the pool of bug reports waiting to be verified against 5.0. We are asking for help in verifying that these issues affect 5.0. That essentially means writing a test (or adapting an already attached test) to use 5.0 and verifying that the problem still exists. If it does still exist in 5.0, add the specific version used to test to the list of "Affects version/s" for the Jira issue and attach the test used to verify.

After a bug report is verified as affecting 5.0, the issue will move to the This pool of issues will then become part of the triage meeting the Hibernate ORM team has (roughly) once a week to be discussed and either scheduled, resolved or rejected.

Bug reports that sit in the "awaiting verification" pool will eventually be resolved as "Out of Date". Eventually is a fluid term; we have not defined any sort of timeline for when that would happen; but I expect it would be allowed to sit there for months before we get to that point.

JBoss Community Asylum - Infinispan Encore

Posted by Max Andersen    |       |    Tagged as JBoss Asylum

It's been a while but here we go again with an encore about the project that shall not be named. We discuss use cases as well as Infinispan 8 new features, in particular distributed streams and all the new query features.

Recorded by Emmanuel with notable Infinispan guests: Tristan Tarrant and William Burns!

Find it all in the Show notes and episode.

Have fun!

Hibernate ORM 4.2.21.Final Released

Posted by Gail Badner    |       |    Tagged as Hibernate ORM Releases

Hibernate ORM 4.2.21.Final has just been released.

The complete list of changes can be found here.

For information on consuming the release via your favorite dependency-management-capable build tool, see

The release bundles can be obtained from SourceForge.

Second bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The second bug-fix release for Hibernate ORM 5.0 has just been published.

The complete list of changes can be found here.

For information on consuming the release via your favorite dependency-management-capable build tool, see

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

Hibernate Validator 5.2.2 released

Posted by Gunnar Morling    |       |    Tagged as Hibernate Validator Releases

I am happy to announce the availability of Hibernate Validator 5.2.2.Final.

This release fixes several bugs, including a nasty regression around private property declarations in inheritance hierarchies and a tricky issue related to classloading in environments such as OSGi.

We also closed a gap in the API for constraint declaration which allows to ignore annotation-based constraints for specific methods, parameters etc.:

HibernateValidatorConfiguration config = Validation.byProvider( HibernateValidator.class ).configure();

ConstraintMapping mapping = config.createConstraintMapping();
mapping.type( OrderService.class )
    .method( "placeOrder", Item.class, int.class )
        .ignoreAnnotations( true )
        .parameter( 0 )
            .ignoreAnnotations( false );
config.addMapping( mapping );

Validator validator = config.buildValidatorFactory().getValidator();

Please refer to the change log for the complete list of all issues. You can get the release with Maven, Gradle etc. using the GAV coordinates org.hibernate:hibernate-validator::5.2.2.Final. Alternatively, a distribution bundle is provided on on SourceForge (TAR.GZ, ZIP).

Get in touch through the following channels:

Hibernate Search 5.5 Final is out

Posted by Davide D'Alto    |       |    Tagged as Hibernate Search Releases

I’m happy to announce the latest final release of Hibernate Search: Hibernate Search 5.5 Final. We mainly consolidated the features included in the latest candidate release and worked on fixing some bugs.

As a reminder on versions:

Hibernate Search now requires at least Hibernate ORM 5.0.0.Final, and at the time of writing only Infinispan 8.0.1.Final supports real time replication of an Apache Lucene 5.3 index.


WildFly 10, Lucene 5

Last week, we released Hibernate Search 5.4 Final with the minimal set of changes to make it work with Hibernate ORM 5. This version uses Lucene 5.3; if you haven’t upgraded already, we recommend to start with version 5.4.0.Final, first.

Hibernate Search 5.5 will be included in WildFly 10.

Out of the box indexing of java.time types

Hibernate Search is now able to automatically provide a sensible mapping for java.time.Year, java.time.Duration java.time.Instant, java.time.LocalDate, java.time.LocalTime, java.time.LocalDateTime, java.time.LocalTime, java.time.MonthDay, java.time.OffsetDateTime, java.time.OffsetTime, java.time.Period, java.time.YearMonth, java.time.ZoneDateTime, java.time.ZoneId, java.time.ZoneOffset.

That means that it includes an out of the box FieldBridge for each of these types, and allows transparent indexing and querying of properties of these types. You can of course customize the indexing by providing your own FieldBridge, as usual.

This feature is only available if you are running on a Java 8 runtime, although all other features of Hibernate Search are still backwards compatible with Java 7.

Sorting improvements

Since Apache Lucene 5.0 (and including 5.3 as we currently require) we can provide a significant performance improvement if you let us know in advance which fields you intend to use for sorting.

For this purpose a new annotation is available. If you start using this annotation in your projects you’ll benefit from improved performance, but for those who don’t want to update their mapping yet we will fallback to the older strategy.

This subject is discussed in detail in this follow-up post.

Encoding null tokens in your index

When using @Field(indexNullAs=) to encode some marker value in the index, the type of the marker is now required to be of a compatible field type as all other values which are indexed in that same field.

This was problematic for `NumericField`s, the ones optimised for range queries on numbers, as we would previously allow you to encode a string keyword like 'null': this is no longer allowed, you will have to pick a number to be used to represent the null value.

As an example for an "age" property you might want to use:

@Field(indexNullAs = "-1")
Integer nullableAge;

How to get this release

Everything you need is available on Hibernate Search’s web site. Download the full distribution from SourceForge, or get it from Maven Central, and don’t hesitate to reach us in our forums or mailing lists.

Order, ooorder! Sorting results in Hibernate Search 5.5

Posted by Gunnar Morling    |       |    Tagged as Hibernate Search

"Order, ooorder!" - Sometimes not only the honourable members of the House of Commons need to be called to order, but also the results of Hibernate Search queries need to be ordered in a specific way.

To do so, just pass a Sort object to your full-text query before executing it, specifying the field(s) to sort on:

FullTextSession session = ...;
QueryParser queryParser = ...;

FullTextQuery query = session.createFullTextQuery( queryParser.parse( "summary:lucene" ), Book.class );
Sort sort = new Sort( new SortField( "title", SortField.Type.STRING, false ) );
query.setSort( sort );
List<Book> result = query.list();

As of Lucene 5 (which is what Hibernate Search 5.5 is based on), there is a big performance gain if the fields to sort on are known up front. In this case these fields can be stored as so-called "doc value fields", which is much faster and less memory-consuming than the traditional approach of index un-inverting.

For that purpose, Hibernate Search provides the new annotation @SortableField (and it’s multi-valued companion, @SortableFields) for tagging those fields that should be available for sorting. The following example shows how do it:

@Indexed(index = "Book")
public class Book {

    private Integer id;

    @DateBridge(resolution = Resolution.DAY)
    private Date publicationDate;

        @Field(name = "sortTitle", analyze = Analyze.NO, store = Store.NO, index = Index.NO)
    @SortableField(forField = "sortTitle")
    private String title;

    private String summary;

    // constructor, getters, setters ...

@SortableField is used next to the known @Field annotation. In case a single field exists for a given property (e.g. publicationDate) just specifying the @SortableField annotation is enough to make that field sortable. If several fields exist (see the title property), specify the field name via @SortableField#forField().

Note that sort fields must not be analyzed. In case you want to index a given property analyzed for searching purposes, just add another, un-analyzed field for sorting as it is shown for the title property. If the field is only needed for sorting and nothing else, you may configure it as un-indexed and un-stored, thus avoid unnecessary index growth.

For using the configured sort fields when querying nothing has changed. Just specify a Sort with the required field(s):

FullTextQuery query = ...;
Sort sort = new Sort(
    new SortField( "publicationDate", SortField.Type.LONG, false ),
    new SortField( "sortTitle", SortField.Type.STRING, false )
query.setSort( sort );

Now what happens if you sort on fields which you have not explicitly declared as sortable, e.g. when migrating an existing application over to Hibernate Search 5.5? The good news is that the sort will be applied as expected from a functional perspective. Hibernate Search detects the missing sort fields and transparently falls back to index-univerting.

But be aware that this comes with a performance penalty (also it is quite memory-intensive as uninverting is RAM-only operation) and it even might happen that this functionality will be removed from Lucene in a future version altogether. Thus watch out for messages like the following in your log files and follow the advice to declare the missing sort fields:

WARN ManagedMultiReader:142 - HSEARCH000289: Requested sort field(s) summary_forSort are not configured for entity \
type mapped to index Book, thus an uninverting reader must be created. You \
should declare the missing sort fields using @SortField.

When migrating an existing application, be sure to rebuild the affected index(es) as described in the reference guide.

With all the required sort fields configured, your search results with be in order, just as the British parliament members after being called to order by Mr. Speaker.

back to top