Skip to content


Subversion checkout URL

You can clone with
Download ZIP
A Java Immutable object Relational Mapper focused on simplicity, convenience, and thread safety.

Merge pull request #47 from mwanji/support_ConstructorProperties

Basic support for constructor properties
latest commit df4e56d7f3
@agentgt authored

Build Status


Java Immutable object Relational Mapper is a unique Java SQL ORM that allows you to CRUD immutable objects. It is a good match for highly concurrent message driven architectures.


How JIRM is different

  1. CRUD truly Immutable POJOs. That is all fields are final with a constructor that fills them.
  2. Uses JPA annotations to help map the SQL ResultSet to your POJOs
  3. READ's hiearchy of Immutable POJOs. That is @ManyToOne 's are loaded eagerly, but for WRITE we only write the top POJO.
  4. Once the POJO is loaded there is no magic. It is not "enhanced". It is safe to deserialize or cache especially because they are immutable.
  5. Manually do One to Many (ie collections) which IMHO is the right way to do it (because there is nothing worse than accidentally pulling 1000 items).
  6. No hidden lazy loading.
  7. Threadsafe - Most of the library is threadsafe.
  8. Stateless (like Ajave EBean... ie no session factory).
  9. Fluent API
  10. Or you can use SQL with IMHO the best SQL Placeholder templates.
  11. Sits nicely on top of other JDBC wrappers like Spring JDBC
  12. Let your JDBC wrapper handle transactions - e.g. compile time Transaction Support through AspectJ (Through Spring JDBC).

JIRM does all of this and more!

There was also some one looking for one here:


The current version of jirm in the maven central repository is: 0.0.8

If you would like full usage of the ORM, Spring is currently the only JDBC Wrapper supported.


Alternatively if you want to use only the SQL Placeholder templates you only need jirm-core.


You need a JirmFactory to use Jirm. Right now Spring JDBC is the only implementation but it is trivial to support other JDBC wrappers by implementing SqlExecutor interface.

Why choose Spring JDBC? - Because its an extremly mature JDBC wrapper that does most things correctly (exception handling and transactions).

Spring Config:

<bean class="co.jirm.spring.SpringJirmFactory" id="jirmFactory" />

Now in your Spring components you can simply do:

@Autowired //or however you do your wiring.
private JirmFactory jirmFactory;

Now you can create a threadsafe JirmDao for your Immutable POJO like:

   JirmDao<MyBean> dao = jirmFactory.daoFor(MyBean.class);


The JirmDao allows you to CRUD immutable POJO's. Immutable POJO's have all of their member fields final and the fields themselves should be immutable objects. Immutable POJO's require a constructor to instantiate their member fields.

Because immutable objects require constructor based loading of fields we need to make a constructor with all the fields from table (and/or ManyToOne child tables... more on that later).

Unfortuanately the JVM has some limitations on reflection of constructor based arguments so you will have to annotate your constructor with either JDK's @ConstructorProperties or Jackson's @JsonCreator and @JsonProperty

public class TestBean {

    private final String stringProp;
    private final long longProp;
    private final Calendar timeTS;

    public TestBean(
            @JsonProperty("stringProp") String stringProp, 
            @JsonProperty("longProp") long longProp,
            @JsonProperty("timeTS") Calendar timeTS ) {
        this.stringProp = stringProp;
        this.longProp = longProp;
        this.timeTS = timeTS;

    public String getStringProp() {
        return stringProp;
    public long getLongProp() {
        return longProp;
    public Calendar getTimeTS() {
        return timeTS;

Our SQL Table for the bean might be something like (Postgres):

CREATE TABLE test_bean
  string_prop text NOT NULL,
  long_prop bigint,
  timets timestamp without time zone,
  CONSTRAINT string_prop_key PRIMARY KEY (string_prop)

Lets see some CRUD of our immutable TestBean

JirmDao<TestBean> dao = daoFactory.daoFor(TestBean.class);

// You can insert, delete, update, etc...
String id = randomId();
TestBean testBean = new TestBean(id, 1L, Calendar.getInstance());


//Or batch insert 200 beans at a time
Iterator<TestBean> testBeanIterator = other.iterator();
dao.insert(testBeanIterator, 200);

TestBean reload = dao.findById(id);
reload = dao.reload(testBean);

//Explictly update one field.
   .set("longProp", 100L)

//Of course you could update the entire object which will take advantage 
//of opportunistic locking if you have @Version
TestBean updateBean = new TestBean(testBean.getId(), 2L, Calendar.getInstance());
//Or exclude a field from update


//Now lets select some TestBeans.
List<TestBean> list =
    .property("longProp", 1L)

JIRM embraces SQL

When the going gets tough JIRM says write SQL.

JIRM's select, update, and delete builders (fluent api) are generally for convenience of simply tasks. That is because update, delete and insert are pretty simple one table operations. Also most selecting only requires inner joining @ManyToOne children.

As soon as it gets complicated we recommend you write SQL. Luckily JIRM provides awesome support for that.

Besides TestBean mentioned earlier lets say we have another table/object called ParentBean.

public class ParentBean {
    private final String id;
    @ManyToOne(targetEntity=TestBean.class, fetch=FetchType.EAGER)
    private final TestBean test;
    //... snip ...

Now we can select ParentBean using plain SQL by making a SQL file in the classpath we'll call it select-parent-bean.sql.

SELECT    AS "id", 
       test.string_prop  AS "test.stringProp", 
       test.long_prop    AS "test.longProp",
       test.timets       AS "test.timeTS"
FROM parent_bean 
INNER JOIN test_bean test ON test.string_prop = parent_bean.test 
WHERE test.string_prop = 'test' -- {testName}
AND test.long_prop = 100 -- {testAmount}

Yes the above is real SQL with out any placeholders that would break normal SQL parsing. We use comments on the end of the line to indicate a place holder. You can read more about it here.

Besides the comment placeholders the other thing to notice is the use of result column labels for property paths. By using AS "dottedPropertyPath" gives JIRM clues on how to map the flat ResultSet back to a hierarchical object.

Now here is the Java:

JirmDao<ParentBean> dao = jirmFactory.daoFor(ParentBean.class);

List<ParentBean> results = 
      .bind("testName", "test")
      .bind("testAmount", 100)

JIRM's SQL Placeholder Parser can also be used independently of JIRM's ORM functionality.

Something went wrong with that request. Please try again.