Today we release Firebase 1.9.0-CE (and of course also EE for our enterprise customers). It’s been 6 months since 1.8.0 and we’ve been using 1.9 internally for approximately 2 months now, including within a very active development project. This release can be described in two acronyms: JPA and JNDI. By adding JNDI within the server and removing JPA we’ve made it significantly easier to actually use JPA. The king is dead! Long live the king!

Our issues with JPA as it was in earlier releases was that Firebase supported persistence archives as a deployable unit. But in order to do that we had to bundle a JPA provider, in our case Hibernate, together with the main release. And this would perhaps have been enough if not for two problems: first of all we needed to patch Hibernate to allow it to reside in a sibling class loader; and secondly the JPA interfaces needed to be loaded by the system class loader.

The first problem stemmed from a design problem in Hibernate: it assumed that it was loaded by a direct ancestor class loader to the entities themselves. However, in Firebase this is not the case, any deployed unit is isolated from the Firebase internal class loader in order to not confuse library versions. After all, we don’t want to limit our developers to the set of libraries we use. You’d think that this would work: after all JPA is a set of discreet interfaces, and so as long as they are shared between the class loaders, the Firebase internal and the deployed units, all would be great. But no…

And then the second problem: the persistence API jar was loaded by the system class loader. But if you wanted to use another version of JPA? Well… Good luck. That would lead you into all sorts of strange behavior. Not the least because the Persistence class caches loaded entity manager in a static context. And since it was loaded by the system class loader you actually break the class loader sandboxing. Not. Nice.

And now? It might seem counter-intuitive, but now using JPA is much easier. You simply include your provider of choice and instantiate an EntityManager the usual way:

EntityManagerFactory emFactory = Persistence.createEntityManagerFactory("my-entities");

Any DataSource deployed will be picked up by the persistence configuration and you’re set to go! This also means that it is now altogether trivial to use Spring or Guice to setup your DAO’s and entities. Of course, you need to use JTA if you don’t manage the transactions yourself. But watch this space: support for Guice Persist and Spring Transactions are coming your way!