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

**Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154)
**Created:** 2007-02-19 11:37 UTC
**Views:** 4
**Replies:** 2
**URL:** https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621

---

## Post #1 by @erik.sundvall

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/

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\.

  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\.

  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
  is that ok?
  Daniel used the published schema\.

11:41 AM Rong: OK
  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\.
  Daniel Karlsson \(at the meeting\)\.
  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\!

---

## Post #2 by @thomas.beale

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.

- thomas

---

## Post #3 by @system

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

---


**Canonical:** https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621
**Original content:** https://discourse.openehr.org/t/chat-regarding-thoughts-about-the-java-ref-impl-future/14621