db-jdo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "boegner-online@gmx.de" <boegner-onl...@gmx.de>
Subject Re: Parameterized constructors with JDO
Date Fri, 27 Aug 2010 13:22:29 GMT
Thanks for answering. You are the first who replied.

I thought of making the constructors private, too. The question is than: 
Is JDO able to use this constructor or it is not, because it is private 
respective protected?

Actually such a class would not be a Java bean class. Every Java bean 
class has to provide a public parameterless constructor, e.g. the 
default constructor which is automatically there, if no other 
constructors have been specified.

Can JDO handle those classes with private / protected constructors?
Does JDO work with reflection to instantiate classes for detachment?

I know it would be possible to use private class members, through 
reflection, but this becomes a security issue. If JDO somehow can use 
those private constructors, that would be the easiest solution.

However there are other approaches. It may be possible to configure 
which attribute has to be injected with which constructor parameter. 
This may be optional. Most constructors look simple like this one:

     public MyPojo(int myAttribute) {
         this.myAttribute = myAttribute;
     }

It would be possible, to automatically analyze and use such constructors 
by JDO. This would help users to write better code while JDO stays easy 
in use.

Does JDO support anything in that direction? I am realistic enough, that 
this won't be a new feature in acceptable time, if it is not there, yet.

Actually this is an dependency injection issue. In this case, there may 
be no global objects to inserts. Instead there may be individual 
attributes taken from the datastore and injected into the object during 
detachment. I am not sure if the new dependency injection API supports 
anything like this. If I remember right, it can inject references 
through constructors. I will read about this.

Thanks again for answering and thank in advance for any future repliers. :D

Am 27.08.2010 08:33 schrieb Renato Garcia <renatao.garcia@gmail.com>:
 >  Hi,
 >
 >
 >
 > Did you get an answer for this yet? You could declare 
protected/deafult constructors. Would that sovle?
 >
 >
 >
 > On 21/08/2010 2:38 AM, boegner-online@gmx.de wrote:
 >
 >
 > Hello,
 >
 >
 >
 > I am new here. I looked at the archives but I did not find anything 
related. Maybe a search function would be nice.
 >
 >
 >
 > Sometimes there are classes which need some other objects to work 
well. When I write those classes I like to write a constructor with 
those dependencies as parameters. So there is no default constructor 
anymore. I think this is nice, because everyone who uses my class can't 
do much wrong now. The instances are in a consistent state (at least at 
initialisation time).
 >
 >
 >
 > Without a parameterless constructor the class is no bean anymore. I 
can't use such classes with JDO, right? I see that it is much easier for 
an persistence layer to deal with bean's parameterless constructor 
instead of constructors with parameters. But I think it would be a 
really nice feature of JDO to do so.
 >
 >
 >
 > Alternatively I thought about writing beans and using them as 
attributes of my classes. Another alternative would be to use beans at 
the persistence layer and my POJOs at application layer. In that case 
there has to be an layer which converts between POJOs and beans. Both 
approaches seem to work at a first look, but they require almost double 
the code like a POJO only or bean only solution. For every POJO there 
has a bean and maybe a converter be written. This is a huge repetition.
 >
 >
 >
 > My questions are:
 >
 >
 >
 > - Is it right, that there is no way that JDO can deal with 
parameterized constructors?
 >
 > - Is there a related feature at development or did you even think 
about it?
 >
 > - Any other proposal?
 >
 >
 >
 > Thanks in advance
 >
 >
 >
 > c0d3x 
<http://mail-archives.apache.org/mod_mbox/db-jdo-user/201008.mbox/%3c4C6EAF8B.7000109@gmx.de%3e>

Mime
View raw message