I have a class to persist that has only 'final' attributes and only getters. In the mapping document I put <class... mutable="false" ...>. This should handle my class as immutable. When Hibernate builds its session factory it returns this:

net.sf.hibernate.PropertyNotFoundException: Could not find a setter for property username in class xxx
at net.sf.hibernate.util.ReflectHelper.getSetter(ReflectHelper.java:146)
at net.sf.hibernate.persister.AbstractEntityPersister.<init>(AbstractEntityPersister.java:568)
at net.sf.hibernate.persister.EntityPersister.<init>(EntityPersister.java:651)
at net.sf.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:218)
at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:618)

Any idea? Why do I need to have setters for an immutable class? That kills the purpose of immutability.

Having a attribute final does not mean you cannot set it the first time. Thus setter is mandatory

Hibernate need SOME way to set your values - right ?

Besides in the new 2.1 you can use direct field access - then you don't have setters, but have even worse direct field access - what do you prefer ? ;) (remember that the setters can just be private if you want)

Eh??
My IDE strongly opposes declaring a variable final and not having it in the constructor declaration.
And I've always thought that you'll get a compilation error if you try to set final variable after you've created your instance.

hibernate can't inject via the constructor so if you want the property to be loaded from the database it need to be set *somehow*

Many software design gurus advocate using immutability where possible and Hibernate states it is transparent to the domain model. If immutability according to Hibernate means making all setters private (without using final keyword), then fine.

Hang on a sec... In Cavet Emptor final fields are used:



Ah, that's why MonetaryAmountSimpleUserType.java is also present.

Ironicly, there is comment to this in the book:



With all due respect, needing to write a new custom UserType for each immutable class doesn't sound too simple.

I wounder if there was some other solution for using final fields, e.g. reflexion or ... advanced reflexion )

fell free to contribute it ;)

note: for entities to be loaded from the db a 2-phase loading is used and we need the object to be instantiated during that process. That means we might not have the value for the final field until later and hence need a .set method.

Value types like monetary amount is different and can be loaded directly from the resultset and you can write customtypes for it...if you find that too cumbersome then you most likely can write a generic custom type that loads it more generically for more than one type.