# (Im)mutable java RM? (Was: Re: Improving the minimal terminology service)

**Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154)
**Created:** 2007-12-17 12:03 UTC
**Views:** 5
**Replies:** 3
**URL:** https://discourse.openehr.org/t/im-mutable-java-rm-was-re-improving-the-minimal-terminology-service/12673

---

## Post #1 by @erik.sundvall

Hi Humberto and others\!

There is a zip at
http://www.imt.liu.se/~erisu/2007/mutable_immutable.zip with a small
test \(including java\-code and comments\) of an approach that possibly
would let us have a choice of both mutable and immutable classes and a
conversion mechanism between the two\. Please have a look and comment\.

There was a lot of mail discussion before this regarding arguments for
and against \(im\)mutability, some excerpts to start searching the mail
archives from are listed below\.

Something like a summary:
http://www.openehr.org/mailarchives/ref_impl_java/msg00380.html

Discussions regarding setters \- if you have mutable objects that you
want to populate piece by piece it is not enough to have validation in
the constructor as for immutable objects \- am you might \(e\.g\. in a
GUI\) want to allow "invalid" states for a while and the choice \_when\_
\(and where in a distributed system\) to validate may vary depending on
system setup:
http://www.openehr.org/mailarchives/ref_impl_java/msg00327.html

Some background to the above comes from the very long thread
"Hibernate and RM" starting with\.\.\.
http://www.openehr.org/mailarchives/ref_impl_java/msg00210.html
\.\.\.some examples from followups in that thread regarding
\(im\)mutability and/or validation \(others might want to highlight other
messages\)\.\.\.
http://www.openehr.org/mailarchives/ref_impl_java/msg00212.html \(ES\)
http://www.openehr.org/mailarchives/ref_impl_java/msg00221.html \(TB\)
http://www.openehr.org/mailarchives/ref_impl_java/msg00231.html \(ES\)
http://www.openehr.org/mailarchives/ref_impl_java/msg00256.html \(RC\)
http://www.openehr.org/mailarchives/ref_impl_java/msg00285.html \(ES \-
a bit of my summary\)
http://www.openehr.org/mailarchives/ref_impl_java/msg00286.html \(RC \-
reply to the above\)
http://www.openehr.org/mailarchives/ref_impl_java/msg00345.html \(ES \-
suggesting branch\)
http://www.openehr.org/mailarchives/ref_impl_java/msg00353.html \(TB \-
multiple validations\)

The svn branch mentioned above and that I'd recommend to use for
experimenting with changing immutable things to mutable is:
http://www.openehr.org/svn/ref_impl_java/BRANCHES/immutable-experiment/
It has not been updated recently so it's probably a good idea to start
by getting the latest changes from the main trunk in \(should be fairly
easy\)\. Last time that operation looked like this:
http://www.openehr.org/mailarchives/ref_impl_java/msg00450.html

Best regards,
Erik Sundvall
erisu@imt\.liu\.se    http://www.imt.liu.se/~erisu/    Tel: \+46\-13\-227579

> \[\.\.\.\] Also, may I make a "mutable experiment" \(a new branch\) of the RM and
> AM? \(This will turn my life much better\.\.\.\)
> > Regards,
> > Humberto Naves
> >

On Dec 14, 2007 6:58 PM, Erik Sundvall <erisu@imt\.liu\.se> wrote \(off\-list\):

---

## Post #2 by @system

Erik Sundvall schreef:
> Hi Humberto and others\!
>
> There is a zip at
> http://www.imt.liu.se/~erisu/2007/mutable_immutable.zip with a small
> test \(including java\-code and comments\) of an approach that possibly
> would let us have a choice of both mutable and immutable classes and a
> conversion mechanism between the two\. Please have a look and comment\.
>
> There was a lot of mail discussion before this regarding arguments for
> and against \(im\)mutability, some excerpts to start searching the mail
> archives from are listed below\.
>
> Something like a summary:
> http://www.openehr.org/mailarchives/ref_impl_java/msg00380.html
>  

I must say, this discussion was the most important reason to go my own
way in development\. This was not an easy choice, because from that point
on, I had to check/implement every change myself, and could not anymore
use code written by others \(took me months of extra work\)\.
The current state of my work is that I do not use hibernate, I do not
trust it, I don't like things to happen without knowing, but I learned
from hibernate, I mimic it partly\. For this reason, there are still
things important, especially regarding immutability issues\. But my work
could use some refactoring in the persistence, i have ideas about that\.
There are some very standard, also generic persistence\-pattern, which
support many different solutions\.

