Guice Persist with Private Modules

When almost two decades ago ORM libraries (like Hibernate) entered the scene everyone was thrilled. It was a game changer for small projects that required database access. There was no more need to tediously reinvent your in house database framework every time you had to start a new project. It was very liberating. Years later introduction of JPA only made things better by standardising certain practices and removing glaring incompatibilities between the vendors.

Years pass and what used to be fresh is now old. What was succinct is now a definition of a boiler plate code. Especially if you have chosen route of application-managed Entity Managers. The constant need of creating and closing them seems almost a sacrilege in the age of injections and functional programming. Still using full blown JTA does not feel right for a small projects that needs to read few lines from the database.

That’s where Guice Persist comes in. It’s an extension that builds upon Google’s successful dependency injection (IoC) library: Guice, that many use and love. It comes with few interesting features and should help trim some code.

For the purpose of this article I have create a fictional project, dealing with authors and books, that showcases transition from application-managed Entity Managers into “guice-managed” Entity Managers.

Lets start with looking how DAOs with application-managed Entity Managers could look like for the fictional AuthorDao that allows you to create and find an entry for an author:

And here is how Guice Persist can simplify things:

Looks better, doesn’t it? We have managed to remove 5 lines of code per method by getting rid of those pesky try-catch expressions.

Guice Persist does also something more subtle. It removes the need for YOU to remember that every time you create an Entity Manager you have to dispose of it at the end. I think anyone that has spent few hours troubleshooting and application that is generating deadlocks will appreciate that one.

So win all around right. Yes?

Well for the most part. Magic seldom happens on it’s own. There’s always a man behind a curtain that pulls some leavers to make it happen. In this case “the man” takes a form of a Persist Service that needs to be started and stopped at appropriate times in your application in order for Guice to be able “magically” create and dispose of those Entity Managers .

So your application usually ends up looking something like this:

No problem. Right?

Right … unless you need to connect to multiple databases in the same application.

You see, above example assumes that everything is bound publicly which gives you access to Persist Service anywhere in your app. Problem starts when you trying to install two separate instances of it. Guice Persist binds everything by theirs primary interfaces (EntityManager.class, EntityManagerFactory.class, PersistSevice.class, etc.) which if you do twice would lead to disambiguity and Guice raises an error when that happens.

Luckily has a dark horse in play for situations like this. Guice Persist wiki suggest to use so called “private modules” that allow you to bind instance and install modules only in the private module’s context (only elements you expose are visible outside its scope). Great! It looks something like that:

This will nicely hide Guice Persist behind a wall of private module and the only thing exposed is the dao interface. So what is the catch? The catch is that when you do that you loose access to Persist Service as well.

So what do we do now? 🙀 It looks like there might be an easy way out as private modules offer facility to expose binding by annotating it.

After that it’s just a matter of starting the exposed Persist Service as before. ✌️

That’s all for now, folks! See you soon.

Related posts:

Legends tell of a place where no man can tread, a place shrouded in darkness and full of terrors. For generations, man had no idea what such a place was called, across the years it had many a name…

According to the study by Persistence Market Research, the water pump market in Thailand is anticipated to grow at ~6% CAGR during the forecast period. Persistence Market Research (PMR) recently…

NFT digital twins have become the next big play for luxury brands’ adoption of blockchain technology. From Nike CryptoKicks to Breitling and Vacheron Constantin’s ‘digital passports’ to Dolce &…