Java v.s. Eiffel + What should the setters do as mandatory checks...

[erik.sundvall]

Hi!

well whatever you do, don't try it [Eiffel] now, otherwise you will go mad when you go
back to do something in Java

I agree that Java as in _the Java language_ is not always ideal and
not the most productive environment. I'm not a seasoned expert but
some experience with e.g. Smalltalk and Python has shown interesting
features (closures, mixins etc.) that Java does not have (yet) but
that are available in e.g. Ruby, Groovy etc. I still think having an
openEHR reference implementation in Java is very important, probably
the strategically most important reference implementation for openEHR.

Java as in the _JVM_ (that runs almost anywhere) and the ecosystem
around Java with a multitude of libraries and products is very
attractive. Now if we get a truly extendable and usable java-ref-impl
library it can be used smoothly with...

...several languages, e.g.:
JRuby, http://jruby.codehaus.org/
Groovy, http://groovy.codehaus.org/
Jython, http://www.jython.org/
Scala, http://scala.epfl.ch/

...and in several environments/setups, some random examples are:
http://www.terracotta.org/
http://code.google.com/webtoolkit/
http://www.springframework.org/

So let's go on discussing a bit about the future and what will be good
in order to possibly use the same java-ref-impl in many settings and
languages.

When we discussed
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html I
specifically mentioned what they said about using setters instead of
assertions for preconditions because I wanted a discussion on this.
Rong seems to go for what the document says and Thomas had a somewhat
different approach coming from the Eiffel culture. Below I'll try to
explain better what I think should be done and not in order to have a
solution that fits into the Java culture and that is at the same
"configurable" in some sense.

I tend to agree with Rong that in Java, the usual way to check
preconditions is to throw an exception on wrong usage. The environment
will show the caller what went wrong and where, just as I guess that
DbC preconditions in Eiffel work. Thomas said that preconditions
often are switched on in runtime (with a 5% additional processing
cost). So doing _some_ important mandatory checks in setters would
probably be a normal and good java-way of doing things. Even though
many are unnecessary when reading from database it could be an OK
default behaviour for the reference API.

If the properties are protected instead of private, then the setters
and their checks (all or selected ones) can be overridden anyway if
they are detected as significant bottlenecks in performance profiling
of some runtime system. So yes, checks in setters can be a good way to
do preconditions in java, and having protected properties instead of
private will cover the possible "configuration"-need for this.

So, what should the setters avoid as mandatory checking? I'd say
checking things in a way that forces the user to populate the objects
properties in a certain order is what should not be mandatory. The
reason is that many usages demand an arbitrary order of property
population, some persistence and GUI solutions are examples. In these
cases you might want to have the object in an illegal or inconsistent
state for a while during build up and then call validation when you
are finished. I believe Bert reported such a problem in
"AuthoredResource.java" in a posting on Jan 8.

If a certain order is demanded, then you might need to use special
builder classes (like the RM-builder) or you'll end up constructing a
parallel mutable hierarchy of custom coded objects that you then pass
to some building process (we have seen this happen here when using the
current code). If you instead have a choice to use mutable classes
that allow arbitrary population order, then coders can avoid a lot of
work. We have to consider how a library affects the users of the
library, solutions that lead to simple and elegant code within the
library but to unnecessarily complicated client code used to call the
library should be avoided.

Invariants could (depending on how they are written) cause problems
with arbitrary incremental object population. How does this look in
openEHR (the invariants in the spec)? Do they allow arbitrary order of
property population or not?

If we use assertions for invariants, they could be turned om and off
depending on what you want. The same goes for postconditions. This
would cover the "configuration" need for this part, but what do we do
if we want post-conditions on but not invariants? Any suggestions? An
extra if-statement in the assertions checking a boolean configuration
variable? (Sounds a bit too much like a "home-made-hack" maybe?)

Now, using assertions does not prevent us to also have comments
containing JML DbC rules if someone feels like adding and using that.
I do suspect that using the JML kind of DbC is not very common in the
Java culture. It sounds like Thomas has managed to get DbC used by
.net-people at Ocean, but I'd guess that is more of an exception than
a rule regarding environments that will use the java-ref-impl.
Assertions and (limited) setter checks is more java-style.