Because, now I come to the conclusion that there are many
persistence\-implementations possible,
\- f\.e\. store every property in separate fields, small scale OLTP would
allow this, link tables to objects in the RM\-model,
\- When it is for large scale quick OLTP\-retrieval, also possible is dump
top\-objects to blob's\.  Also mixed possibilities exist, for example,
dump the datatypes to blob's and some others also, but leave the most in
relational model \(hibernate\-like\), representing the RM\-model\. One could
also mix in XML, for some parts\.
\- If needed for data mining, one could consider to accompany the blob's
by separate \(kind of\) index tables\.

It is a matter of trade\-off's\.

As you can see, these are only a few considerations which come to mind\.

Concluding, because of many possibilities, a good choice for a published
\(open source\) persistence layer, in my opinion, would be that it would
be able to home many solutions, it would be transparent for the really
persistence implementation below it\.

I would encourage that, it would make it possible for me to reconnect to
the published code, and even post my code\. I talked about this with my
business partners, and they also feel that it would be good to published
large parts of my code\.

Of course,  this would mean that I would have to refactor quite a lot,
to connect to shared ideas, but it would be worth the effort\.

I hope I made myself clear, let me know how you feel about this\.
Bert

---

## Post #3 by @system

> Erik Sundvall schreef:
>
> > Hi Humberto and others!
> >
> > There is a zip at
> > [http://www.imt.liu.se/~erisu/2007/mutable_immutable.zip ](http://www.imt.liu.se/%7Eerisu/2007/mutable_immutable.zip)with a small
> > test (including java-code and comments) of an approach that possibly
> > would let us have a choice of both mutable and immutable classes and a
> > conversion mechanism between the two. Please have a look and comment.
> >
> > There was a lot of mail discussion before this regarding arguments for
> > and against (im)mutability, some excerpts to start searching the mail
> > archives from are listed below.
> >
> > Something like a summary:
> > [http://www.openehr.org/mailarchives/ref_impl_java/msg00380.html](http://www.openehr.org/mailarchives/ref_impl_java/msg00380.html)
> >
>
> I must say, this discussion was the most important reason to go my own
> way in development. This was not an easy choice, because from that point
> on, I had to check/implement every change myself, and could not anymore
> use code written by others (took me months of extra work).
> The current state of my work is that I do not use hibernate, I do not
> trust it, I don't like things to happen without knowing, but I learned
> from hibernate, I mimic it partly. For this reason, there are still
> things important, especially regarding immutability issues. But my work
> could use some refactoring in the persistence, i have ideas about that.
> There are some very standard, also generic persistence-pattern, which
> support many different solutions.
>
> Because, now I come to the conclusion that there are many
> persistence-implementations possible,
> - f.e. store every property in separate fields, small scale OLTP would
> allow this, link tables to objects in the RM-model,
> - When it is for large scale quick OLTP-retrieval, also possible is dump
> top-objects to blob's. Also mixed possibilities exist, for example,
> dump the datatypes to blob's and some others also, but leave the most in
> relational model (hibernate-like), representing the RM-model. One could
> also mix in XML, for some parts.
> - If needed for data mining, one could consider to accompany the blob's
> by separate (kind of) index tables.
>
> It is a matter of trade-off's.
>
> As you can see, these are only a few considerations which come to mind.
>
> Concluding, because of many possibilities, a good choice for a published
> (open source) persistence layer, in my opinion, would be that it would
> be able to home many solutions, it would be transparent for the really
> persistence implementation below it.
>
> I would encourage that, it would make it possible for me to reconnect to
> the published code, and even post my code. I talked about this with my
> business partners, and they also feel that it would be good to published
> large parts of my code.
>
> Of course, this would mean that I would have to refactor quite a lot,
> to connect to shared ideas, but it would be worth the effort.
>
> I hope I made myself clear, let me know how you feel about this.

Hi Bert,

I will encourage you to do that. The community will benefit from a common code base.

Cheers,
Rong

---

## Post #4 by @system

>
> Hi Bert,
>
> I will encourage you to do that\. The community will benefit from a
> common code base\.

Thanks Rong, I will publish an interface to a generic persistence layer
in a few months\.
But we need getters and setters which contain no algorithm, other than
assignment, they need, at least to be protected, and we also need a
default constructor

If we do not have these things, it is very hard to assign values from a
persistence layer to the RM\-objects\.

Or\.\.\.\.\.

Do you have another opinion, I am very anxious to learn more about it\.

regards,
Bert

---


**Canonical:** https://discourse.openehr.org/t/im-mutable-java-rm-was-re-improving-the-minimal-terminology-service/12673
**Original content:** https://discourse.openehr.org/t/im-mutable-java-rm-was-re-improving-the-minimal-terminology-service/12673