Re: Parameterized constructors with JDO

[Michael Bouschen]

 Hi,

sorry for the late response.

I like to second what Renato said: JDO requires that a 
persistence-capable class must have a no-arg constructor and it is your 
choice which visibility you give it. In addition you can add as many 
constructors (with any number of arguments) as you want.


Concerning the use of reflection: JDO does not specify whether to use 
reflection or not, this is an implementation decision.


Regards Michael



 Hi,

Yes,  should be able to use no-arg constructor with other visibility 
than public. I believe that even if you don't declare one, or override 
the default,  most of the implementations will create one at enhance 
time to be used. Note that you can also constructors with arguments 
along with your non-public no-arg constructor.


You might want to take a look at the spec 
, as is it might answer 
a lot of your questions. This constructor question, for instance, is 
clearly stated there:
"All persistence-capable classes must have a no-arg constructor. This 
constructor might be a private
constructor, as it is only used from within the jdoNewInstance 
methods. The constructor might be
the default no-arg constructor created by the compiler when the source 
code does not define any

constructors."

Regards,
Renato

On 27/08/2010 11:22 PM, boegner-onl...@gmx.de wrote:

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 :
>  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-onl...@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 

Re: Parameterized constructors with JDO

[boegner-onl...@gmx.de]

Thanks a lot. That sounds really great. I'll give it a try.

Re: Parameterized constructors with JDO

[Renato Garcia]

 Hi,

Yes,  should be able to use no-arg constructor with other visibility 
than public. I believe that even if you don't declare one, or override 
the default,  most of the implementations will create one at enhance 
time to be used. Note that you can also constructors with arguments 
along with your non-public no-arg constructor.


You might want to take a look at the spec 
, as is it might answer a 
lot of your questions. This constructor question, for instance, is 
clearly stated there:
"All persistence-capable classes must have a no-arg constructor. This 
constructor might be a private
constructor, as it is only used from within the jdoNewInstance methods. 
The constructor might be
the default no-arg constructor created by the compiler when the source 
code does not define any

constructors."

Regards,
Renato

On 27/08/2010 11:22 PM, boegner-onl...@gmx.de wrote:

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 :
>  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-onl...@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 

Re: Parameterized constructors with JDO

[boegner-onl...@gmx.de]

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 :
>  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-onl...@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