A side note to Thomas who I believe considers setters and getters are
a clumsy detour in order to change properties: Many of the alternative
JVM languages mentioned above and some scripting solutions (velocity
etc.) hide the "set" and "get" parts of java-bean-style objects and
let's your code treat the library as if the the properties are
directly accessed, but under the surface setters can do precondition
checks etc.

By the way I saw that JRuby is "Distributed under a tri-license
(CPL/GPL/LGPL)" note that CPL is the Eclipse thing. This could be
interesting to study regarding the previously mentioned Eclipse OHF. I
guess a quad licence would be quite possible too, but let's have the
IBM lawyers look at that later if necessary.

Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/

P.s. related link:
http://www.artima.com/weblogs/viewpost.jsp?thread=173229

[system]

So, what should the setters avoid as mandatory checking? I'd say
checking things in a way that forces the user to populate the objects
properties in a certain order is what should not be mandatory. The
reason is that many usages demand an arbitrary order of property
population, some persistence and GUI solutions are examples. In these
cases you might want to have the object in an illegal or inconsistent
state for a while during build up and then call validation when you
are finished. I believe Bert reported such a problem in
"AuthoredResource.java" in a posting on Jan 8.
  

That is correct, that is exact what I reported

Bert

[system]

Bert Verhees schreef:

So, what should the setters avoid as mandatory checking? I'd say
checking things in a way that forces the user to populate the objects
properties in a certain order is what should not be mandatory. The
reason is that many usages demand an arbitrary order of property
population, some persistence and GUI solutions are examples. In these
cases you might want to have the object in an illegal or inconsistent
state for a while during build up and then call validation when you
are finished. I believe Bert reported such a problem in
"AuthoredResource.java" in a posting on Jan 8.
  

That is correct, that is exact what I reported
  

That is to say, it was in another class, but the problem is like you
described.
There more problems witrh getter/setters and hibernate, I must point to.

Don't put logic in the seters which can fire an exception, how should
hibernate handle this?
As is the case, it stops, because of a uncaught exception, which can
lead to unpredictable results in a application.

You can say, in OpenEhr, where there is not much relational use of a
database in normal EHR use, data in the database will not change,
because no other objects touch them, so data coming from the
persistence always are valid. Because they were checked just before
writing them.

And if setters are only used for persistence-layers (make them protected
instead of public), there is no need to do DbC in setters

Bert

[thomas.beale]

Bert Verhees wrote:

[thomas.beale]

Bert Verhees wrote:

You can say, in OpenEhr, where there is not much relational use of a
database in normal EHR use, data in the database will not change,
because no other objects  touch them, so data coming from the
persistence always are valid. Because they were checked just before
writing them.

I think everyone using openEHR persistently is using a relational database to do it.

• thomas

[system]

Thomas Beale schreef:

Bert Verhees wrote:

You can say, in OpenEhr, where there is not much relational use of a
database in normal EHR use, data in the database will not change,
because no other objects touch them, so data coming from the
persistence always are valid. Because they were checked just before
writing them.

I think everyone using openEHR persistently is using a relational
database to do it.e best
- thomas

Yes that is true, that is the common tool, also familiar. Not
necessarily the best, but it can do very good.
But that is not what openehr is designed to, because most of the classes
do not interact on a relational way (like Codd had in mind), they could
as well be blobbed, it would functionally make no difference at all for
normal EHR use, but it would in performance.

The only thing to solve is that fast datamining will be impossible to do
on blob's.

So I started thinking towards hybrid solutions:
I was thinking:
- - for EHR-use, to use blobs for high performance store and
retrieval
- - and parts of the classes (have not thought about yet it which)
also store relational to make datamining possible, they can then be
written with low priority, eventually retrieved from the blobbed data,
and created once a day.

The blobs eventually before can be translated to XML (got the idea from
Thomas, a good listener (like me) only needs half a word, we say in
Holland) and then other techniques are possible to retrieve datastructures.

But that are only thoughts.

Fact is that most of OpenEhr is not a relational class model, (if that
is good English?), this fact gives us a lot of freedom to choose
implementation-forms.

For my choice at this moment, I work purely relational, and see where I
will get at, after that I will start tuning by partly blobbing or
"XML-blobbing", and see what will be necessary to do, or maybe use
multiple database-engines of different kind (which is only a matter of
configuration-files).

Good to have so many opportunities.

Maybe, we can discuss things with other people having experience with
Openehr-persistence.

