# Chat regarding thoughts about the java-ref-impl future

**URL:** <https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621>\
**Category:** Reference Implementation: Java (archive)\
**Created:** [19 February 2007 11:37 UTC](https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621 "2007-02-19T11:37:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Post date:** [19 February 2007 11:37 UTC](https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621/1 "2007-02-19T11:37:27Z")

</div>

Hi!

Rong initiated a chat as a followup to a live meeting we had here at  
LiU last Friday. It is attached below. We are circulating it to you in  
order to get some comments and more thoughts regarding this, so feel  
free to reply!

Summary: We'll start an experimental branch to test an approach with  
mutable classes in addition to immutable ones. We won't mess with the  
TRUNK version until the experiment is finished and tested/commented.  
Pros/cons of hardwiring client components like GUIs etc to the  
ref-impl are also discussed.

By the way Tom, the archive of the ref\_impl\_java list is not publicly  
accesible, could you fix that?

Best regards,  
Erik Sundvall  
[http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/)

9:07 AM Rong: Hi Erik!

9:28 AM me: Hi. Just came back to the computer

9:29 AM Rong: Just want to continue our discussion on Friday a bit  
here, if you have time now?

9:30 AM me: Sure, we can start a bit here, but email would probably be  
better to involve more people. We can paste in some of the chat to a  
mail if we start by chatting.

9:32 AM Rong: that's right.. I hope I can visit LiU more often than  
before in the future  
me: Great! First thing first, the immutable container issue. I do  
hope we don't need to make all classes mutable, container classes is  
bit different from others. I agree we should experiment with mutable  
containers in the RM.

9:36 AM me: I believe we'll see what classes need to be mutable in  
order to avoid having programmers creating parallel hierarchies. Some  
of our projects will show that.

9:38 AM Rong: Well, I really want to have a look at the editor coding  
on that aspect. My suspicion is that we can achieve a lot with  
reflection on the aom/rm instead of hard-code things up

9:40 AM me: One of the main problems is that the classes of the  
ref-impl are final and thus stop experiments with added features or  
different solution approaches. It would be ok to have many Immutable  
classes to begin if one was able to change the ones where needs for  
mutability pop up. But immutable classes that are not final are not  
very immutable as we said before...  
9:44 AM Of course a lot can be done with reflection, but what kind of  
things are you thinking about? If one wants to use an RM builder  
reflection is a good way of course, but in many cases a builder just  
makes things harder to work with. Putting objects in a bunch of hash  
maps instead of using a type checked object hierarchy directly is not  
always safer or easier.  
9:45 AM What are your reactions to the (im)mutability experiment code  
that we (me, Mattias & Mikael) sent to the list? Is there anything in  
the experiment approach that would make the classes less safe than  
they are today?  
9:49 AM And, no we are not suggesting setters to container lists, of  
course it is add one would like there instead. Sorry for not answering  
that on the list, I mistakenly thought it was obvious.

9:51 AM Rong: I think the one you posted on the list is quite OK. I  
prefer the one based on Interface, same as the immutable List in jdk,  
but the down side is that can't make classes final

9:53 AM me: What can't make immutable classes final? In the experiment  
they were final.

Rong: I think after all this catch-up-the-spec coding, I am bit tired  
of hard-coded stuff for anything.. I use more reflecting for parsing,  
serializing, wrappers generation etc  
9:54 AM yes, yours are good at that perspective! Interface based is not.

9:56 AM me: Interfaces are good for some settings, and I believe it  
could be combined with the posted experiment. Often one would probably  
want to instantiate objects directly though, not having object  
factories everywhere. But sure, in some settings interfaces are nice.  
Maybe we can add interfaces at a later stage?  
9:59 AM I understand the "catch-up-the-spec coding" problem. In our  
experiment code approach I suggested (but maybe not clearly enough)  
that only the mutable classes should be manually maintained and the  
immutable ones should be auto-generated.

10:00 AM Rong: that's very good  
10:02 AM Another thing we need to keep in mind is right now there is  
no validation logic for RM instances based on archetypes, previous  
assumption has been that once the object (tree) is created it remains  
the same. Once we have mutable RM classes, we will need to provide  
validation logic as well

10:04 AM me: When it comes to having client code hardwired to the  
ref-impl that might be changing because of changing spec: I believe  
that having hardwired code is safer than loose coupling via hash-maps  
and reflection, because your IDE and compiler will more clearly tell  
you about errors and incompatible changes long before runtime  
deployment. If a developer updates to the latest and possible  
incompatible kernel, then the client code should break in a very clear  
way.

10:07 AM Rong: that I agree, but you use reflection carefully, you  
won't have broken code hopefully 😉

10:08 AM me: Yes, archetype based validation is very important. We  
have to find a way to do that also on demand (not just at build time  
in an RM-builder as I guess it is now). So, yes validation needs  
another approach. I posted some hints to validation frameworks  
earlier, they often provide means to create custom validators. One way  
could be to create such a validator that is archetype aware.  
10:10 AM Even if you "use reflection carefully" I guess you can't  
catch potential conflicts before runtime, or do you have some special  
solution in mind?  
10:13 AM Does it not have to be a very complicated "reflection code"  
to safely convert model changes between incompatible client- and  
kernel-code? If so is that really the best overall solution from an  
engineering and maintenance perspective?

Rong: not always of course, but stuff like changes on attributes in  
the classes can be well handled I believe  
10:18 AM I am convinced that we need to go that way considering the  
amount of changes in the RM/AOM in the past months, we simply don't  
have enough resources to keep the pace on updating software. Ideally,  
only the RM/AOM/AP need to updated and all the rest - parser,  
serializer, wrappers, persistence, GUI widgets etc etc can just adapt  
the changes smoothly.  
10:20 AM Another thing I want to discuss which I didn't have time to  
mention last Friday is that how much synergy we could create between  
the LiU student projects and the Java project.

10:27 AM me: "we need to go that way" what way do you mean, having  
magic reflection based intermediate layers that shield client code  
from RM/AM/AOP changes? If so I believe it might be dangerous and  
should be optional. But if there are clearly version-marked releases,  
a client code developer is not forced to upgrade to the latest  
version, they can keep using the old one for a while and then choose  
when upgrade and take the pain of fixing incompatible changes. But  
maybe I misunderstood what you meant?  
10:37 AM me: Synergy: Right now I believe that what has come out of  
the archetype editor project is bug-finding and the surfacing of the  
problem with unextendable code. If the code was extendable (not final)  
I believe that some LiU projects could add features to the Java  
project easier and contribute that if anyone else finds use for it.  
Some possible future surrounding artifacts like archetype services etc  
could also be a contribution (probably unrelated to immutability).

10:39 AM Rong: I hope you don't have objection on using reflection.  
You seems to be rather skeptical on that. There are lots of  
dependencies on RM/AM/AOP even with the core components, where I see  
using reflection can reduce amount of work for maintenance. The client  
code can chose which way to go, as long as they are not maintained by  
the java project.  
10:49 AM Rong: "bug-finding" as you may call it; I rather see it as,  
most of the time, an exercise to update the existing components to the  
latest specs

11:12 AM me: Sorry for the interruption, Hans came in for a "live" chat 🙂  
There are many other possible synergy effects, and I believe others  
will add more when we send this as a mail.  
11:13 AM Agree that a lot of the "bug-finding" has been specification related.  
11:16 AM There is nothing wrong with reflection properly used, it can  
be a great way to reduce and simplify coding tasks. i probably used  
bad terminology there, it was silent "shielding" of model differences  
I was sceptical towards.

11:19 AM Rong: that I agree - if the code should fail, it should fail early

11:20 AM me: Duplication of code is for example bad, and reflection is  
sometimes a good remedy.

&nbsp;&nbsp;Rong: Now, we seem to share some common views 😉

11:21 AM me: OK, I thought we would reach something like this. Nice.  
How do we go on from here?  
11:23 AM Could we start an experimental branch on openEHR SVN server  
for mutable/immutable experimentation so that it can be commented by  
more people than if we do it in a non-public repository?

11:24 AM Rong: yes, it sounds like a good idea as long as it remains  
as a temporary branch.. we don't want to maintain extra branches for  
fixes

11:27 AM me: It should not mess up the TRUNK during experimentation,  
and if the experiment falls out in a positive way we could move it in  
to trunk later after a lot of testing and commenting by the community.

&nbsp;&nbsp;Rong: that sounds great  
11:28 AM maybe we could even try out different approaches different  
container classes just to compare

11:30 AM me: Sure, an experiment branch is a good place to test  
different approaches.  
Another thing that we have been thinking about is XML export/import

11:31 AM Rong: Is that the one used in the editor, currently called  
'xml-serializer'?

11:33 AM me: No, that was a quick hack. More regarding RM  
export/import. Maybe some annotations could be added to the classes to  
ease XML binding? But we should probably first get the mutability  
working, and then look at XML.

11:34 AM Rong: ok

11:37 AM me: Daniel ran an XMLS-\> java conversion and got a class  
hierarchy, but there is a lot of work left if one wants to get that  
"connected" to the current RM/AM. Let's look into that later some  
other time.  
11:38 AM I believe that we (as usual) will find many incompatibilities  
between the published XMLS and the published specs when we start  
working with binding 😉

11:39 AM Rong: We probably should use XML-schema published by openEHR  
for the binding.. both the parser and serializer would be generated in  
that case

11:40 AM me: I can send this chat in a mail to the java-implementers  
list and the LiU people attending the friday meeting  
&nbsp;&nbsp;is that ok?  
&nbsp;&nbsp;Daniel used the published schema.

11:41 AM Rong: OK  
&nbsp;&nbsp;Should I create the branch for you to start with?  
11:42 AM by the way, which Daniel you are talking about? The one in  
the meeting on Friday or a new thesis student?

11:43 AM me: Sure, maybe I can have a go at it parts of next week.  
&nbsp;&nbsp;Daniel Karlsson (at the meeting).  
&nbsp;&nbsp;Rong: cool  
11:45 AM me: Daniel is a hacker in disguise 🙂  
11:46 AM Ok, I'll mail the chat to the list and LiU people. Bye for now!

11:48 AM Rong: please do that.. talk to you later!

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [19 February 2007 16:40 UTC](https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621/2 "2007-02-19T16:40:41Z")

</div>

Erik Sundvall wrote:

> ```auto
> 
> By the way Tom, the archive of the ref_impl_java list is not publicly
> accesible, could you fix that?
> 
> ```

Is it the preference of this group to make the archive publicly available? If so, I will get the system administrator to do it.

- thomas

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [20 February 2007 09:21 UTC](https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621/3 "2007-02-20T09:21:12Z")

</div>

Thomas Beale schreef:

> Erik Sundvall wrote:
> 
> > By the way Tom, the archive of the ref\_impl\_java list is not publicly  
> > accesible, could you fix that?
> 
> Is it the preference of this group to make the archive publicly  
> available? If so, I will get the system administrator to do it.

If these archives are publicly available, it means that they will be  
searchable by Google. I think it could be good for my business.  
Against would be that stupid questions and stupid answers will be  
searchable until the end of civilisation.  
This can make discussions less open and freely.

So I see pro's and con's, and obstain from vote

bert