Maybe it is an idea to wrap the classes in interfaces, and leave the
hibernate-supporting methids and getters outside the interface, and tell
people to only use the interfaces.
Bert
Bert Verhees schreef:
Hi!
Many other persistance mechanisms (db4o, Xstream etc) can handle
private fields by using reflection, is ther no setting available in
Hibernate to enable such behaviour?
Maybe it is an idea to wrap the classes in interfaces, and leave the
hibernate-supporting methids and getters outside the interface, and tell
people to only use the interfaces.
We previously wanted setters for som values in the AOM and suggested
that the fields could be made 'protected' in the kernel classes so
that one could create sub-classes in other packages (that the average
user should avoid) with setters (and/or getters) for special purposes.
I believe this would be better than cluttering the current kernel code
with interfaces or other features specially targeted for Hibernate
usage.
With different package naming you can use the same class names as the
original classes and the code for calling the classes would be
untouched with the exception that you have different import statements
in usual.
Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/
P.s. Regarding the AOM, we made a workaround instead, so the AOM
fields were never changed to protected... but we might suggest this
again if needed in the future...
Erik Sundvall schreef:
Hi!
Many other persistance mechanisms (db4o, Xstream etc) can handle
private fields by using reflection, is ther no setting available in
Hibernate to enable such behaviour?
First I must say, I am busy over a week with this, I come from one
problem to the other, and every solution seems to have disadvantages.
So, I am very happy with your suggestions.
The problem is that reflection is a suboptimal mechanism, and therefore,
there is in hibernate a reflection optimizer, which avoids using
reflection, in a previous email, I pointed to a discussion which
explains this. It is also explained on the Hibernate-website. How it
exactly works, I don't know, I have no time to study that, zillion of
classes are involved. I did some source-viewing because I wanted to
understand some exceptions. I decided to just follow the suggestions and
instructions on the hibernate-website and trust their good thinking.
It is (kind of) explained here: http://www.hibernate.org/15.html
But there is much more information on the website, and hibernate-forums,
I struggled through that last week. Please do not ask me to repeat this
search again. I did send some links in previous mails.
I think that performance is a important issue. OpenEhr is meant to be
scalable, and I think it is a bad idea to have an avoidable
performance-issue right at the start.
Maybe it is an idea to wrap the classes in interfaces, and leave the
hibernate-supporting methids and getters outside the interface, and tell
people to only use the interfaces.
We previously wanted setters for som values in the AOM and suggested
that the fields could be made 'protected' in the kernel classes so
that one could create sub-classes in other packages (that the average
user should avoid) with setters (and/or getters) for special purposes.
I believe this would be better than cluttering the current kernel code
with interfaces or other features specially targeted for Hibernate
usage
Only interfaces, other features are not necessary. Interfaces make a
clean code-tree possible, and Interfaces is what the developer wants to
see. If they belong to a class or to an interface as such (on top of a
class). As long as the methods and concepts behave as to expect.
With different package naming you can use the same class names as the
original classes and the code for calling the classes would be
untouched with the exception that you have different import statements
in usual.
It looks to me also as a good approach, what you suggest.
I think we need a formal decision to find a path to go.
Maybe there are other ideas also?
I see a few problems, if you have setters/getters in a derived class,
you need to have the fields which are to get or set, to be protected.
Most of them, they are private and often also final.
That brings me to the other problem, many classes in RM are final, so
you cannot subclass them. So, in this solution we have to bring offers
towards hibernate.
kind regards
Bert Verhees
Sorry, want to add an extra statement to this
We must ask ourselves, what is RM.
In my opinion, it can be seen as a framework for developers. It is not
encouraged for user/developers to look further than the public
interface-parts of the offered classes.
What is below, may not be of any importance to user/developers. It must
be transparent.
That is why I suggested interfaces as the framework, they behave as
described in the docs, and leave the classes as an implementation of the
interfaces. This gives the developers of the kernel-code below the
interface a lot of freedom to optimize and do what they need to do, as
long as the interface stays consistent with the docs.
So, in fact, a separation of interface and kernel-code could also be
beneficial for other purposes.
Maybe there are complications I overlooked
regards
Bert Verhees
Bert Verhees wrote:
This needs discussion. There are many problems with using hibernate for
persistence.
Sorry for being late on this. The persistence layer issue certainly
needs more exploration. My general feeling is that Hibernate is not the
only game in town, and we should not sacrifice good OO practice to
please Hibernate for good performance. Please see more comments below.
It is not that classes will break, but it is not possible to enforce
class integrity on property level.These reasons:
- Classes need a default constructor without arguments. These are often
already there, so this concession was already done.
- Classes need public getters and setters for each property they have.
And these setters must allow to store null in the property, because they
are tested for this ability.This has consequences, as said, class-integrity cannot be enforced, it
is not possible to make classes immutable.
Making objects immutable is usually a good idea. For the RM case, it has
another special purpose that is to safely implement the invariants
checking required by the specification. If the object is not modifiable,
it would be enough to do the checking when object is created. This make
it easier to realize invariants without involving Java libraries that
implement Design by Contract (or even trying to implement DbC by ourselves).
However, immutable objects do create difficulties in object
construction. We might want to create experimental branch with
modifiable RM classes.
What can be done, is to urge programmers who use the classes not to use
the public getters and setters. Than the classes can stay on there
regular interfaces immutable.
It's hard to restrict that and not a valid implementation of immutable
objects pattern. I suggest we either use immutable objects or not at all
(rely on validation by invariants).
I see that this is dangerous. But that is how hibernate works,
The public getters and setters are necessary obligatory, the public
default contructor also.
The fact that setters must be able to set a property to null is
necessary to get the reflection optimizer running, which is necessary
for a good performance of the system.Alternative, there are some other options.
1) Stick to Hibernate 2.
2) Write a persistence layer without the use of hibernate.
Both seem to be viable to me.
Cheers,
Rong
Rong Chen wrote:
Bert Verhees wrote:
This needs discussion. There are many problems with using hibernate for
persistence.
Sorry for being late on this. The persistence layer issue certainly
needs more exploration. My general feeling is that Hibernate is not the
only game in town, and we should not sacrifice good OO practice to
please Hibernate for good performance. [...]
I agree with Rong. The persistence layer must be implemented according to
the best practice in both design and implementation to make the complete
system genuinely useful. The system is potentially going to handle very
large sets of data and the persistence layer is therefore going to be the
bottleneck for the performance. Time spent on finding the ultimate
persistence solution according to the best practice is therefore probably
well spent time.
Regards,
Mikael
My opinion, (maybe you have read parts of it before)
We must ask ourselves:
What is OpenEhr?
According to the OpenEhr website, it is a set of specifications,
implementable in software.
The specifications do not describe the internals of the software, but
they describe the behavior and properties of its exposed interfaces.
It is often stated in this community, that openEhr consists of the specs.
This is the power of OpenEhr, it allows implementation in Eiffel, C# and
Java. Other implementations would also be possible, for example Pascal
or C++.
Most programming languages will suffer from lacking the many features
which are in Eiffel language features by default.
Most important are "Design By Contract" and invariants.
This makes Eiffel a very powerful programming environment for
prototyping. That is how it is used inside the Openehr community.
But on the other hand, also Eiffel misses some important features, most
heard (amongst others) is missing interoperability to popular third
party libraries, for example, to a well designed and good featured
persistence layer. One must write itself, or use one of the persistence
mechanisms which are designed towards Eiffel, like Matisse, which
results in a limited number of choices.
This is why Eiffel is not used that much in production environments.
For production the choice is, at this moment, C# and Java. Both have
garbage-collection, like Eiffel, which makes it easy to (more or less)
translate the Eiffel-design to Java and C#.
The Eiffel features these environments lack of must be implemented by
advanced coding.
Maybe I am wrong, but is this possible?
public class RMClass implements RMClassIntf extends RMClassImpl
RMClass:
The advantage of this class is to avoid a seperate construction line
like wherein the Interface is "constructed" by calling the
Interface-implementer
This class implements the interface and only that, and has no getter and
setters because the interface does not have that.
RMClassImpl
This class has the default contructor and the getter/setters needed by
hibernate.
In fact the Interface is not needed, but it makes maintaining simpler.
The problem with this construct is that the getter/setters are still
visible in RMClass
C# has the advantage that it has possibility of seperation of visibility
inside namespace and outside namespace.
Maybe more sensible constructs are possible.
For example, make from the Hibernate-aware class a property of the pur
RM-class, like at this moment, multiple inheritance is implemented.
This makes a seperate-line of heritance-structure necessary.
Or something else
Who has a good idea?
Bert
Rong Chen wrote:
Making objects immutable is usually a good idea. For the RM case, it has
another special purpose that is to safely implement the invariants
checking required by the specification. If the object is not modifiable,
it would be enough to do the checking when object is created. This make
it easier to realize invariants without involving Java libraries that
implement Design by Contract (or even trying to implement DbC by ourselves).However, immutable objects do create difficulties in object
construction. We might want to create experimental branch with
modifiable RM classes.
I don't think immutable objects are viable for larger class types, and
particularly wherever there are container objects, e.g. lists, hashes
etc, since for the latter, you rarely know what you have in one go - yu
normally add things one at a time. In Ocean's implementation, we are
adding DbC to C# using some available class libraries that do this. All
the programmers have now adopted this style, and it has improved the
quality considerably. The value of invariants isn't to force objects to
be unchangable, but on the contrary to allow them to be changed, while
still remaining correct.
Where immutable types can possibly work easily is at the level of the
Data Types, but I don't believe any higher.
What can be done, is to urge programmers who use the classes not to use
the public getters and setters. Than the classes can stay on there
regular interfaces immutable.
It's hard to restrict that and not a valid implementation of immutable
objects pattern. I suggest we either use immutable objects or not at all
(rely on validation by invariants).
I see that this is dangerous. But that is how hibernate works,
The public getters and setters are necessary obligatory, the public
default contructor also.
The fact that setters must be able to set a property to null is
necessary to get the reflection optimizer running, which is necessary
for a good performance of the system.Alternative, there are some other options.
1) Stick to Hibernate 2.
2) Write a persistence layer without the use of hibernate.
I think that the question of invariants/immutability is independent of
the question of using hibernate. I think Hibernate out of the box
doesn't work for anything except trivial object models, since it by
default turns even the finest grain of objects in to relational
entities, and the join time make performance horrible (we tested it at
UCL - 4 sec to retrieve a single EHR based on primary key). If you
reduce the number of relational tables drastically , performance
radically improves. But then it is questionable as to whether you need
hibernate at all in that case - what is it doing?
But regardless of Hibernate, I think you will hit other problems to do
with immutable objects. But - I can imagine a second layer of objects,
simplified from the RM, whose only purpose is to act as a map from the
RM into the relational database. Such objects would then not "be" RM
objects, only a transformed copy of them. It may be that you have built
two concepts - openEHR RM and relational mapping - into a single layer
of classes when it needs to be two...
- thomas
Thomas Beale schreef:
Rong Chen wrote:
Making objects immutable is usually a good idea. For the RM case, it has
another special purpose that is to safely implement the invariants
checking required by the specification. If the object is not modifiable,
it would be enough to do the checking when object is created. This make
it easier to realize invariants without involving Java libraries that
implement Design by Contract (or even trying to implement DbC by ourselves).However, immutable objects do create difficulties in object
construction. We might want to create experimental branch with
modifiable RM classes.
I don't think immutable objects are viable for larger class types, and
particularly wherever there are container objects, e.g. lists, hashes
etc, since for the latter, you rarely know what you have in one go - yu
normally add things one at a time. In Ocean's implementation, we are
adding DbC to C# using some available class libraries that do this. All
the programmers have now adopted this style, and it has improved the
quality considerably. The value of invariants isn't to force objects to
be unchangable, but on the contrary to allow them to be changed, while
still remaining correct.Where immutable types can possibly work easily is at the level of the
Data Types, but I don't believe any higher.
What can be done, is to urge programmers who use the classes not to use
the public getters and setters. Than the classes can stay on there
regular interfaces immutable.
It's hard to restrict that and not a valid implementation of immutable
objects pattern. I suggest we either use immutable objects or not at all
(rely on validation by invariants).
I see that this is dangerous. But that is how hibernate works,
The public getters and setters are necessary obligatory, the public
default contructor also.
The fact that setters must be able to set a property to null is
necessary to get the reflection optimizer running, which is necessary
for a good performance of the system.Alternative, there are some other options.
1) Stick to Hibernate 2.
2) Write a persistence layer without the use of hibernate.
I think that the question of invariants/immutability is independent of
the question of using hibernate. I think Hibernate out of the box
doesn't work for anything except trivial object models, since it by
default turns even the finest grain of objects in to relational
entities, and the join time make performance horrible (we tested it at
UCL - 4 sec to retrieve a single EHR based on primary key). If you
Hi Thomas, I welcome your opinion on this matters regarding to immutable
objects and I really hope discussion on this will be initiated by this.
But, despite of welcoming this, I have some remarks to your opinions on
hibernate. (that is what discussion isa bout, using arguments and in the
end learn)
In my opinion your opinions on hibernate are too simple. It looks like
you prove something (by mentioning an experience), but it may well have
been a bad test-situation. let me explain why I come to this.
Please keep in mind that I am not a fan of Hibernate, but there are many
advantages, let me explain. Also see what alternatives you have.
Also I have spent a lot of time in implementing Hibernate3 into RM, and
I do not have your experiences. But like many technicians, I also tend
to defend my choices afterwards, it is hard to admit one has spent
months on the wrong choice. You see this many times, on many subjects
with many people. But besides that it is possible that this personal
situation drives my thoughts in directions, I also have experiences
(Rong also has with Hibernate2), and I have arguments, please read on,
and let discuss them and stop mentioning tests when not all parameters
are known:
There are many ways to plan a hibernate-construct, depending on if you
need polymorphism through inheritance trees and other factors, like
possibility for choices for performance needed for this or that purpose.
A lot depend on the design and purpose. It is for example not always bad
to have many tables, specially if you tend to request small specific
datasets.
If it is wrong constructed for the purpose you need it, then you will
see a bad performance. But that is with every database design, this has
nothing to do with hibernate.
Beside many construct-ways there is a performance difference between the
reflection-use of CGLib, or native java-reflection.
Even a small detail-choices can be optimized as discriminators to
support polymorphism can be string, integer, or whatever, depending what
your database support best.
And performance is much better when using Hibernate 3.x instead of 2.x.
Also performance gain is possible when using better database-drivers,
and depending on which database you use, and which connect mechanism.
Performance can vary depending on many things.
We need to know all these parameters to judge in how far the use of
hibernate (in your testcase) was optimal for a given situation. There is
more to know.
But on the other hand, I think we should not judge that, but rely on our
own exeperiences. This purpose of this discussion is not how to use
hibernate best, but how to make the best choices for OpenEhr. And what
is best, there are also many ways to think about that.
Small scale, large scale, costs, high perfomance, university
investigations-database, datamining, and let'not forget the most famous
purpose called "etcetera"(joke), all different purposes which need
different system/parameter setup.
(the use of a persistence layer like hibernate makes it easy to change
the parameters when the purpose changes, I come back to this)
reduce the number of relational tables drastically , performance
radically improves. But then it is questionable as to whether you need
hibernate at all in that case - what is it doing?
In fact, if you create SQL-constructs by hand, it is very obvious that
you get about the same table-structure, then as when hibernate does it.
If you debug the code, you'll see that hibernate does the same SQL-calls
as you would have done manually. If it doens't, and you do not agree
with what is does, you should reconfigure it.
Hibernate should do what you want it to do!! You are the boss.
Also for specials cases, Hibernate has the possible of a own query
language and it is possible to use SQL.
Hibernate isv ery configurable, without changing the code!!!! (it all is
in configuration-files)
Why you should use hibernate or any other persistence layer, is because
it makes coding and maintaining the code simpler and less error-prone.
Thereby, Hibernate offers some very strong advantages.
Without changing one character of the code one can change
database-engine (brand), database-server (machine), even have that table
to reside on that machine and that on another, and change your plan
later on. It is all in configuration-files.
In my opinion, it is necessary to use a persistence-layer like
hibernate, there may be other good to when using a relational database,
which almost always will be the case. As I understand, Ocean also uses a
relational database. As I understand, but maybe I am wrong, Ocean has
written its persistence layer by hand. As I understood from previous
messages, Ocean runs it C#-RM-kernel on Microsoft SQL server. Maybe
NHibernate is not that good, I don't know, maybe that was what is tested?
It is a fact that support for all kind of third party libraries for
Dotnet is much less than in java-world. This will change over the years
for sure, but one can see from the number of mature third party
libraries that Java is hanging around a long time, and many people favor
its platform independency.
So I tend to disagree with this part of your message you bring into the
discussion, but the part you bring in regardless to Hibernate is very
interesting (below), and I hope others will respond to that (also to
what I said about hibernate)
regards, hoping for many discussions on these subjects
bert
Hibernate should do what you want it to do!! You are the boss.
Also for specials cases, Hibernate has the possible of a own query
language and it is possible to use SQL.
Hibernate isv ery configurable, without changing the code!!!! (it all is
in configuration-files)
I forgot, the Hibernate query language queries objects, not tables, so
even if you change your table structure, for whatever reason, Hibernate
supports this without changing the code
Bert
Bert Verhees wrote:
In fact, if you create SQL-constructs by hand, it is very obvious that
you get about the same table-structure, then as when hibernate does it.
If you debug the code, you'll see that hibernate does the same SQL-calls
as you would have done manually. If it doens't, and you do not agree
with what is does, you should reconfigure it.
Hibernate should do what you want it to do!! You are the boss.
Also for specials cases, Hibernate has the possible of a own query
language and it is possible to use SQL.
In our system, we don't use SQL to do clinical queries, we wrote a
querying language that combines SQL and Xpath to do archetype-based
querying. We will release the definition when it is cleaned up a bit,
and would be very happy if the community is interested in looking at it.
Currently it works fine in our server.
Hibernate isv ery configurable, without changing the code!!!! (it all is
in configuration-files)Why you should use hibernate or any other persistence layer, is because
it makes coding and maintaining the code simpler and less error-prone.
Thereby, Hibernate offers some very strong advantages.Without changing one character of the code one can change
database-engine (brand), database-server (machine), even have that table
to reside on that machine and that on another, and change your plan
later on. It is all in configuration-files.
that is the advantage, I agree. But the object-relational mapping has to
be made reasonable. The default mapping is no good at all. There is no
point storing the individual fine-grained values in an Observation as
separate relational items.
In my opinion, it is necessary to use a persistence-layer like
hibernate, there may be other good to when using a relational database,
which almost always will be the case. As I understand, Ocean also uses a
relational database. As I understand, but maybe I am wrong, Ocean has
written its persistence layer by hand. As I understood from previous
messages, Ocean runs it C#-RM-kernel on Microsoft SQL server. Maybe
NHibernate is not that good, I don't know, maybe that was what is tested?
we have a layer that allows us to abstract to any relational DB.
- thomas
Rong Chen schreef:
Thomas Beale wrote:
Rong Chen wrote:
Making objects immutable is usually a good idea. For the RM case, it has
another special purpose that is to safely implement the invariants
checking required by the specification. If the object is not modifiable,
it would be enough to do the checking when object is created. This make
it easier to realize invariants without involving Java libraries that
implement Design by Contract (or even trying to implement DbC by ourselves).However, immutable objects do create difficulties in object
construction. We might want to create experimental branch with
modifiable RM classes.
I don't think immutable objects are viable for larger class types, and
particularly wherever there are container objects, e.g. lists, hashes
etc, since for the latter, you rarely know what you have in one go - yu
normally add things one at a time. In Ocean's implementation, we are
adding DbC to C# using some available class libraries that do this. All
the programmers have now adopted this style, and it has improved the
quality considerably. The value of invariants isn't to force objects to
be unchangable, but on the contrary to allow them to be changed, while
still remaining correct.
Hi,
Since I think, Java-implementation is also my concern, I would like to
ask a few questions, which come to mind.
Are we talking about the immutable java-classes in the RM-tree?
Do I understand well if I read that there is no purpose in the specs for
immutability, but the intention is to use DbC-concepts to keep the
instantiated classes valid instead of immutable? It seems I did not read
the specs to well, because I did not see this point.
But that does not matter, it is never too late to learn.
Sounds good. I would like to try out JML,
http://www.cs.iastate.edu/~leavens/JML/, with some experimental branch.
It seems to only support JDK1.4 which could be a problem.
Isn't there a matured assertion-mechanism in java? I don't know.
What is wrong with the DbC concept like it is used now in the
constructors? If it was implemented in the setters, it would be like
invariants, when a setter is the only place to change a field. This
should be a golden rule.
But I agree, it would be good to have an Eiffel like mechanism (short
and simple coded).
I took a quick look at the web-page you point to. Did you study it?
Although it is a very young project. Maybe it is possible/feasible, if
it is good, to extract the needed functionality from it.
I am very interested what is to happen in this, which choices will be
made. I would be glad to help if there are good ideas.
Bert Verhees wrote:
Rong Chen schreef:
Thomas Beale wrote:
Rong Chen wrote:
Making objects immutable is usually a good idea. For the RM case, it has
another special purpose that is to safely implement the invariants
checking required by the specification. If the object is not modifiable,
it would be enough to do the checking when object is created. This make
it easier to realize invariants without involving Java libraries that
implement Design by Contract (or even trying to implement DbC by ourselves).However, immutable objects do create difficulties in object
construction. We might want to create experimental branch with
modifiable RM classes.
I don't think immutable objects are viable for larger class types, and
particularly wherever there are container objects, e.g. lists, hashes
etc, since for the latter, you rarely know what you have in one go - yu
normally add things one at a time. In Ocean's implementation, we are
adding DbC to C# using some available class libraries that do this. All
the programmers have now adopted this style, and it has improved the
quality considerably. The value of invariants isn't to force objects to
be unchangable, but on the contrary to allow them to be changed, while
still remaining correct.
Hi,
Since I think, Java-implementation is also my concern, I would like to
ask a few questions, which come to mind.Are we talking about the immutable java-classes in the RM-tree?
Do I understand well if I read that there is no purpose in the specs for
immutability, but the intention is to use DbC-concepts to keep the
instantiated classes valid instead of immutable? It seems I did not read
the specs to well, because I did not see this point.
But that does not matter, it is never too late to learn.Sounds good. I would like to try out JML,
http://www.cs.iastate.edu/~leavens/JML/, with some experimental branch.
It seems to only support JDK1.4 which could be a problem.
Isn't there a matured assertion-mechanism in java? I don't know.
Yes, assertion is support in Java from 1.4. Most of the invariants in
the RM specifications are actually preconditions which should be
implemented as explicit check instead of assertion. See more at
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
What is wrong with the DbC concept like it is used now in the
constructors? If it was implemented in the setters, it would be like
There is nothing wrong with them. We still need to these explicit checks
regardless if we would choose go for mutable objects or not, or use
third-part DbC support or not.
invariants, when a setter is the only place to change a field. This
should be a golden rule.
Agree here.
But I agree, it would be good to have an Eiffel like mechanism (short
and simple coded).
I took a quick look at the web-page you point to. Did you study it?
Although it is a very young project. Maybe it is possible/feasible, if
it is good, to extract the needed functionality from it.I am very interested what is to happen in this, which choices will be
made. I would be glad to help if there are good ideas.
-----------------------------------------------------
Now another subject, a question to Rong, I come back to this later:
Maybe it is too early to ask, but is it that there will be no support to
Hibernate3, and the class changes needed?
Sorry for the delay. I will fix them (missing setters) if these don't
require change of coding style. Use of JML or DbC library would require
more experiments.
I ask because I hear none think about it. But maybe I am to early
(although, I started asking some weeks ago).
Specially now new points of view, may make other code-design possible.But is there will be no support for Hibernate3, then it doesn't need to
be a bad thing, a good fork, often matures specs, and also the products
And the code already standing is a very good base to start further
building and implementing the specs on.
I would like to encourage you to continue your exploration with
Hibernate3 since you have already started. Your experience on this would
be extremely valuable to the Java implementation project.
-----------------------------------------------------
I don't know what is best to do. I wonder, are there any
Java-programmers having ideas about this all?
I would really appreciate if there was any discussion about different
code-designs on this list
I would not mind share knowledge with people that help me develop ideas
and code.
-----------------------------------------------------
Come back to the original subject.
Even if we are to follow different code-paths, for whatever reason, I
mentioned my reasons to choose for Hibernate3 before.
Which may not be good, but I did not really see an effort to test the
idea. All objections/rejections seemed to me a bit too fast, too quick.
I agree we need more concrete implementation experience on the
persistence solution. We need to join force on this.
Regards,
Rong
Rong Chen wrote:
Yes, assertion is support in Java from 1.4. Most of the invariants in
the RM specifications are actually preconditions which should be
implemented as explicit check instead of assertion. See more at
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
we need to be careful to correctly understand the meaning of those
invariants - they are real invariants, i.e. conditions that have to
apply before and after calls to all publicly available routines,
including constructors. If you consider them preconditions, you have to
make a call at the start of every public routine; in this case I
recommend a single function called "invariant" to which a call is made;
by the way, it should also be called just prior to routine exit.
- thomas
Thomas Beale schreef:
Rong Chen wrote:Yes, assertion is support in Java from 1.4. Most of the invariants in the RM specifications are actually preconditions which should be implemented as explicit check instead of assertion. See more at [http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html](http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html)we need to be careful to correctly understand the meaning of those invariants - they are real invariants, i.e. conditions that have to apply before and after calls to all publicly available routines, including constructors. If you consider them preconditions, you have to make a call at the start of every public routine; in this case I recommend a single function called "invariant" to which a call is made; by the way, it should also be called just prior to routine exit.
It is a good idea to capture invariant checking in a separate method, which is “automatically” called in the begin and the end of every public method.
But that is not as simple as it sounds.
In Eiffel, a failing post-condition, or a failing invariant-check, as far as I remember, must neutralize the effect of the method.
The invariant-check should raise an exception, and catch it, to clean up its own mess, but also reraise it to let the caller catch it, and clean up its mess.
The system is not build in in Java, in no environment, only in Eiffel.
Thomas mentions DbC-libraries he uses with C#, maybe it is possible to port this library to Java. But maybe it is not, or maybe it is proprietary and not for sharing.
In fact, it is possible to write DbC controlling for Java, but it will be a pain in the …
A lot of work, and error-prone, because one must be careful to let a calling method not in a undefined state. So it has to be implemented in once through all objects.
But it is a good idea.
Cost maybe one week to do.
Much more simple to do is Dbc-proxies, but they are not meant to be for runtime, still worth something good, but not as good as Eiffel.
Coming to DbC, there is no equivalent in quality compared to Eiffel. We must admit that.
And DbC (excuse me for (in Netherlands we say:) kicking against a holy house) has no effect on the functionality of the code, it is functionality-neutral. So the code should not act different to the world if DbC is in it or if it is not.
That is why I come to the following idea, which I describe in my next message
Bert
Sorry, I thought I had an another email which referred to this subject and would be appropriate to proceed with my elaborations.
As I wrote before, openEhr can be seen as specifications, with example implementations, and implementations in production.
All these implmentions differ, in programming-environment, persistence-methods, OS-platform-dependency, database, programming language, business-model to operate, many more factors.
The only thing in common is the following of the specifications.
This diversification is good. it gives the future-customers something to choose, and in the end competition is good for us all.
To have competition there must be a playing ground to compete on, and we must remember the future customer, to serve him, because in the end, he is paying for all this. It will please him if in an early stage, even without him having a face or name yet, we were already thinking of him, to make things convenient, as much as possible.
But, not only for the customer, but even more for ourselves, it would be good to have for the Java-implementation a standarised interface, created by java-interfaces.
This makes it possible for each to do its own things under the surface. We now have Hibernate2 and Hibernate3, we have code with partially implemented DbC, maybe someone will want to implement it complete (if possible) or implement it by proxy for test or not implement it at all, or have another idea of error-catching and object validation. Maybe someone will want to write an own persistence-layer. There are many things to think of one would want to do.
This gives us great advantages.
The customer-implementor would have a standardized java-platfom to work against. Without changing a lot of code he could switch from underlying (under surface) code, from one to another.
This disconnecting of code and interface, also has a lot of advantage to us. We do not have to wait on each other, we can watch people work on a different path, and learn from that how to… or how not to do things. It makes us, developers free to do whatever we want, and still go on writing OpenEhr compliant code. It allows us to test ideas without having to change the interface, etc,. etc.
This is the idea I have, are there other opinions about this?
bert
Bert Verhees schreef:
Bert Verhees wrote:
But, not only for the customer, but even more for ourselves, it would
be good to have for the Java-implementation a standarised interface,
created by java-interfaces.
This makes it possible for each to do its own things under the
surface. We now have Hibernate2 and Hibernate3, we have code with
partially implemented DbC, maybe someone will want to implement it
complete (if possible) or implement it by proxy for test or not
implement it at all, or have another idea of error-catching and object
validation. Maybe someone will want to write an own persistence-layer.
There are many things to think of one would want to do.
In any case, we need a standardised API. We have already implemented an
API, and there must be one in the Java code as well. We should publish
these in a reviewable format, and begin collaborating on an abstract
formal specification.
I think the interface that Bert is talking of is between the openEHR
server layer and the pesistence. It would be nice to have a standard
interface there, but of course this will be platform specific.
- thomas
Thomas Beale schreef:
Bert Verhees wrote:But, not only for the customer, but even more for ourselves, it would be good to have for the Java-implementation a standarised interface, created by java-interfaces. This makes it possible for each to do its own things under the surface. We now have Hibernate2 and Hibernate3, we have code with partially implemented DbC, maybe someone will want to implement it complete (if possible) or implement it by proxy for test or not implement it at all, or have another idea of error-catching and object validation. Maybe someone will want to write an own persistence-layer. There are many things to think of one would want to do.In any case, we need a standardised API. We have already implemented an API, and there must be one in the Java code as well. We should publish these in a reviewable format, and begin collaborating on an abstract formal specification. I think the interface that Bert is talking of is between the openEHR server layer and the pesistence. It would be nice to have a standard interface there, but of course this will be platform specific.
Thomas, you are almost thinking what I am thinking, but I had some refinements. Maybe it is only a question of semantics and you are thinking about the same.
(API in my vision means, like traditionally in f.e. Windows, calls to do something. Windows has IMHO a very bad designed API)
I would like to see an object oriented API, actually I am thinking of complete interfaces. It will be platform specific, that is unavoidable. But similarity could third party developers get familiar on different platforms more easy. Maybe you were also thinking about this, let me explain more:
Like there are now in the specifications, and followed by Rong in the java-implementation, that specification translated into Java-interface, where it does not matter if it is in java-class-interfaces or java-(sec)-interfaces.
So the outside of the library, which will be a one to one translation of the specifications. And to (excuse me for repeating myself) give developers as much freedom as possible, and let them support each other as much as possible, there should be a steady interface (best in a sec-java-interface, a good way to hide underlying code).
I see one problem to this, but there may be more.
The problem I see is that you cannot instantiate an Interface. You need an object, and the instantiation-code should always be the same, in a way to avoid to confuse third party developers. So it could be consistent like this.
ObjectToInstantiate oti = new ObjectToInstantiateImpl()
Maybe, some Java-experts see a possibility to hide this kind op instantiation-code, and replace it by a layer which is better.
The main point is that there is freedom to develop and at the same moment, all have the same interface, you could call it API, but I don’t know it this is what Thomas understands by API.
Bert
Hi,
If I understand correctly, the interface mentioned by Bert is not exactly the same as the interface between different layers (packages / components). The idea is to have one interface for each RM class to hide the implementation details from the client code.
It is not common but does exist in Java world, e.g. in some XML libraries. The main drawback of it is the client code is stuck with the interfaces and can only get object instances through static factory methods, thus make it inconvenient to work with. For the RM classes, it’s not necessary a bad idea but it would need some exploration to judge I think.
Cheers,
Rong