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

Reference Implementation: Java (archive)
1

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):

2

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

3

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.

Hi Bert,

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

Cheers,
Rong

4

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