I see that sometimes, the depht of data storage in relational storage
goes to far.
We'll see about that, it is almost ready, it was quite a job, lots of
difficulties to overcome, really, but I think it was worth it. Some
difficulties I am still in, the tuning of the MySQL InnoDB parameters,
for example, because of the data bombardments going to the database,
f.e. when storing a Composition, and also the way back.....

Bert

[thomas.beale]

Bert Verhees wrote:

Yes  that is true, that is the common tool, also familiar. Not
necessarily the best, but it can do very good.
But that is not what openehr is designed to, because most of the classes
do not interact on a relational way (like Codd had in mind), they could
as well be blobbed, it would functionally make no difference at all for
normal EHR use, but it would in performance.

that’s true, but there is nothing special about openEHR. No object model fits a relational database well. Hence the need for all the object mapping generally.

The only thing to solve is that fast datamining will be impossible to do
on blob's.

So I started thinking towards hybrid solutions:
I was thinking:
- - for EHR-use, to use blobs for high performance store and
retrieval
- - and parts of the classes (have not thought about yet it which)
also store relational to make datamining possible, they can then be
written with low priority, eventually retrieved from the blobbed data,
and created once a day.

this kind of thing is pretty common, and has been done for years, e.g. in Health.one (Belgian HIS), based on GEHR, the precursor to openEHR. There will be many variations on the theme, and experience will tell the best for each situation, but I doubt if one is best for all situations.

• thomas

[system]

Thomas Beale schreef:

Bert Verhees wrote:

Yes that is true, that is the common tool, also familiar. Not
necessarily the best, but it can do very good.
But that is not what openehr is designed to, because most of the classes
do not interact on a relational way (like Codd had in mind), they could
as well be blobbed, it would functionally make no difference at all for
normal EHR use, but it would in performance.
  

that's true, but there is nothing special about openEHR. No object
model fits a relational database well. Hence the need for all the
object mapping generally.

It depends, the Codd idea was also about sharing of data, better/easier
for maintaining. One can imagine object-models which have typical
relational characteristics.
But OpenEhr does not have, that is what counts.

The only thing to solve is that fast datamining will be impossible to do
on blob's.

So I started thinking towards hybrid solutions:
I was thinking:
- - for EHR-use, to use blobs for high performance store and
retrieval
- - and parts of the classes (have not thought about yet it which)
also store relational to make datamining possible, they can then be
written with low priority, eventually retrieved from the blobbed data,
and created once a day.
  

this kind of thing is pretty common, and has been done for years, e.g.
in Health.one (Belgian HIS),

Health One doess not use databases for their regular store, (as if I
remember well), they use a proprietary file format base on memory dumps
of object-constructs (every EHR, one file), and besides that, they
indeed use a regular database-engine to do other things, like
datamining, publishing data to webservers, reports, etc. In my humble
opinion it is a handicap to must work with a own data/memorydump format.
Every connection to modern generally used technique must be tricked, and
causes extra code, proprietary and not reusable code

based on GEHR, the precursor to openEHR. There will be many variations
on the theme, and experience will tell the best for each situation,
but I doubt if one is best for all situations.

true, it is a matter of taste, so to say.

regards
Bert

[erik.sundvall]

Hi!

Another candidate if someone would like DbC:
http://www.contract4j.org/

Based on, guess what, aspect oriented programming and Java annotations
(You can configure/enable/disable the DbC stuff at runtime if you
want. It works for java 5 and also 6 I believe.)

The example...
http://www.contract4j.org/contract4j/example
...points out that assertion based DbC code can make objects a bit
messy. Do you think this would be a problem or not for the
ref-impl-java code?

