Posted on

Writing a Java Library for 2 AM

Writing a Java library for 2 AM is easy with hrorm

We are spoiled by Java. For almost any programming task, you can imagine there are many freely-available, open-source projects you can choose from. If I was managing a team and they came to me suggesting that we write our own ORM framework, I would send them home and tell them to come back when they sobered up.

You may also like: Introducing Hrorm: A Simple, Declarative, Type-Checked ORM

Nevertheless, when I was working on a personal project beginning last year, I could not find what I wanted, and so I began hrorm. I've written some articles about hrorm (for example, here) that describe some aspects of hrorm. In this article, I want to talk about some of the questions I faced in writing hrorm, and why I made some of the choices I did.

Posted on

Introducing Hrorm: A Simple, Declarative, Type-Checked ORM

A Question

A lot of cyber ink has been spilled about the problem of connecting models in Java code with models in relational (SQL) databases. The topic of object-relational mappings (ORMs), is indeed rich, and the full scope of things you might want to do to transfer information between an application and a database is enormous. Many ORM tools attempt to cover as much of that space as they possibly can; their designs and implementations provide for a great deal of flexibility and they are packed with features.

Of course, to achieve that flexibility, they are burdened with complexity. This is not their fault: Java and SQL are quite different worlds and covering all (or even many) of the ways to pull them together is intrinsically complex. What about a different approach? What if instead of designing an ORM tool to handle a wide variety of object and schema models and all the accompanying use-cases, an ORM tool was designed with some assumptions in mind about how objects and schemas look and work and how they are used? How simple could an ORM tool be?