PS: (get my hobby in attention, already moved to the PS-part of an email
That is why we need to work on a base-code for conformance and reference
purposes.
(how can we do that, I have not seen an idea now, or I missed it,
please, then forgive me)

Oh, I think a couple of ideas have been mentioned. An incomplete summary list :
- Simple mutable POJO/bean-style objects with only simple default
validation on setters (so that arbitrary property population is
allowed).
- The properties in these POJOs should be protected not private.
- The POJOs described above could have a validation() method that
checks the object (and possibly its children when called.
- Separate packages with classes that extend the POJOs but that are
immutable and check everything at object creation. (Setters will throw
exceptions)
- Helper classes that can create an immutable object based on POJO and
the other way around.
- Rong also suggested "wrappers" as a possible solution (Rong feel
free to clarify this, wrappers can mean so many different things to
different people. Would these wrappers look like simple POJOs or would
they require some kind of factory to be created? What would be wrapped
within what? Would it be a simpler solution than having immutable
objects that inherit from POJO-style objects?)

Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/

[system]

Hi!

Another candidate if someone would like DbC:
http://www.contract4j.org/

Based on, guess what, aspect oriented programming and Java annotations
(You can configure/enable/disable the DbC stuff at runtime if you
want. It works for java 5 and also 6 I believe.)

The example...
http://www.contract4j.org/contract4j/example
...points out that assertion based DbC code can make objects a bit
messy. Do you think this would be a problem or not for the
ref-impl-java code?

> PS: (get my hobby in attention, already moved to the PS-part of an email
> That is why we need to work on a base-code for conformance and reference
> purposes.
> (how can we do that, I have not seen an idea now, or I missed it,
> please, then forgive me)

Oh, I think a couple of ideas have been mentioned. An incomplete summary list :
- Simple mutable POJO/bean-style objects with only simple default
validation on setters (so that arbitrary property population is
allowed).
- The properties in these POJOs should be protected not private.

I would agree with that, for me it is the same as interfaces, almost empty getter/setters, no semantics of the refenrence model in it, that would come in derived layers

- The POJOs described above could have a validation() method that
checks the object (and possibly its children when called.

I would not favour that, because, IMHO the getter/setters are only used for storage-purpose, and they should not validate. How to handle exceptions, would be aproblem, and thereby, everything that coems through it, is already checked at higher derived level, or at contructor (as it is now).
Aand also validation methods contain semaantic information, which should not be there at that level.

- Separate packages with classes that extend the POJOs but that are
immutable and check everything at object creation. (Setters will throw
exceptions)

Exactly

- Helper classes that can create an immutable object based on POJO and
the other way around.

I would like to see some examples, also examples on Rongs-wrappers.

- Rong also suggested "wrappers" as a possible solution (Rong feel
free to clarify this, wrappers can mean so many different things to
different people. Would these wrappers look like simple POJOs or would
they require some kind of factory to be created? What would be wrapped
within what? Would it be a simpler solution than having immutable
objects that inherit from POJO-style objects?)

We'll see, when do we start.?

I must have missed this wrapper-discussion, I do not read everything, which in a quick scan does not seem to fit in my thinking, sometimes I mis something.

I would like to get this started as quick as possible, and I can offer some help, as soon as we have a steady plan.

regards
Bert

[erik.sundvall]

Hi!

Just some clarifications.

> - The POJOs described above could have a validation() method that
> checks the object (and possibly its children when called.

Correction: validate() would be better than validation()

I would not favour that, because, IMHO the getter/setters are only used for
storage-purpose, and they should not validate. How to handle exceptions,
would be aproblem, and thereby, everything that coems through it, is already
checked at higher derived level, or at contructor (as it is now).
And also validation methods contain semaantic information, which should
not be there at that level.

Sorry if I was not explaining this good enough. I only meant that the
validation method could be provided as a method that validates the
entire object _if_ the application designer chooses to call it, for
example when they consider their calling code to be finished with
object creation after finishing parsing of an incoming XML-message.
Validate() should not be called automatically by setters in the base
class, but some overriding implementation might want to call
validate() in their setters or constructors though and those coders
would then not need to write their own validation code.

(Related repetition: Some simple argument checking in setters might be
OK if the community feels that this would be good. That is common Java
culture practice and can catch a couple of bugs in a familiar manner.)

A word of warning though: having a validate() method might be
completely unneccesary if we have other ways of validating an object
or object structure. Some examples:
- DbC activated (that would check RM conformance)
- An external RM-validator class that traverses and validates the
object or object structure.
- An external RM-validator class that traverses the object or object
structure and at the same time is Archetype aware and checks for
constraints based on both the RM and the archetypes used within the
structure.

I guess that the last two in the list are similar to what is done in
the current code of the RM builder and when creating RM instances from
an archetype object. The difference is that clients can populate real
RM objects and object structures with data instad of populating maps
with attribute names and objects. I believe that one then in many
situations (not all scenarios) will get better support from an IDE and
the compiler to catch potential bugs before runtime.

> - Helper classes that can create an immutable object based on POJO and
> the other way around.
I would like to see some examples, also examples on Rongs-wrappers.

I agree that examples and some experiments would be good before
starting any major redesign.

I would like to get this started as quick as possible, and I can offer some help,
as soon as we have a steady plan.

Rong is working on a roadmap for the java-ref-impl.
http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm
(I found in SVN now with the help of Mattias, links from the website
are missing or hard to find. There are also other interesting
documents in: http://svn.openehr.org/ref_impl_java/TRUNK/docs/)

I believe this discussion can give input to the roadmap.

Rong is also stabilizing and fixing the current java-ref-impl version
and I think it is good that improving the current version has priority
over discussions about the future.

Experiments with mutable objects etc. should probably be done in a
separate SVN branch if we want them version controlled by openEHR, and
probably more people than Rong should be involved in contributing and
committing code to that branch since Rong has other things to do in
life too

Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/

[system]

Rong is working on a roadmap for the java-ref-impl.
http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm
(I found in SVN now with the help of Mattias, links from the website
are missing or hard to find. There are also other interesting
documents in: http://svn.openehr.org/ref_impl_java/TRUNK/docs/)

Well, I plan to post the link to the list for discussion before I manage to include some comments from a small group of people who have reviewed this document. But thanks anyway. Here are things on the to-do for this doc so that you know what’ coming - better categories ( e.g. Applications instead of Tools); status of each components and a overview diagram which includes all the components and how they fit into a full-blown system.

Cheers,
Rong

[system]

Erik Sundvall schreef:

Hi!

Just some clarifications.

- The POJOs described above could have a validation() method that
checks the object (and possibly its children when called.
      
Correction: validate() would be better than validation()

I would not favour that, because, IMHO the getter/setters are only used for
storage-purpose, and they should not validate. How to handle exceptions,
would be aproblem, and thereby, everything that coems through it, is already
checked at higher derived level, or at contructor (as it is now).
And also validation methods contain semaantic information, which should
not be there at that level.
    
Sorry if I was not explaining this good enough. I only meant that the
validation method could be provided as a method that validates the
entire object _if_ the application designer chooses to call it, for
example when they consider their calling code to be finished with
object creation after finishing parsing of an incoming XML-message.
Validate() should not be called automatically by setters in the base
class, but some overriding implementation might want to call
validate() in their setters or constructors though and those coders
would then not need to write their own validation code.
  

I agree

(Related repetition: Some simple argument checking in setters might be
OK if the community feels that this would be good. That is common Java
culture practice and can catch a couple of bugs in a familiar manner.)
  

I could not think about a purpose for this, as the base-class setters
are only used by persistence-layers and only will be used by what has
been written by the getters to the persistence-store.

A word of warning though: having a validate() method might be
completely unneccesary if we have other ways of validating an object
or object structure. Some examples:
- DbC activated (that would check RM conformance)
- An external RM-validator class that traverses and validates the
object or object structure.
- An external RM-validator class that traverses the object or object
structure and at the same time is Archetype aware and checks for
constraints based on both the RM and the archetypes used within the
structure.
  

I agree, but that is a higher level where setters can be used by
application programmers. This is another discussion

I guess that the last two in the list are similar to what is done in
the current code of the RM builder and when creating RM instances from
an archetype object. The difference is that clients can populate real
RM objects and object structures with data instad of populating maps
with attribute names and objects. I believe that one then in many
situations (not all scenarios) will get better support from an IDE and
the compiler to catch potential bugs before runtime.
  

It suddenly appeared for my nose. I have to study that. Today was such a
big Java update, I am a bit confused by that, I must think how to handle
this. it is all trunk, that is true, I ask this question in a separate
message

  

- Helper classes that can create an immutable object based on POJO and
the other way around.
      

I would like to see some examples, also examples on Rongs-wrappers.
    
I agree that examples and some experiments would be good before
starting any major redesign.

I would like to get this started as quick as possible, and I can offer some help,
as soon as we have a steady plan.
    
Rong is working on a roadmap for the java-ref-impl.
http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm
(I found in SVN now with the help of Mattias, links from the website
are missing or hard to find. There are also other interesting
documents in: http://svn.openehr.org/ref_impl_java/TRUNK/docs/)
  

I hate looking to TRUNK, it is a moving target, it does not help me.
My target is finishing an implementation. I don't have time to follow
new ideas on moving targets.

I can learn from that but not implement that.

I believe this discussion can give input to the roadmap.

Rong is also stabilizing and fixing the current java-ref-impl version
and I think it is good that improving the current version has priority
over discussions about the future.
  

Which is current?

Experiments with mutable objects etc. should probably be done in a
separate SVN branch if we want them version controlled by openEHR, and
  

I don't know, we had a branch sandbox, it disappeared, we had a branch
rm-splitted, it disappeared.

I guess, some ideas are better done in forks, and maybe ported partly
back, if the fork brought good ideas.
maybe fork is the same as branch in your way of speaking, but forks do
not disappear suddenly.
They even can be maintained, if someone likes to do that.

probably more people than Rong should be involved in contributing and
committing code to that branch since Rong has other things to do in
life too
  

I agree, more people should have a chance to get involved. It is good
for Rong, but also for the project. It never is good if a project
depends too much on one person.
There must be an infrastructure to let others be involved.

Bert

[thomas.beale]

Erik Sundvall wrote:

Sorry if I was not explaining this good enough. I only meant that the
validation method could be provided as a method that validates the
entire object _if_ the application designer chooses to call it, for
example when they consider their calling code to be finished with
object creation after finishing parsing of an incoming XML-message.
Validate() should not be called automatically by setters in the base
class, but some overriding implementation might want to call
validate() in their setters or constructors though and those coders
would then not need to write their own validation code.

this problem is a well-known one in non-trivial software. The invariants that should be true after creation only relate to a minimal version of an object, created in any circumstance. The validate() - I usually use the method name is_valid: Boolean for this purpose - is about business level validity of the object, and can only be called at sensible points. You can see an example in the Eiffel version of the ARCHETYPE class:

http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/libraries/openehr/src/am/archetype/archetype.e?op=file&rev=0&sc=0

Look at the is_valid method (about halfway down), and the invariants (at the bottom). Note that “is_valid” is not mentioned in the invariants.

You can see that is_valid is called by the ADL_INTERFACE class in the parser: http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/components/adl_parser/src/interface/adl_interface.e?op=file&rev=0&sc=0
see the parse_archetype method, about 3/4 way down.

It takes a while to get used to having to have more than one idea of validity, but it is almost always needed.

• thomas

[Mattias_Forss1 (Mattias Forss)]

2007/1/17, Bert Verhees <bert.verhees@rosa.nl>:

Erik Sundvall schreef:

(Related repetition: Some simple argument checking in setters might be
OK if the community feels that this would be good. That is common Java
culture practice and can catch a couple of bugs in a familiar manner.)

I could not think about a purpose for this, as the base-class setters
are only used by persistence-layers and only will be used by what has
been written by the getters to the persistence-store.

Hi Bert,

I don’t think the setters are only used by persistence layers. There are other use cases as well. Code that creates RM objects by getting data from a user interface is an obvious example. As long as the checks are small and don’t use too much resources it shouldn’t be a problem of having them.

You might say that when we are creating RM objects from the user interface side we do the checks after all objects have been created by calling some validation code. I think the simple checks in the setters could prove useful to detect errors at an early stage in the code instead of getting back a list of errors first after all objects have been created and the validation is done.

Regards,

Mattias

[system]

Mattias Forss schreef:

2007/1/17, Bert Verhees <bert.verhees@rosa.nl
<mailto:bert.verhees@rosa.nl>>:

    Erik Sundvall schreef:
    > (Related repetition: Some simple argument checking in setters
    might be
    > OK if the community feels that this would be good. That is
    common Java
    > culture practice and can catch a couple of bugs in a familiar
    manner.)
    >
    I could not think about a purpose for this, as the base-class setters
    are only used by persistence-layers and only will be used by what has
    been written by the getters to the persistence-store.

Hi Bert,

I don't think the setters are only used by persistence layers. There
are other use cases as well. Code that creates RM objects by getting
data from a user interface is an obvious example. As long as the
checks are small and don't use too much resources it shouldn't be a
problem of having them.

You might say that when we are creating RM objects from the user
interface side we do the checks after all objects have been created by
calling some validation code. I think the simple checks in the setters
could prove useful to detect errors at an early stage in the code
instead of getting back a list of errors first after all objects have
been created and the validation is done.

I thought, the proposal to which I can agree, and which made me happy
was to create a base-class-layer with protected getter/setters. It is
not possible to use them of extern classes, because they are protected,
just like Erik proposed (POJO-style). On "top" of the base objects with
protected getters/setters would be the real reference implementation,
with possibly rich getters/setters, rich constructors, etc.

In my opinion, the base-classes should have all the properties that are
important from perspective of serialization.

But this is my opinion, I thought, also Eriks opinion, maybe I misunderstood

regards
Bert

[system]

probably more people than Rong should be involved in contributing and
committing code to that branch since Rong has other things to do in
life too

I agree, more people should have a chance to get involved. It is good
for Rong, but also for the project. It never is good if a project
depends too much on one person.
There must be an infrastructure to let others be involved.

Agree here. People get involved in open source projects in different level - testing software, reporting bugs, submitting patches, discussing ideas for new development and finally coding directly are all regarded as valuable contribution to the project. In that sense, I think you are already involved and contributing, aren’t you?

Ultimately the Java project will need more committers other than Yin Su (Tom?) and me. But I see getting a committer right as a gradual process and I certianly think we have several good candidates on this list

Regards,
Rong

[system]

Rong Chen schreef:

    > probably more people than Rong should be involved in
    contributing and
    > committing code to that branch since Rong has other things to do in
    > life too
    >
    I agree, more people should have a chance to get involved. It is good
    for Rong, but also for the project. It never is good if a project
    depends too much on one person.
    There must be an infrastructure to let others be involved.

Agree here. People get involved in open source projects in different
level - testing software, reporting bugs, submitting patches,
discussing ideas for new development and finally coding directly are
all regarded as valuable contribution to the project. In that sense, I
think you are already involved and contributing, aren't you?

Ultimately the Java project will need more committers other than Yin
Su (Tom?) and me. But I see getting a committer right as a gradual
process and I certianly think we have several good candidates on this
list

I would say, if we accomplish the base/POJO-implementation, in the way I
have written the Roadmap-document, and we have thus the base for
building different storage-implementations, people could be given
opportunity to do something with that base.
For me, I could publish the hibernate3-layer, included hbm-files and
test-files.. But I need something in return for this, else I cannot sell
this to my employer.

So a good plan/deal would be (IMHO).

Create a naming scheme for the base/POJO-classes
Create the POJO-classes, so that the reference-implementation fits on it.

If this is ready, I can publish my hibernate3-layer, gives me also some
extra time to do some tuning, and clean up some mess.

My advantage will be (also to convince the employer)

I can reconnect to development on the reference-implementation, this
will lead to a much better and stable product.
I still will be able to use and control the databasestructure as I think
it will be optimal. Tuning of hibernate is very much depending on
implementation-purposes, etc. We can share the knowledge, even create,
f.e. more hibernate3 layers for different purposes
Also important could be that is that the company-name of my employer
gets more exposure.
Maybe I switch also to another email-address, and name some source-trees
to this company, in addition of se.acode, there would also be nl.zorggemak

So, the sooner we start, the better.

I can help write some POJO files, it is not a lot of work, mainly
deleting things. There are a few current reference-implementation
classes which are not easy to translate to POJO.
We must rewrite the reference-layer so it can be used together with the
POJO.
I could spent an hour every day or so, for community-based work. And
even if possible, good for my own production, more.

regards
Bert

[system]

Bert Verhees schreef:

Rong Chen schreef:

    > probably more people than Rong should be involved in
    contributing and
    > committing code to that branch since Rong has other things to do in
    > life too ;-)
    >
    I agree, more people should have a chance to get involved. It is good
    for Rong, but also for the project. It never is good if a project
    depends too much on one person.
    There must be an infrastructure to let others be involved.

Agree here. People get involved in open source projects in different
level - testing software, reporting bugs, submitting patches,
discussing ideas for new development and finally coding directly are
all regarded as valuable contribution to the project. In that sense, I
think you are already involved and contributing, aren't you? :-)

Ultimately the Java project will need more committers other than Yin
Su (Tom?) and me. But I see getting a committer right as a gradual
process and I certianly think we have several good candidates on this
list ;)

I would say, if we accomplish the base/POJO-implementation, in the way I
have written the Roadmap-document, and we have thus the base for

My bad English, often make small mistakes, maybe I work to hard, anmd do not pay enough attention

I meant to say:

I meant to say, if we accomplish the base/POJO-implementation, in the way I 
have **read** the Roadmap-document, 

excuse me

Bert